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.
1 Like
There are several scripts out there to store your weights redo the rig and bring them back.
1 Like
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/