We are going from Max to Maya. In max any transform in a hierarchy can be a ‘joint’.
We are transferring rigs from Max to Maya via FBX, for one project which is a sequel, we need thousands of animations from very custom Max rigs to be able to load and work in Maya.
I am trying to work as general as possible. One thing I noticed is that when looping through ‘skeletons’ and hooking things up with msg attrs/nodes, if there’s a non joint in the deforming hierarchy, it puts this attr on the shape node as well. As you can imagine there are other issues…
Should I convert all curves, geom, etc… any transforms with shape nodes to joints or empty groups when i convert a deforming skeleton from Max to Maya?
If the extra objects are actually deforming something then yeah, it needs to be a joint.
It’s technically possible to keep controls and other junk in the middle of the joint hierarchy, but I use parentConstraints as much as possible. This lets you keep an object outside of the hierarchy, but still behave as if it was.
Another thing we do is we have a super clean export skeleton, which is the skeleton that gets bound to the skin and exported to the game. And then as a totally separate hierarchy we have the animation rig, which has all of the extra joints for IK FK and other stuff, and then you parentConstraint the 2 together.
[QUOTE=lkruel;11956]Another thing we do is we have a super clean export skeleton, which is the skeleton that gets bound to the skin and exported to the game. And then as a totally separate hierarchy we have the animation rig, which has all of the extra joints for IK FK and other stuff, and then you parentConstraint the 2 together.
[/QUOTE]
This is the way I’ve always worked when rigging in Maya as well. Don’t get to do much of it though as most studios use MoBu.
Another thing we do is we have a super clean export skeleton, which is the skeleton that gets bound to the skin and exported to the game. And then as a totally separate hierarchy we have the animation rig, which has all of the extra joints for IK FK and other stuff, and then you parentConstraint the 2 together.
This is the way I’ve always worked when rigging in Maya as well. Don’t get to do much of it though as most studios use MoBu.[/QUOTE]
I think this is the best approach with anything real-time, Max or Maya. You have the deformation skeleton, pure joints without any sort of rigging, and another hierarchy with all the controls over it to drive this deformation skeleton for the animator to work with. Before exporting, just collapse/bake the animation to the deformation skeleton and that’s it.
It was a long time ago I tried to export a fully rigged character into FBX, I dunno what comes out of it from Max to Maya these days. You could try to delete all non-deformable objects from the scene before exporting to FBX. If you want to export also the animation, you can use the Collapse Transform on the Motion panel before deleting the non-deformable controllers.
If you want to do that automatically you will have to write your own “collapse transform”, because it’s not exposed in Maxscript. But it’s not difficult to do it anyway.
I’m actually writing support for this collapse from/to both rig and skeleton on my autorigger, so we can move animated characters from Max to Maya and vice-versa.
Chris, I can only say you are looking forward to some serious amounts of pain.
We decided to redo all when switching to Maya for animation. Old animations for legacy skeletons (if they are still needed) go thru the old pipeline from MoBu thru Max. Our MoBu/Max pipeline was fully based on constraints from the “animator skeleton” to the “game skeleton”, so no news there.
Hey guys,
This is also something we are venturing into as well. I’m trying to come up with a good way for data transferring characters between DCC apps. Obviously, we are only concerned about mesh/uv data and bind bones as the control rigs will be constructed in Maya.
FBX seems the likely solution for most of it but my main goal is maintaing metaData. I was curious if you guys have any experience with this. I was alternatively thinking of doing some database storing and polling between the DCC apps to transfer this data if needbe. However, my concerns with aligning that data based on named objects is really in question here. I know Maya doesnt care for certain characters in the object names so I may need to avoid relying on object names.
Define your own ‘format’, which can be existing geo/anim formats bundled with some additional metadata, or your own entirely custom formats (which I’d suggest in many cases). Export everything, import everything. Moving data from one package to another in one shot isn’t really difficult. Trying to maintain a link between the two and being able to work in both, especially on the same assets, is not something I’d want to attempt and can’t see a real need for (and I’m not sure it’s been asked for in this thread, just saying).
>>Moving data from one package to another in one shot isn’t really difficult.
Yes and no… if your alien rig has custom bezier spline IK tentacle limbs, scripted/built in Max by a guy no longer at the company… gonna be somewhat difficult to port that over to Maya
We had to do something similar on a project once before where we were trying to get stuff from Maya into Max. We never actually went through with this part, but here was the theory in a nut shell and you can see if this would work for your pipeline. We found a plain skeleton could go over pretty well from one program to another, back and forth. So the idea was make a base transfer skeleton for any animation that needed to go back and forth. (At this point I should note we needed to work in Max because that’s what the engine used, but all the animators wanted to work in Maya.)
The idea was to get that base skeleton to follow the original animated rig via constraint and then bake out the animation on it. (If the animation exported over ok, even baked, we could skip this step, but that wasn’t always the case.)
Then we would take our new rig in Max, import in our transfer skeleton with working animation on it, and constrain the new rig’s controls to follow the animated one we just imported in. Then we would bake the animation onto the controls, which makes a mess yes, but then the idea was to handle it like it was motion capture data and use a reduce filter to clean up the keys and cross our fingers it was close enough.
After all that, still, you start going is this faster/cheaper than re-animating everything? But if you were able to script it and the reduction turned out ok, and the keys were still editable, maybe.
