I wasted most of today to do in depth research on available 3D formats and their suitability for libgdx with regards to mobile platforms. Here’s what i checked out:
- Imagination Technologies POD format: straight forward, SDK tools come with collada2pod tool. No other tooling support. Binary.
- MD5: well, we know that already, tooling support is somewhat OK. Text-based.
- MD2: easy to parse, but not flexible at all and no good tooling support anymore. Binary.
- DAE (aka Collada): oh god, please. No. Great tooling support though! XML-based
- 3DS: haven’t looked to closely, but seemed straight forward to parse for the most part. Great tooling support
- OBJ: static meshes only. Great tooling support. Text-based.
- a shitton of other options that all seemed to be worse than the above
From the lot above POD was the one i could sympathize the most with, but the missing tooling support makes it a pain in the ass workflow wise. DAE is a well supported standard, but a big bloaty XML abomination i would like to avoid if possible. Nbf of l33tlabs uses it via a custom parser, only fetching what he actually needs. That sounds like a viable but fragile option. 3DS and OBJ are fine i guess (in the later case only for static meshes of course). But i decided against all of the above. So here’s what i’m going to dedicate the next few days/weeks to.
We’ll use the Ogre XML format for meshes and skeletons. It supports everything we’ll need (shitton of vertex attributes, different face types, skeletal animation etc.) and is extremely easy to parse. It also has great tooling support (though Blender 2.5 seems to be lacking a little, the JME guys figured out a way to get the exporter working though).
Now, being an XML format it’s of course problematic on Android. So instead of having direct Ogre XML support in the libgdx core we’ll create an extension that will convert the Ogre format to a custom libgdx binary format (which will follow the Ogre XML format pretty much, just with a little “compression” if you will). Workflow wise i’ll make the loaders plugable, by default only the binary loader will be available. For development you can plugin the Ogre XML loader to speed up the development cycle. When you deploy your app you’ll have to convert the Ogre XML files to libgdx binary files via a tool we’ll provide you with (CLI & Gui if necessary).
The mesh and skeleton is covered by the above, materials are a different beast. I propose the following: most often you ignore the material you specify in your modelling app anyways. Instead we’ll provide a generic, (de)serializable Material class that allows you to specify any attributes you want, be it fixed-function material properties, shaders, diffuse/specular/normal maps and so on and so forth. For the Material class we’ll go the same way as we do for the mesh and skeleton: plugable system, with a default implementation in the core that can cope with a binary representation only, and a couple of extension loaders for material definitions of specific formats. Hooking up a material with a mesh is something that you can do by yourself (e.g. based on material names defined in the mesh which map to a material file).
This should cover most bases i think. No ETA, it’s done when it’s done.