Hello everyone! I’m Dave, the newest contributor to libgdx, and I’m here to tell you about some new additions to the 3D pipeline. There’s quite a lot to explain, so I’m going to do it in order of my commit log and hope it’s reasonably coherent. Here goes…
- New constructors for Mesh, VertexArray and VertexBufferObject to accept VertexAttributes in addition to VertexAttribute…
This is a simple change that allows you to easily construct a new Mesh using the VertexAttributes from an existing Mesh.
- Reference counted textures and a texture dictionary
Textures can consume a lot of memory, so you want to minimise their footprint and also make sure you don’t load the same resource twice. A reference counted texture (TextureRef) ensures the same Texture can be shared between different resources with varying lifecycles. Use the TextureDict to manage your TextureRefs – if you use its loadTexture() method to get a reference to a texture it will automatically share the resource. Call unload() on a TextureRef to remove a reference to it (typically when your resource using the Texture is destroyed). You can also manually increment the internal reference by calling addRef().
- Normal allocation and interpolation in the MD5 classes (experimental)
I’ve made a first attempt at pre-computing and skinning the normals for an MD5 (Doom 3) model. You can read all about the specification for MD5 here. Note that this is not guaranteed to work correctly currently, so use it at your own risk. Note that you only need normals if you want your models to be dynamically lit, and the extra computation to skin them is fairly significant. Any feedback or suggestions for this code is very welcome.
- Keyframed animation baking (sampling) from MD5Animations
Doing the computation for skinning on an Android device’s CPU is typically quite slow and can severely impact your framerate. When I first started using Mario’s MD5 classes, I got into a discussion with him about his vision for 3D animation with libgdx. Under his direction I’ve implemented keyframed animation that loads from the MD5 Models and Animations. This animation system is similar to that used by id’s MD2 file format, used in the Quake 2 engine. Initial tests with my game suggested an approximate 10-20 fps improvement over MD5 Animation – of course, this is dependent on many factors, but in general it should be faster than doing CPU skinning. The reason keyframe animations load from MD5 animations is because MD5 is a more modern format that is still used, and relatively up-to-date exporters are available for Max and Maya.
- Keyframed animation model and animation controller
You don’t have to use these, but the KeyframedModel and KeyframeAnimator classes give you a high level encapsulation of keyframed animations. Use sampleAnimationFromMD5() to load a KeyframeAnimation into the model, setAnimation() to play a named animation, then update() and render() to draw it.
- Animation controller for MD5 animations
I also wrote an animation controller for MD5 animations (MD5Animator). It works more or less the same way as the KeyframeAnimator, so these two classes share the same abstract Animator class.
Finally, I added a simple container used to store material properties including a TextureRef, ShaderProgram, and lighting properties. This class is used by the KeyframedModel. Note that the MD5Loader does not currently load Materials yet, so you’ll need to write your own implementation of material loading. At some point I may also add the classes I use for this, but as they only support OpenGL 1.x and are a horrible mess right now, don’t hold your breath!
I hope this outline gives you some idea of what the new stuff does. If you have any questions, drop me an email at email@example.com. Plug: look out for my RPG Discretion sometime in Q1 2011!
Oh yeah and finally, you’ve seen Nate’s bitch, this is mine: