Talking libgdx 3D Support

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.

12 thoughts on “Talking libgdx 3D Support

  1. Haha I was reading the beginning as you were talking about the other formats, and thought to my self “Gee maybe just have a binary format we convert these too.” glad I read on before commenting 😛

    Sounds like a good solution to me, almost done w\ my 2D game, and my next game will have some 3D elements in it, so can’t wait to see this come to fruition!

  2. Would you consider implementing a general-purpose compressed binary XML format to go with this? 🙂 I’ve been thinking through how to write one, but haven’t come up with an optimal method. It would be nice to be able to seamlessly load from XML or compressed-binary XML depending on the file format, and have a tool to go from XML->bin.

    Apparently, there are some formats: http://en.wikipedia.org/wiki/Binary_XML

    Sorry, kinda just thinking out loud here. Probably an extensions/ type of thing, if anything.

  3. For me the benefits of XML are purely with being able to specify a hierarchy. As a trivial example, being able to get “Engine.Screen.Width” from a config file, and then later in the same file, something like, “Orc.Stats.Level16.HitPoints” is neater than a flat list of data vars, or a heap of different game data files that are only seperate to keep the scope/functionality seperate.

    If it was binary, and all those tags were automagically translated to integer IDs, for example (which is where I’m stuck trying to make things seamless), it would be both fast and nice to use.

    I realise this argument may not be very compelling 🙂

  4. Sounds like a good plan 🙂
    I myself would like to see a tool for converting collada (dae) to the internal libgdx binary format… later down the road of course. (I have seen other engines having this kind of tool.)

  5. Cool. Always glad to see prominent projects pushing the OgreXML format. There’s a thread on the jME site which links to three WIP Blender-to-OgreXML exporters:
    http://jmonkeyengine.org/groups/import-assets/forum/topic/new-blender-2-5-ogre-exporter/

    blender2ogre looked the most promising for a while, but now it seems abandoned. I’m guessing the “official” one will ultimately come through. I just hope they can join forces soon instead of doing three (that I know of) separate projects to solve the exact same problem.

    @Moritz: The site was just down for a while, the link works now.

    @Mario: How come .blend wasn’t taken into greater consideration?

  6. @Erlend .blend files are little to complex for my limited time budget. They aren’t all that well documented either, and loading them in Java is a bit of a pain. They directly save memory contents to the file which would mean make for some nasty code in a Java-based loader. So, i considered it but immediately scraped that idea 🙂 Thanks for the link to the ogre exporters!

  7. Any news on the binary Ogre format and the core loader for it?

    I was trying to find one for testing out if I can use the skeletal animations I have exported from Blender, but with no luck. There seems to be one for desktop but not for Android.

Leave a Reply

Your email address will not be published.