Looking for input on managing 100’s of skinned meshes that’ll share the same rig.
some options and questions:
-import meshes into the rig scene, skin and weight there. super heavy scene! Danger!
-reference them into the rig scene. now you can edit their mesh as needed in their own scenes, but weighting will still need to be be done in the master rig scene. What if vert counts change? Other drawbacks?
-reference the rig into each asset scene. Skin and weight there. Change vert counts easily, as the mesh isn’t referenced. What if the rig changes? (additional joints, moved joints… ugh)
I have little experience using referenced rigs/meshes for skinning. Not sure what the big ‘gotchas’ are, or if there’s an obvious way I should be headed. Any input appreciated!
Coming from a Softimage background this is also an issue we encountered at Lionhead. Here are the thoughts I had :
Reference all the meshes into the rig scene
The geometry will definitely change during iteration, and the fact that the skinning is done in a file where it is referenced means its potentially very error prone. Another problem here is the volume of references, and the fact that adding a new geometry asset means updating the rig file. Depending on the project this may not be an issue, but when you’re talking about hundreds of meshes sharing rigs it has the potential to be a little messy.
Referencing the rig into each individual geometry file
Initially this seems like a great idea, and depeding on the projects requirements it may very well be the solution that works. The issue we have is that our characters are made up from multiple parts and thus we need to link multiple meshes to a single rig. Because of that its not really a viable option. Rig changes are generally not an issue, if your skeleton changes to a point where bones are removed then you’ll hit the same problem regardless.
In the end, we decided to store our geometries and our rigs seperately with each ‘asset’ ( whether its geometry or a rig) stored within a container scope. When a user saves a skinned piece of geometry ( using our own ‘save’ option) what we actually do is store various information about the skin connections, and bespoke asset node connections then do an equivilent of ‘export selected’.
The same procedure is carried out for the rig. This way the artist/animator can work on any amount of assets at the same time and not worry about removing other assets to save. It also means that an animator can on-the-fly reference geometry to any rig in the scene.
It defintily has an overhead in terms of pipeline code but it offers a lot of flexibility.
The way I’ve done that in the past is to separate each mesh into it’s own maya file with the just the joints that the mesh needed to be skinned to. I would do my skinning and weighting in these files. Then I would reference in one of the skinned mesh files into my rig scene and point and orient constrain the skinned joints to the corresponding rig joints. As long as all of the skinned joints were named the same across every file, I was able to replace the referenced skinned mesh file at any time. I then just made a few mel scripts for the animators that made replacing the referenced file nicer and they could switch the mesh they were working with at any time.
We had a rig scene per character that had everything in it, and then exported the mesh, skel and weights from it. Im still scared of Mayas referencing.
As long as your rig is a single button operation and your weights are saved you’re generally safe. If the mesh changes you’ll want to reskin it anyways, and if your rig changes you want to be able to batch update it and not destroy any anim data because referencing threw up on itself.
I am dealing with a similar issue right now, but on a much smaller scale.
But I have found the Human IK stuff to be very helpful for this sort of thing.
Not sure if this is at all game related, but I am able to set up a source rig to do all of my animations with and then characters with a skinned mesh that I re-target the animation data over to. http://download.autodesk.com/global/docs/maya2012/en_us/index.html
How do you handle testing animation on a rig, removing that animation, and ensuring you’re back to the bind pose (on rig that a user is testing any number of skinned parts on)? (then repeating that process as often as a user likes in a scene)?
My current solution for managing all the parts is UI based, where you start in blank scene, hit a “bring in the rig” button, then have a list of skinned parts that have been stored in their own scenes that you can import, modify, and save back out to their respective scenes. This system seems to work ok for managing parts/skins, but what I can’t figure out is how to involve animation/deformation testing in the setup. I want the system to be ‘rig-agnostic’, so the user doesn’t have to register anything about their particular rig, more than identifying the bind and control hierarchies. (As in, I don’t want them to have to communicate what controllers can be, or are animated.) The ideal solution would be an addition list in the UI of test animation scenes, that the user can hit ‘play’ (and ‘remove’) on, all while keeping their current parts and weights on the rig clean and intact.
Any input ya’ll have got would totally help! Basically - how do you manage animation previewing in Maya? Load this animation on the rig, now unload it. Load another. Now return to the bind pose. Repeat. Keep everything clean.
Atom and Animation Layers could do this with some work in 2013, Depending on how you reference your animation files you can load/unload references to preview animations … lots of issues that are all fixable, but talk with your animators about what they want and how they like to work now or expect lots of wasted work.
