What experience does everyone have in referencing rigs in your animation files?
I’ve toyed with it in the past but never actually done it, so I was wondering what the pitfalls are with this practice, as well as wondering how common it is to do.
Thanks!
Back in my rigging days, I ran into a few issues with referencing rigs. It wasn’t alot of issues, but a few show stopping ones that broke alot of things. The biggest thing is don’t ever assume that a “simple” change to the base file will propagate properly to the files referencing. Example (I work in Maya, so this is all assuming Maya rigging, xsi or max probably has a ton of other issues( or not :D:)):
i have a skeleton (file 0) that i reference into a file where the rig is applied (file 1). This rigged file is referenced into an animation, so now i have a 2 deep referencing chain(file 2).
Break case 1:
I change the hierarchy in file 0. Adding a node onto the end of a chain usually isn’t a big deal, but adding or changing the position of a node already in a hierarchy potentiall causes some breakage. Even if you try to recreate the original hierarchy through careful parenting and unparenting, there is no guarantee that the changes will propagate properly
Break case 2:
I change the controls in file 1. Opening file 2 or any other animation that references file 1 has missing connections, which can sometimes be fixed by unloading and reloading the reference. The most common occurance of this is constraints. Constraints would get either not connected or connected improperly, which would cause your animation to look broken. all the data is STILL THERE, it’s just not flowing in and out of the right ports.
I think alot of these could be avoided by not changing the files in the referencing chain, but i’ve never been comfortable with the idea of locking rigs down, limiting the animators, that sorta thing. . .Things like this are why many people (including us) have written their own versions of referencing like systems for Maya.
We used this for nearly all the animations on ETQW using Maya 7, and as far I know we had no issues - I wasn’t an animator on that project though, so there might have been some stuff I wasn’t aware of.
I’ve been experimenting more with it recently, and have had multiple rigs referenced into a master file, which was then referenced itself into animation files, and everything was great, even after I made changes to the rigs / skinning / meshes in the “master” master files.
Sounds like Seth has more experience with this though, and knows some cases which break this 
I think the approach of keeping everything in a canonical rig file vs having a skeleton that is referenced into another file where rigging is applied would solve alot of problems as well. Every time you reference something you create a layer that attributes flow in and out of for the purpose of reference editing/locking/etc(simplified explanation) and the more of those you have, obviously the more chances you have to miss connections:x: Keeping everything in one file that gets referenced out is probably a better way to go, and as long as you have a toolchain the allows for quick and easy rig updating/retargeting you’d be good to go there.
I assume you are interested in doing this with Max. There are many issues with Max’s xRefs sadly. I don’t think anything has changed in the past few versions.
I have no experience with this, but I had this bookmarked, hope it answers some questions:
http://forums.cgsociety.org/showpost.php?p=4013757&postcount=9
Paul Neale might be another good resource, I remember him posting on this subject on cgTalk a while back.
3dsmax’s xRefs are a horrible, crippled mutant child compared to Maya’s References, in my experience. Very unreliable.
It’s a real pain to use 3dsmax’s xRefs.
max xRefs can be used selectively but they are a pain to work with and don’t let you have control over what is going on like maya does.
also with out an ascii format to be able to go in and fix something by hand if a ref. goes bad like you can in maya, it makes max even more unreliable.
… Maya refs are solid and stable but nested refs are still tricky and if you don’t understand what is goign on under the hood with the file refs and make sure you have proper workflow and procedures in place it can make things worse. LIke you don’t want people just useing what ever settings they want when making the refs… know why you want to use them and then test the situations.
Feel free to smack me, but isn’t it a bit of cart before the horse?
Wouldn’t you want to ref the mesh onto a rig? This is from a “what changes
in production” point of view. Typically the geometry undergoes many revisions
whereas the rig is usually stable-ish.
I supposed you could have a ref rig and ref mesh sandwiched in a third file.
In the ideal world everything you re-use would be a reference on some level.
I assume in the max world, to get past the reference limitations, most studios generate the rigs procedurally ( a modular system ). In the event that something needs to change on multiple characters you can have tools re-generate the rig and re-import the skinning and mesh data into a new file. This seems like an OK solution if the system could account for custom rig edits built on top of the generated rig.
I really wanted us to do something like xref skels on Crysis, but ran into some problems. That was max 7. I just noticed this is possible in XSI (we use both) and I was going to try again in max this week. (2009)
[QUOTE=TechChimp;1026]Feel free to smack me, but isn’t it a bit of cart before the horse?
Wouldn’t you want to ref the mesh onto a rig? This is from a “what changes
in production” point of view. Typically the geometry undergoes many revisions
whereas the rig is usually stable-ish.
I supposed you could have a ref rig and ref mesh sandwiched in a third file.[/QUOTE]
It’s a good concept, but I’ve found in practice it doesn’t work so well. In Maya, while referencing rigs is fine, if you reference in the geo and then bind it, there are to many dependencies at that point: What happens if the modeler updates it? You binding, just broke. Plus, based on the way that Maya applies deformers to a surface, it has to modify said surfaces. But… references are modifiable only to a certain extent, so you end up writing custom code to fix shader assignments to the new deformable meshes, et-all. Plus, if you export from this rigged file to the engine (presuming you’re making games), what happens if the model gets changed to some wip version, or the textures get goofed, and the game conks out based on the dependency’s? Need to have more checks and balances in the pipeline.
I’ve been doing rig referencing for a long time: We have mel\python code that brings all the components of the rig together: geo, core rig, rig components, binding, textures, etc, and saves that to our ‘rigged file’. Then the animation staff references that into their animation scene files, and goes crazy. We can then modify the rig behind the scenes (updating geo, controls (add, don’t delete…), binding etc, and it’s seamless to the animation staff. Proven workflow 'round these parts.
Sorry to hear about Max. I could not live without referencing.
[QUOTE=AKeric;1285]We have mel\python code that brings all the components of the rig together: geo, core rig, rig components, binding, textures, etc, and saves that to our ‘rigged file’. Then the animation staff references that into their animation scene files, and goes crazy. We can then modify the rig behind the scenes (updating geo, controls (add, don’t delete…), binding etc, and it’s seamless to the animation staff.[/QUOTE]
I realize that this is an old post, but I figure it’ll still be referenced often enough to ask…
How many of the above listed components reside in separate files?
Which of those files are Maya scene files, or something else? (i.e. raw data, etc.)
Are all of the Maya scene file directly referenced by the ‘rigged file’ or are there any cascades of referencing going on?
No need to get to specific about data file formats and such. I’m really just looking for a functional overview of a Maya based system that works well in production.
Thank you to everyone who has contributed so far.
-AN
Our simple rig gets referenced (w/o namespace) into every animation file. That way the only thing that exists in each animation scene is the actual animCurves. Then when the rig gets minor updates it propogates to every animation.
Seth is right though, if you change the name of a control that an animCurve s connected to, it will break. This is easily reconnected w/ batch scripting, however.
One of the little annoyances of doing this is that all of the rig elements are locked so sometimes you’ll want to tweak a visibility or other minor node adjustment on the rig in your animation file but Maya will not let you as all nodes referenced are ‘locked’. You’ll need to simply put in some kind of switch in the original rig file and reload your reference to get this functionality.
Like Eric says, we could not live without referencing. It is extremely powerful and a wonderful time saver.
We too reference all rigs and props into anim files. The riggers run a master rig file which has several levels of referencing to keep things nice and easy to update and tweak their side, ie the skin file is referenced and easily switched.
They then publish the rig which flattens all of the referencing, cleans up and checks everything to produce a final anim rig. It’s this published rig that the animators take via our custom characterManager which has a lot of extra namespace handling to ensure things don’t break.
[QUOTE=Count_Zr0;4042]
Seth is right though, if you change the name of a control that an animCurve s connected to, it will break. This is easily reconnected w/ batch scripting, however.[/QUOTE]
This is actually not the case if you run characterSets… Attrs linked to characterSets are broken into placeholder lists and as long as the order of these lists don’t change, you can rename at will. This has saved us on many occasions. That said you have to be very careful to maintain connection order.
yeah Mark do you have any tips on how to manage that order? we tried to user chracter sets agian because of animation request and also reference protection but I found it very hard to control the building of character sets so they stayed the same.
Were you building them in the anim file or in the rig file (ref. in with char sets.)
NEVER build or add to the characterSet in the referenced file, always do it in the master rig that’s being referenced. As for the order of the chSet this is a nightmare! There’s no support in Maya to store the order out so we had to do a lot of digging. Here’s the general rub:
The characterSet is broken down in the saved file into 3 lists, angular, linear and unitless and the order of these is as found by the index in the characterSet… be careful though, when you query the characterSet member list it’s actually random, you need to find the index’s and look at the plugs from them. You’ll also see in the file a characterMapping and aliasAttr entry. The characterMapping is the actual store for these 3 lists and as long as they’re consistant, all is well.
Since Maya 2008 they added another level to this, a placeholder list which is made up from the 3 sets above. Theres a bit of a black box here that we guest and it seemed to work.
Since 2009 they fixed another bug which means that as long as the names match, the order of the chSet is no longer as important when referencing.
Hope that helps
Mark
Holy Hell! no wonder, Thank you Mark-- you are master of the trax/char set system and still one of the only people I know that has got it figured out.
Thank you! It was making me crazy that it kept reordering everything no matter how I seemed to try and build them, and then I ran out of time to work out the issue. And glad to know its fixed in 2009.
So for 2009 I should be able to rebuild the charSet and it will not Fubar the animation correct? yes I am double checking.
Pretty much yes, there are still a number of issues that Autodesk are working on, but 2009 fixes most of them. The best thing I can say is save a simple base file out with a chSet as an ma, look at how the data is store ( characterMapping and placeholder) , then reference the file. The connections are always via the placeholder.
Hi, maybe I misunderstood some of this. But it sounds to me that all of the above mentioned animation teams are working in a 3D application when animating? Or at least this is required for a good reference system to work. I’m asking because most animators here works in motionbuilder.