When loading animation from a characterized skeleton stored in an FBX file onto a characterized skeleton in Maya (using the FBX importer with the “Update Animation” option active):
No re-targeting or re-mapping of animation curve<->nodes relationships takes place (based on the characterization present in the FBX file and in the Maya scene)
Animation curves are simply loaded 1-1 and all node names/namespaces need to match.
This is true of animation on any set of nodes. Whether they be a skeleton or the HIK rig.
Thus to bring in animation onto a character that is different in structure, naming and/or proportions from that in the FBX file:
The animated skeleton need to be brought into Maya, where we can now re-map/re-target the data using the HIK tool set.
Correct- you could try creating a reference of the fbx file, do a retarget and then unreferenced. fine for a one time deal.
Or you create a dedicated retarget file with a source maya skeleton that has a character node on it (no need to have the HIK rig), to keep the scene clean that matches your source skeleton so you can “update animation” on to it directly and then use the retarget system to get the animation on to the new character.
I would most likely do this if I was re-targeting in Maya so that I could then batch the retarget via script.
Definitely go for a remapper file with the base skeleton setup then just import the fbx data onto this, far easier to manage. Yes you could reference the fbx in, load in a rig that’s driven by the HIK remapping and then connect the new animation up as a source to the HIK, but it’s far easier having a file already setup and just importing the FBX files onto the source directly.
One good pointer here is if you’re intending to do this, make damn sure you make the remapping skeleton unique in name… FBX is node NAME based. We always prefix our moCap files with FBX_DATA_jointname that way there is only ever one skeleton in the scene that matches the incoming FBX data.
As for pre-processing a bunch of animation, option 2 sound like the way to go and we already have batch tools in place for that in MotionBuilder. What I’m looking for is a way to let our animators bring in/out animation on any character they like, with either Maya or MotionBuilder, on demand. MotionBuilder obviously does this pretty well through loading/exporting animation through Story. For Maya a convenience Animation Saver/Loader that automates your option 1, sound like a plan to me.
It would be nice if we knew beforehand what namespace and skeleton is in the FBX file we are dealing with is. If the skeleton is different, we do option 1. If it’s the same we need only load animation. One obstacle with loading animation 1-1 obstacle is making sure namespaces match. I’ve found no good way of changing the namespace in the incoming FBX file (only including what’s already there in a parent namespace), but we could temporarily change the one in Maya to match the one in the file.
Any idea of how to query the content of the FBX file, short of using the limited FBX plug-in MEL query commands or using the FBX SDK? (We save as Binary and plan to keep doing so). I would likely tag all skeleton types with a custom attribute.
How would you use the re-mapper in practice? Would you pre-process all you animation data and save out unique FBX’s for all your animations * skeleton types? Or would you launch the re-mapper on demand in Maya batch mode?
I do like me some Live Animation Binding - Thanks, that was worth a re-watch I do plan to use something like the binders once it comes time to drive our custom Maya rig (Unless Characterizing it does the trick).
As far as loading any characterized FBX animation (with any origin) onto our characters on demand, I’m not sure a separate mapping file would be useful. For batch/pre-processing of animation surely, but that’s already handled in our MotionBuilder pipeline.
So as I’m not looking for a good manual workflow here, just a shopping list of stuff to wrap in a script, I’m going to assume that referencing the animated skeleton into our animation scenes, doing a re-target/bake and then un-referencing it, will be the way to bring animation from FBX files onto our characters in Maya - Unless of course someone can make me understand why doing it otherwise is better
Thanks for the plug!
I think there is a neater way in the HIK retarget and changing the source to the HIK input, but we’ve not really pushed it in development. For us the remapper file has worked for 10years and is all automated so not a huge point in investing time, but I do intend to look at this with fresh eyes when I get to Crytek! The one thing I still like about the remapper method is just how easy it is to manipulate the data once it#s being driven as it’s all live.
Currently we just load the Remapper file up, drop the FBX into the scene (set to update only) and the rig comes to life. So as for batching we just load the remapper, import the fbx, and do a save (with options to bake and clean the scene), and that is just a task in the Batch so we just point it at a folder of FBX files to map.
Btw. do any of you know where to find a list of all the HIK node id’s (You know the ones you’ll need to set up custom rig mappings, UI configurations and node connections)? Short of looking at the Character Node in the attribute editor and gestimating that is.
[QUOTE=Sune;17667]
It would be nice if we knew beforehand what namespace and skeleton is in the FBX file we are dealing with is. If the skeleton is different, we do option 1. If it’s the same we need only load animation. One obstacle with loading animation 1-1 obstacle is making sure namespaces match. I’ve found no good way of changing the namespace in the incoming FBX file (only including what’s already there in a parent namespace), but we could temporarily change the one in Maya to match the one in the file.[/QUOTE]
I’m hoping somebody can figure out a way to “swap” namespaces; import animation saved with one namespace onto a skeleton of another namespace. Barring that, my solutions have been to save without a namespace. It is possible to import/merge from an animation file that has no namespaces onto a skeleton with a namespace. You can do it from the import UI, but the UI does not echo the appropriate commands so to replicate via code, takes some shenanigans. Have to use ‘namespace’ command to set the namespace you want to import onto, mel.FBXImportMode command to set “update” (‘exmerge’) and mel.file command with ‘type’ and ‘namespace’ set:
The other workaround is ATOM seems to load onto a skeleton even if it was saved with a different namespace.
Still testing these two solutions to see which is better. ATOM is leading as it means to save out the animations, the export/saving process does not need to be destructive like the FBX export does, because we have to strip the namespace which in our case means loading the reference into the scene and moving namespace to root, etc. (Unless anybody knows a way to swap the namespace of a reference?
FBX isn’t namespace dependent in that it doesn’t consider namespaces in the load, or as far as I’m aware it doesn’t, it’s pure short node name matching. This is both useful and a pain at the same time as you can’t guarantee what skeleton in a mutli character scene it’ll pickup, it just loads to the first node Name match it finds. This is the reason we prefix, not namespace, our delivered fbx files so we have a unique ID on them.
Are you running a binder or loading to HIK rig? If you’re running a binder with a source skeleton then maybe consider referencing in the fbx then just doing a copyKeys from that fbx to your binder’s source skeleton (Red9 has a copy function with match that’s perfect for it
Or are you saying that by setting the active current namespcae FBX loads into that? If so I need to do some testing as that would be useful for multi-character scene cases.
[QUOTE=Mark-J;20332]
Or are you saying that by setting the active current namespcae FBX loads into that? If so I need to do some testing as that would be useful for multi-character scene cases.[/QUOTE]
Yep. You can merge into a namespace if you use that hack I pasted above.
ATOM is better because you can save/export with a namespace and merge back in onto any namespace you specify.