When to do the final Bind?

After one does a preliminary bind to check for joint placement and bad geometry, should the rig have all the FK controls, IK & FK skeletons, contraints, SDK, etc attached before the final bind ?

I think it depends largely on your tools and workflow. Much of the time the rigs I work with are generated via script - so generating the skeleton/guide and the full control rig is trivial and therefore I use that during a preliminary binding.

If I were rigging by hand, or was using a toolset that went through many stages then I would probably leave out any control specific functionality (for instance, whether in IK or FK the deformation should be no different), but anything that affects the deformation (such as twists, or SDK’s etc are probably worth testing with during the initial bind.

MiKeM,
Thank you ! Thats very interesting. Do you generate these scripts in Python ?
Do you know any reference material that would shed some light on creating these
scripts? I already know a bit of python and mel.

Like MikeM, all my rigging is generated via script. But skinning/binding is independent process from rigging. For example, may of our assets are never rigged, since they’re on a shared skeleton, and the animators use some generic version for the motion sets. The skeleton is the intersection of skinning and rigging, and to me they can both be on two different development schedules.

When do I do a ‘final bind’? When I get word the asset design is locked and final. Then I go in and add the sauce. But as long as it’s in block form, or the final mesh is still being iterated on, I’m hands off putting the polish time in until it’s signed off on.

Of course, a final approval is really never a final approval (bob_final_01_releaseCandidate02_B_reallyFinalThisTime02.mb), and technically assets can get updated designs at any time, but I’m hedging my bets at this point that it really shouldn’t happen too often.

These are all very good points. Thanks for the insights.
Is the rig scripting done in Python ? if so maya.cmds or pymel ?
Could you direct me to reference material for total rig scripting ?

Most of it will be done through python yes.

I had a quick look for tome tutorials to get you started, free ones seem to be hard to come by unfortunately. But these should give you an idea of what to look for.

There are also free autoriggers like mGear or Advanced Skeleton. But I wouldn’t advise using those if you have no experience with scripted setups.

There are several scripts out there to store your weights redo the rig and bring them back.

That is awesome ! Thanks so Much !!

Python: Used PyMel for a few years, but didn’t care for the performance hit, so went back to vanilla maya.cmds / maya.api.OpenMaya combo

We author our rigging code as internal IP, but it looks like PVDH gave some nice resources.

I wanted to explicitly call out the common practice having separate “bind” skeleton that is driven by the “rig” skeleton. For games you generally need a skeleton with out extra transforms, which has the advantage of being able to make some (but not all) rig changes without altering the weighting at all.

I would recommend using pymel to start with because it makes so much stuff easier to work with, like tracking object renames.

obj = selected()[0]
obj.rename( 'box' )
obj.rename( 'still_works' ) # pymel renames work no matter how many renames happen

Pymel lets you make code with clearer intent:

for i in range( len(polyEvaluate('pCube1', v=True)) ):
    xform( 'pCube1.vtx[%i]' % i, q=True, t=True )

for vert in obj.vtx:
    xform(vert, q=True, t=True)

Pymel is also much faster now than it used to be. There are still cases where it’s not, like iterating every vert of high poly meshes. Still, I always use pymel first and refactor the slow parts with cmds or maya.api if it is too slow.

I’ve been working on a modular rigging system for a while that you’re free to use, look at and take apart https://github.com/patcorwin/fossil/