A Question on Exporting Bones from 3ds Max

Coding
#1

Hello,

I’ve just graduated from University and I’m considering attempting to create my own auto rig script which would be for the games sector. Unfortunately my knowledge of exporting Bones into engines is very limited so I have a few questions which hopefully some of you could help me out with.

  1. Do the bones have to be Bones objects or could they be made of, say, Box objects with “Bone On” checked in the Bone Tools dialog window?
  2. Do you need a Bone to be the parent of the entire hierarchy or can this be a Spline object (which is what I usual use)?
  3. I’m assuming that you can have hierarchies like Bone > Helper > Bone and when you come to export the rig it will just export the Bones?
  4. I noticed in the CryTek documentation in the CryTek Animated Geometry Files section it says that objects need to have TCB animation controllers, does this apply for Bones too?

Are there any other tips that anyone could give me for creating a rig for export?

Thanks,
-Harry

#2

Depends on the game engine and tools. For instance havok hkt files, exported from max, doesn’t care what node type it is in max. It just goes by names in a text file and dumps out the transform animation.

Ive worked in studios that specifically looks for maya joints, so you could have an exporter that only looks for bone types or helper types, depends on the setup. It’s really per engine/studio that this stuff gets worked out.

#3

I’ll answer the questions specific in my studio (proprietery engine and tools), but keep in mind as andylt1 said it Depends on the specific game engine and tools.

  1. Do the bones have to be Bones objects or could they be made of, say, Box objects with “Bone On” checked in the Bone Tools dialog window?

We use bone objects. Some reasons include
its what they are designed for
visually obvious to others
no worries about rendering or exporting as something unintened
easy selection / display filtering

  1. Do you need a Bone to be the parent of the entire hierarchy or can this be a Spline object (which is what I usual use)?
We use a root bone at [0,0,0] for any skeleton.
  1. I’m assuming that you can have hierarchies like Bone > Helper > Bone and when you come to export the rig it will just export the Bones?

definitely depends on the engine / tools
In our case, we export continous hierarchy of only bones
but I do see a possible red flag:
Chains like Bone > Helper > Bone indicate you are mixing the exportable, skinned bones with the animation control rigging.
I recommend following the advice in TD Matt’s blog:
seperate your skinned exportable bones (bones that are skinned/ export )
from your animation rig ( never exported bones and control shapes that are rigged for animation)
use the animation rig to drive the exportable rig via orient (and maybe position) constraints.
this is something i learned the hard way.

  1. I noticed in the CryTek documentation …

no Crytek experience, but the TCB restriction does not appear to apply to crytek’s CAF (skeletal animation) files.

#4

++ to Mambo’s point about keeping controls separate from data . Always make a clear distinction between what the engine cares about (usually a very small set of things: bones, skins, maybe marker objects) and what the artists care about : rigs, controls, construction history and so on.

The real job of the exporter is to filter out all of the ‘artist only’ information leaving only what the game cares about. Ideally the separation should be as transparent for the users as possible. If they spend a lot of time moving things into layers or whatnot to prevent them from exporting, that’s time they are not spending making art. Wherever possible the details should be hidden from the user; things that you’re sure you never want should ‘just work’. If there’s ambiguity - say, they want to put an object in the file for scale reference but it should not export, give the user a clear way to tell you that it’s not supposed to be exporting (for example, they could freeze the object). The key thing is to keep the amount of fiddling the users must do to a minimum. You’ll find this is easier if you ask them for explicit instructions about big things - is this a character or a vehicle? is this an animation or a light rig? and then making all the smaller decisions as automatically as possible based on that knowledge. Life is always better when the artists are telling you what they intend instead of you trying to guess.

The other thing to do is to allow the artists to focus on the needs of making art, not formatting things for the engine. For example, your engine may want all rotations as quaternions - but most % of the time your animators will want Euler f-curves. Don’t make them use TCB to make your own life easier. Formatting the data for the way the engine wants it should be done on the import side - in the engine, or ideally in a tool which reads the exported, filtered-down data and does whatever you need to make the engine run. Things like byte ordering,

Talk to the engine programmers, find out what data they expect to see, then figure out the simplest, most robust way to map that onto stuff artists can see. Talk to the artists and find out what they want to do. Identify the key decisions the artists are making (‘this is a character’ or ‘this is where the backpack is supposed to be attached’) and make them clear to the artists with UI and clear to the engine in the way they are expressed.

#5

In addition to what others have said, if you’re new to working with exporting data to real-time I would recommend working with a few existing auto-rig scripts including Max’s Biped - finding some test data and looking at what you get in some engine’s of choice. Look at what shows up in engine and ask yourself whether it’s necessary and what you’d improve. Another angle you should consider is how easy a rig is to update and preserve information across existing files using the rig. It will be hard to pre-anticipate every rigging need , but at the very least having a flexible format that can be updated across files will be very important for a production pipeline.