In the process of writing my game prototype, I have found the OBJ format to be insufficient for my needs - it does not support any sort of animation, it doesn't support triangle strips (I'm targeting my ancient hardware). MD2 wouldn't fit the bill because it doesn't have support for named model pieces. MD3 would probably work, but like OBJ, it doesn't have support for triangle strips. Considering the limitations of the formats above, I've come to the conclusion that it may be necessary to write my own format to accommodate my requirements, but that feels like reinventing the wheel.

So, I need a format which can specify indexed tri-strips, supports textures, UV-mapping, collision data, can have multiple named segments and supports animations (have I forgotten anything?). Is there any format like that which already exists, or do I have to write my own?

  • 2
    \$\begingroup\$ You have some answers below so Ill just chime in with a quick: You will generally want to keep your model data and your animation data and the like separate.. Maybe closely related/named files, but if you ever need to change things, its nice to have one thing not require the change of many.. For 'Production' vs 'Development' assets you could always combine all your raw animation, model, collision data, etc.. into a single concatenated object, but that level of asset processing may not be immediately needed either. \$\endgroup\$ – James Jan 7 '11 at 23:14

I won't refer to any specific formats, but here's points for your "yea or nay" question:

Reasons to use custom formats:

  • Speed up loading of your game
    • Can do all preprocessing your heart desires and store the results
  • Support for features not in generic formats
  • Doesn't include anything you don't want to
    • .3ds, for instance, has tons of stuff you'll never need, but will add to your binary size
  • Slow down or stop content alteration / stealing
    • Some consider this a plus, ymmv.

Reasons to use generic formats:

  • Support built-in in modelling packages
    • Be careful to test the actual support though. The actual quality of COLLADA support varies from one package to the next, for instance. Most formats supported by Blender don't include bones, even if the format would support them, etc.
  • Can (possibly) use existing loading code made by other people
  • No need for additional build step (conversion from generic format, preprocessing) or custom exporters
    • Supporting custom exporters can be a huge pain

There are data structures in meshes that work best for development and others that are more optimal for loading. In the development phase generic formats can speed up production and creation of assets.

In the final stages of development closer to completion, start optimizing for load times. When all your assets are final use a custom-made mesh exporter to convert your meshes off-line, and use those converted meshes for the final game.

A mesh file that is most optimized for fast loads would have its data aligned exactly as it is in whatever kind of vertex buffer you use in your API. It would be a simple copy operation and it's done.


Never used it myself, but there was some interest a while back (or maybe still is) in Collada. Projects I've worked on have always rolled our own export formats, you'll always have exactly what you want that way, just depends how much work you want to do.


I'd look through the standards first, just to make sure; but if your needs aren't being met that may be a decent solution.

Check out FBX, I've been working in XNA and so have been kind of bound into them (or .x but we had difficulties with that due to Maya). They are a bit of a headache at times, but I've been told they support animations well, and I have seen evidence of the ability for named bones n' the like.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.