It kind of stinks no matter what, since youve got to nearly double your workload to support both packages.
It’s very frustrating to attempt any kind of bi-directional workflow in which data gets round-tripped fom max to maya and back – the process is irritating enough if you have just geometry to worry about; if you also have things like custom object types or data stored in attributes its wonky in the extreme. Material settings are hard to coordinate, and sis skinning – if people are trying to modify skinning weights on both ends at the same time, its going to be a lot of work for little benefit.
You can probably take work from outsource animators and import it into max as baked animation data – but you should assume it’s going to be like working with mocap. Trying to create a real rig that has the same controls and meanings in both packages is a fast trip to crazy land – even after all this time the FBX guys, who are supposed to that for a living, can’t do it reliably.
If you really have to do this, I’d try to export skinned characters from max to maya as fbx’s and then have the outsources create a rig that animates those. They return a new fbx of animated bones, but with no rigging data and the skins are intact; import the fbx into max as if it were mocap and then work with it accordingly (animation layers, assume that rotations have have gone euler-flip crazy, data on every keyframe, etc).
If your engine reads fbx’s directly the whole thing might be easier – it’s at least conceivable that they can export animations and see stuff directly themselves without sending things back to max for re-export.
You’ll need tools to make sure that the skeletons match up on both sides – don’t want animators working on bones with bad names or accidentally reparented. Also tools to completely take away user options on the fbx import-export size: get unit scales, time scales, axis orientation, etc correct once and then don’t let users touch it manually…ever!. You’ll also need a system to track when base models have changed in ways that might require re-exports (and which knows what files need to be re-exported) Maya 2011+ lets you reference FBX files; I have no practical experience with that but it’s certainly worth investigating as a way of keeping the problems all in one place.
Minor hassle will be textures, if the animators care about those, you’ll need to work out a system for giving them proxy textures so they don’t get a zillion missing texture messages every time (or, have your max > fbx > maya pipeline just strip the textures on export since they don’t really need them – that s a cultural thing, if the animators really demand it you’re in for a lot of extra noodling).
Make sure you know how the engine binds animations to characters in-game – if it’s a name-based thing the check is easy (but of course, it will break all the time because of maya’s habit of renaming stuff). if it’s attribute-based, make sure to test the pathway thoroughly since fbx likes to rename attributes.
sigh
If it’s culturally possible, it’s safer for the long run to use just one package. It’s certainly easier to build the whole pipeline in Maya and let modellers create geometry in max and import that for final prep / export, or to support static FBX model export from max… Geometry is easier to support on two ends than animation, so build around the animation problem.
