Decent animation formats

Started by
4 comments, last by L. Spiro 9 years, 9 months ago

Well met!

I implemented .md5 as the (bone-based) animationformat for my engine quite some time ago, but I need something a little more up to date now (which supports scaling as part of the animations and subsets with independent bonegroups).

I was looking through formats used by big companies (Blizzard, Riotgames, ...), and all of them obviously have their own. I was hoping to be able to find specifications for those, but no luck.

What formats are you using and which ones would you suggest for a 3D game with mid-level graphics (compareable to the new WoWs)? Any good tutorials on implementing one/writing your own, or specifications for a decent one?

Anything will be highly appreciated!

Have a nice day!

Advertisement
If it is an animation engine it should support bvh animation also. You can use xml to store animations of you want (your own language). I am actually looking into learning how to make my own "markup language".

http://en.m.wikipedia.org/wiki/List_of_motion_and_gesture_file_formats

http://en.m.wikipedia.org/wiki/Rich_Representation_Language

http://www.sciencedirect.com/science/article/pii/S0920548903000710

They call me the Tutorial Doctor.

First, I would recommend the approach of designing your own custom format (binary data is normally faster, for instance) for loading into your app. That custom format should be designed for efficient loading - both in time and matching the internal format of your stored data. I find that most available modeling program export formats don't entirely meet the needs of my app. E.g., the data is arranged differently than I desire, or my code has to process or combine data to fit my app's storage scheme. And, often, export formats are text-based (.x, xml, etc.) which can be more efficiently loaded in binary format.

If you create a custom format and use that for loading animation data into your app, you'll have to code a converter to read/parse/process modeling program each desired export format to your custom format. Even if you use only one input format, loading efficiency can probably be improved by that conversion.

In addition to loading data more efficiently (as mentioned), that approach provides the means to use different modeling programs which may or may not export data in a "common" format. Further, in the past, I found that different modeling programs export files in a "standard" format (.x, md5, etc.) but the contents differed either in arrangement or actual data content. Another benefit is to reduce the need to revise your graphics app if you want or need to revise the conversion process. Your graphics app can have a single loading routine - good for debugging!

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

For production I would use an interchange format with support for the features that I need, and for release I would serialise the game objects to data files, which are more direct.

- http://gamedev.stackexchange.com/questions/4202/what-is-serialization
- http://assimp.sourceforge.net/index.html
- https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F

The ideal model format is one that you can load directly into your vertex buffer at creation time and without any intermediate processing required. When players load a map in your game, they like it if the map objects can load fast rather than having to sit waiting and watching a progress bar creep along. For D3D11 that might be accomplished by memory-mapping a file and passing the resulting pointer as the pInitialData::pSysMem parameter to your CreateBuffer call (you might include a simple header describing the vertex format, number of vertices, etc). For model loading parsing == death.

By all means use a more flexible format for development, but when it comes to production, load it fast and your players will be happier, even if it means accepting the tradeoff of a larger file size.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

What formats are you using

A format that I made for my engine specifically for my engine.

which ones would you suggest for a 3D game

A format that you made for your engine specifically for your engine.

Any good tutorials on implementing one/writing your own, or specifications for a decent one?

Learn the FBX format and make a converter.
I have no tutorials because when I have a problem I ask on their forums.
I am currently writing a chapter on this for my book but it is not done so I don’t have anything to share at the moment, but maybe later.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

This topic is closed to new replies.

Advertisement