For our game, we want to build multiple animation scene files for each character, Without worrying about keeping the rigged mesh up to date in every file.
We’ll also be using identical skeletons across many characters, in hopes reusing the animations.
These are all max bones( no biped or CAT)
I’m used to references in Maya, but in 3DS Max…?
Art Director claims to have used xRefs before without issues, but I am reading sooo many posts about xRef Objects being unreliable.
Perhaps the unreliability depends on the situation?
Being new to Max, I am wondering if our situation is one where we ought to avoid xrefs, and seek a custom solution?
I find that XRefs simple do not work when it comes to character rigs. The things that you would want (and expect) to update between files simply do not. On the other hand, XRefs can be viable when used with static assets (e.g., environment assets and props that are not skinned or that are skinned rigidly to a single bone). I haven’t experimented with 3DS Max 2013, so it is possible that the feature has been improved. You might also want to look into containers (although containers too are really better suited to static assets). Generally, I would discourage you from using XRefs for characters. If you do decide to go that direction, you’ll want to thoroughly vet the feature before you commit to it.
[QUOTE=eevans;19884]I find that XRefs simple do not work when it comes to character rigs. The things that you would want (and expect) to update between files simply do not. On the other hand, XRefs can be viable when used with static assets (e.g., environment assets and props that are not skinned or that are skinned rigidly to a single bone). I haven’t experimented with 3DS Max 2013, so it is possible that the feature has been improved. You might also want to look into containers (although containers too are really better suited to static assets). Generally, I would discourage you from using XRefs for characters. If you do decide to go that direction, you’ll want to thoroughly vet the feature before you commit to it.[/QUOTE]
I have to agree with Eric on this. Static sure, but animated assets, I wouldn’t consider it. I’ve mentioned before, it’s been years since we tried to use it and it was nothing but issue after issue including file instability. Honestly, I don’t think xrefs have been touched in years and I’m sure they haven’t been improved upon to handle animation. I was hopeful with containers but it was yet another tool to overlook animation. Currently chatting with some other folks about this same issue on G+. Ultimately, I had to roll my own solution to handling rig updating. It’s pretty straight forward once you have assets authored properly and it helps in so many other ways. I would love max to have proper referencing but it does not and you probably won’t see it anytime soon. Have a look at my demonstration video. If you have questions feel free.
Thanks for the responses, everyone.
Randal, I was actually hoping you’d chime in. The solution you used at volition seems like the direction I may have to go.
I’ll probably have a bunch of questions about your approach once I get into it.
I was hoping that our needs were simple enough that I could avoid scripting some kind of referencing system.
But if xRef cant even propagate a simple change in skinned mesh without errors, I guess we can’t use it…
Randall, I’m reviewing your blog post about the animation manager, and I am working up some questions.
are your animations stored as .max files, or .xaf ( or some other data) files?
does the scene manager actually save/store any .max files,
or is a single scene all separate data files brought together on the fly,
and exported directly as game engine data?
that is to say, the scene never “really” exists as a proper max file, max just uses the data to recreate the scene each time?
I’m thinking that instead of keeping seperate .max files and worrying about referencing,
we can use a single .max file (the rig)
and save/load animations using only .xaf files.
a custom tool roll out would merge in the source rig and load the saved .xaf file
do you see any flaws in this idea?
Each asset ( characters, weapons, backgrounds ) are all individual .max files. The AM brings them all together into one animation scene file. When I swap or update characters or animated items I save out the .bip format for the biped characters and a custom animation format for everything else. Each animated asset has an AnimationExport modifier at the top of the stack for what may be considered the base mesh. We can export each asset animation individually or we can use a Scene Exporter to export each and everyone in the scene automatically.
I think what you are saying is quite close to what I have done using my Asset Manager although I do maintain an actual animation scene file. I’ve considered scene rebuilding on the fly, in the past, but that is a bit more heavy-handed than what is necessary. If you have built in mechanisms for determining if assets added to your scene have been updated in their source location and if your update/swap process is fast and reliable then that would be the best way to go.
This is a great thread. I seriously need to get a way of keeping assets up to date in Max without batching a couple of thousand files.
My first thoughts were roughly the same as outlined above…
add a file link system to the rigs in animation files.
add some scene open callbacks
on open
— save each rig animation out
— delete old rig, re-import new rig (possibly do some checking first if an asset ‘needs’ updating)
— reload saved animation
Yes, it is bit brute force and simplistic, and no where near as simple as its made out, but that should, in theory, get me someway to maya like referencing. There are obvious issue with this of course… speed being one of them. Doing this through maxscript, performance could be horrific.
Randall, I have some questions:
Do you do much in the way of up front checking if an asset ‘needs’ updating or do you always just re-import the data.
How did you manage performance? my tests of file merging can take up to 10 seconds, and then with any post file scripting processes can take much longer. X that by a number of characters and possibly long animations… could be in the minutes territory.
How stable has transferring animation been after you update a rig master file? it seems to be the biggest issue in a setup like this. I think you mentioned you use the biped and .bip format mainly, which we don’t. However, I was just wondering if you hit any pitfalls.
If anyone else has any advice they can bring to the table on this i’d really appreciate it… I’ll be diving into this soon, as I cant take much more batching.
Do you do much in the way of up front checking if an asset ‘needs’ updating or do you always just re-import the data.
Each animated asset has our custom modifier attached to the mesh. This modifier has a simple rig version parameter assigned to it as well as the exported game rig file reference, an intermediate xml format we use in exporting game rigs. When an animated asset is added to the scene it keeps whatever version is currently assigned. On a file post_open callback we can query this parameter in all of the animated asset modifiers within the scene. We can then check a database or parse our rig files for whatever the latest external rig version is. The riggers or Tech Animators will only flip this version, in the base animated asset file, if there is a need for the animation files to be updated in relation to the rig. If the external rig version is newer there will be a prompt for updating the asset. This can be handled automatically or manually of course.
How did you manage performance? my tests of file merging can take up to 10 seconds, and then with any post file scripting processes can take much longer. X that by a number of characters and possibly long animations… could be in the minutes territory.
Most of our current “Setup” files are around 2-3mb in size. These are actually pretty quick and they are initially built in a manner that strips out any garbage not necessary for exporting the character and animation. If you are running batches overnight its rather insignificant but I you are doing one-offs its not more than 30sec - min for our worst cases.
How stable has transferring animation been after you update a rig master file? it seems to be the biggest issue in a setup like this. I think you mentioned you use the biped and .bip format mainly, which we don’t. However, I was just wondering if you hit any pitfalls.
Making sure this was a stable process was the only way it would be sure to be used, so I had to make sure it was bullet proof with every process that I could think of. That started with how every animated asset could be created. This includes characters, weapons, props, and vehicles. There are tools setup to auto-rig almost everything and facilitate properties being applied correctly on each asset type. The tools are also run by the artists themselves so much so that I rarely have to touch the rig on a weapon, prop, character or vehicle, if only to update skin weights on occasion. It’s also been enforced that any Animation or Cinematic scene building has to be constructed with the Asset Manager. It does proper merging and namespaces to avoid name collision errors and skeleton linking issues. While we did use biped I had to write many custom methods for saving external animated rigs and link constraint preservation as bipedal characters were not the only rigged assets.
Having the ability to simplify the creation process for all these asset types made creating the foundation of this much easier and help maintain consistency. That way all the cases you have to handle for saving and transferring animation should be minimal. It is still a poor man’s way to handle referencing but it does work and once you have squeaked out all the edge cases its quite fantastic, for 3dsmax that is.