my first post on this forum was a desperate plea for help on my first rigging job so I want to keep this one light.
just wondering if anyone saves their renaming for later?
I find stopping to rename joints during my workflow to be a little bit disruptive to my process.
But then when I save it for later the work really builds up!
I thought a mel script could be a good idea but joint names can have so much variation between rigs.
just wondering what others’ approach was.
You can write a script that takes care of names obviously but if you’re doing it manually try something like this:
I use this while modeling, I like that its just a box that pops up, I enter the name / prefix / suffix/ hit enter and keep going. (assign it to a hotkey like f4 or something)
Once you get to the really hardcore rigging I think most rigs are built using scripts or a toolset as opposed to manually placing joints, etc. These tools usually provide a default naming system or even a customizable one.
It might be unlikely as a starter rigger you have those tools available to you. Though there are some that you can purchase, like abAutoRig, Rapid Rig, or even are free, like MGear or other popular auto riggers.
Anyway, if it’s really the naming itself that’s cumbersome then definitely a tool like cometRename or similar already helps a lot.
Awesome, thanks so much for the tip. Can’t wait to give it a try!
As far as humanoid Rigs go I have had to somewhat force myself into Hardcore rigging, I have scripts that take care of most of my needs, thats when it comes to humanoids and other common creature shapes.
I can’t imagine anything replacing manually placing joints for my workflow though, Unless theres a script that centers it around a loop? anyways
I do have a pretty good collection of pre defined skeletons but this mesh happens to be entirely unique.
I suppose I will have to evaluate some of the tools you listed to see how they do naming
I have already hijacked a couple of UI “practices” from other auto rigging tools. but all of my mel scripts are super shakey when it comes to names.
I usually just end up copying the names form the outliner into my script 
string manipulation and UI are definitely my biggest weakness with mel.
Using long names – ls -l – and sorting them helps make the hierarchy obvious. For example this ugly hierarchy:
run through
sort `ls -l -type transform`
produces
// Result:
|group6
|group6|group5
|group6|group5|group4
|group6|group5|group4|group8
|group6|group5|group4|group8|group7
|group6|group5|group4|group8|group7|group3 |group6|group5|group4|group8|group7|group3|group2
|group6|group5|group4|group8|group7|group3|group2|group1
|group6|group5|group4|group8|group7|group3|group2|group1|pCylinder1
|group6|group5|group4|group8|group7|group3|pCone1
|group6|group5|group4|group8|group7|group3|pCube1
|group6|group5|group4|group8|pTorus1
//
You can see the branches (at group8 and group7) and how they are preserved in the sorted list. If you work through this list in reverse order (starting with |group6|group5|group4|group8|pTorus1 and ending with |group6) you can do renames without worrying about parentage because you’ll always be renaming children before their parents.
For joints, it’s a good idea to use the .side and .type attributes and then build your names using them – have you script compile those names into whatever convention you need.
With those two tricks – the hierarchy sort-reverse and the attributes to mark intent and side – you can write a decent Mel script to handle the renames in pretty short order.
Speaking of mel renames, suprised to see how fast mel can be (oh so rarely):
Although at 900 cmds catches up. I guess that makes sense python does have a virtual machine.
this beats middle mouse clicking and dragging in the outliner anyday!
Maybe you can add custom attributes on the node.
Just an fyi @dive, python isn’t actually the cause of slowdown here. The column labeled “CMDS” is actually referring to “maya.cmds”, running in python. “OPENMAYA” is actually running “maya.OpenMaya” in python as well. The pymel package is the culprit, not the python language, which for many things can be faster than mel. Pymel just instantiates a lot of objects when it returns data and uses more memory, and as a result is slower.
I like to place a lot of my joints by hand too. Here’s a little script I wrote a while ago that I’ve been using to make renaming easier. You can just select a bunch of joints in sequence and then it will go through them one at a time and you can type a name, then hit enter to continue to the next without having to use the mouse to highlight, rename or select.
I’ll run this tool to name things initially, then use the comet renamer to add prefixes line “L_”, then mirror.
import PySide2.QtWidgets as QtWidgets
import PySide2.QtCore as QtCore
import pymel.core as pm
def chainRenamer():
if not pm.selected():
pm.warning('Nothing is selected')
return
selection = iter(pm.selected())
dlg = QtWidgets.QInputDialog()
dlg.setWindowTitle('Chain Renamer')
dlg.setWindowFlags(QtCore.Qt.Dialog | QtCore.Qt.WindowCloseButtonHint)
dlg.setLabelText('Enter a new name for the selected object')
def select_next():
if selection:
try:
pm.select(selection.next())
except:
return
dlg.show()
def dlg_next():
text = dlg.textValue()
pm.rename(pm.selected()[0], text)
select_next()
dlg.setModal(True)
dlg.accepted.connect(dlg_next)
select_next()
if __name__ == '__main__':
chainRenamer()
Hey JoDaRober,
I def. agree with you, usually things work out how you’re saying.
But look at the first column “MELRename” [Thats regular old MEL not PyMel right?]
Not that it matters, rename isn’t performance critical, but could you explain that?
For objects between 0-100 MEL is faster than OpenMaya, Pymel, and Cmds. (?) More than twice as fast. (No I am in no way advocating MEL trust me haha)
My guess is that before 900 objects, Python[cmds] is paying a startup cost, but at 900 you can see MEL’s lead diminish significantly. (Ignoring PYMEL, we all know thats super slow haha)
I haven’t tried it out myself, but this makes no sense to me. Curious what you think?
I find it slightly annoying MEL is faster 
If you are doing this from the listener there’s probably a compilation cost. Careful management of the Python should also shave off some time too , but honestly it’s not worth getting bent out of shape over human users are unlikely to care 
I’d expect that importing the same function from a module (rather than running it from the listener where the def gets redefined) will cut some of the startup cost …
What you’re seeing here sounds correct to me. Plain old mel is technically faster to execute than maya python scripts, but it doesn’t handle things like code libraries near as well, and importing files takes a lot longer than in python if you have a lot of them, from my experience at least.
My main point is that the loss in speed isn’t necessarily the fault of the python language, but rather the way the cmds, OpenMaya, and pymel libraries are implemented.
But, as @Theodox said, it doesn’t actually matter at those speeds, with the exception of the PyMel 900 case. You have to have a delay of at least 15ms before you start to notice it for things like audio and realtime applications, but for user facing tools like a renaming utility the user isn’t going to notice any slowdown until you start running into delays of 1/8th a second or greater. And even 1/8th a second to rename 900 objects for example may still seem small enough to the end user to be acceptable. Most commercial touchscreen devices have a latency of between 50 and 200ms, just to put that into perspective.
Everyone likes to debate speed, but the reality is you’re better off writing a tool that’s stable and easy to use, and not concerning yourself with speed until it becomes a noticeable issue in the regular usage of the tool
Def. Agree 100 percent JoDaRober,
Clean, modular, testable, Python all day please.
That’s why I was explicitly like, I know it doesn’t matter (performance) nor am I in any way advocating more MEL use haha, I’m just curious as to why such a difference was present at all.
Python IS one of the fastest languages in the world.*
*In terms of developer productivity 
I was just curious as to why Mel would be faster at runtime, how it interfaces with Maya core is somewhat obfuscated in any documentation I’ve seen. I used to always think it was slower than Python.
Something I did learn from that paper above is that xform is quite a bit faster than PolymoveVertex, so I probably will always use that.
Much thanks for the explanations!
Just my 2 cents on the placement of joints with human rigs; with the core anim joints you are
better off manually placing them as close as you can to anatomically accurate pivot positions. Systems that auto place joints in the center of a region or build a skeleton from a mesh input are not going to necessarily give you the best skeleton for animation.
The ideal joint placement for skinning should not be your primary concern. Whether you work in film or games, there are better ways to get great deformation independent of the core anim joint placements. (look up rbf, pose space deformation, other rigging constraints).
That’s not to say however that there isn’t a practical use for auto joint placement, but more along the lines of helper joint creation + auto skin weights calc (aka skinning decomposition). Most solutions for this are not publicly available. Closest I can think of is EA’s dembones, but I don’t believe it covers the driver side of the problem.