Animation Library

Quote:

From http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=6839916: "..The Autodesk® FBX® SDK is a free, easy-to-use, C++ software development platform and API toolkit..."

I guess it's fine to use [grin]

You could also try COLLADA, the dotXSI file format (which has it's own library, the SOFTIMAGE|XSI File Tool Kit), the Milkshape3D .ms3d file format, or any one of the myriad custom game/game engine file formats out there (eg. md2 from Quake 2, md3 from Quake 3, md5 from Doom 3, etc.)

As far as I can tell, FBX and dotXSI are both closed formats and you have to rely on the SDK provided by the format's owner. COLLADA is an open standard and vendor-neutral (so there's a better chance of it being supported well in multiple programs (Max/Maya/XSI/Blender/etc), though that may be irrelevant if you only ever use one of them), and there's a couple of cross-platform open source implementations (COLLADA-DOM, FCollada) which seems nicer than relying on a binary SDK (especially where the vendor might decide to drop support for it, as with e.g. Gmax).

None of those three seem particularly suitable for loading into a game, since they're too general-purpose and don't have the focus on efficiency which games typically need. MS3D/MD5/etc seem more suitable there, though it may be worthwhile to just make up your own format to suit your engine - use a standard format like COLLADA to export and process all your data, then write a converter to change it into your engine's format, and the engine can load it very efficiently (assuming you design the format to match the engine's requirements). The conversion can be done automatically (and then cached) by the game so that it works transparently for artists. At least that's what I've been doing, and it seems to work alright so far [smile]

Quote:

Original post by Excors ..FBX and dotXSI are both closed formats...

Can't speak for FBX, but dotXSI comes in two flavours: binary and ASCII. Worst comes to the worst, you can write your own reader [grin]

Writing a COLLADA -> [Your own file format] converter sounds like an excellent way of doing things, though.

I also recommend using Collada. I'm currently using the Collada DOM approach for basically all of my asset imports.

I should warn you, though, that Collada is a very flexible format. For a given piece of data, there are usually a number of different (and valid) ways of expressing the data, and which way it's expressed can depend on how it was built, and which package it was built in. After you get your initial Collada reader working, expect to need to update it to accomodate this.

thank you for this information