Here you can find MD5Importer for jME.
The project homepage is located at http://code.google.com/p/md5importer/
============================== Updates ===================================
Recent updates
=========================== Current Versions ================================
MD5Importer Concurrent jME2.0 - v1.1
MD5Importer jME2.0 - v1.3
MD5Importer jME1.0 - v1.3
============================== SVN URL ===================================
MD5Importer Concurrent https://md5importer.googlecode.com/svn/trunk/md5importer-concurrent
MD5Importer jME2.0 https://md5importer.googlecode.com/svn/trunk/md5importer-jME2.0
MD5Importer jME1.0https://md5importer.googlecode.com/svn/trunk/md5importer-jME2.0
Detailed checkout instruction
============================= Features ====================================
1. Concurrent update - Allows the animation and mesh geometry update process to be performed in a separate thread from the rendering thread to enhance performance and more importantly scalability. Assuming there is enough computing power available, executing multiple character updates cost roughly the same as executing a single character update.
2. Skeletal animation
3. Texturing - Basic texturing using jME ResourceLocatorTool.
4. Animation fading - Allows smooth fading between two animations.
5. jME Savable - Allows saving loaded model into binary format for distribution.
6. Dependent child - Allows a loaded ModelNode to share its parent’s skeleton during animation. This allows artists to create one single skeleton and skin meshes such as changable armor pieces on it. When export the these armor pieces, you do not have to worry about seperating the skeleton at all. All you need to do is export each piece of armor with the entire skeleton structure all together. Then after loading that armor piece, use attachDependent(ModelNode) method to add the newly loaded piece to an existing piece (chestArmor.attachDependent(headArmor)).
7. Animation speed control - Allowing you to directly control the speed of the animation. This can be useful when you want to play your animation in slow motion or fast motion mode. Think of Matrix
8. Animation repeat type - Inherit jME controller’s repeat types. This includes wrap, clam and cycle modes.
9. Fast cloning - Allows fast cloning of ModelNode and JointAnimation. This allows users to clone models and animations in a matter of milliseconds for multiple entities use. Fast cloning is about 10 times faster than jME CloneImportExport.
10. Normal sharing - Allows vertices with same geometric location to share the same normal vector.
11. Special texture extension support - Allows user to specify texture extension to be used when loading binary exported mesh.
============================== Known issues =================================
None.
HouseMDave said:
I cant try it out, but this might do the trick:
while(this.time >= this.frameTimes[this.nextFrame])
this.nextFrame++;
this.prevFrame = this.nextFrame - 1;
Its the same for all three update methods, so this should be an easy patch:)
i just released the 1.2.2 versions, they fixed this bug. the fix is slightly more complicated than ur patch, but thx alot for reporting the bug! :D
Fixed cycle wrap mode.
Now all three animation modes work properly. 
So, We already have probably 3 technologies to handle MD5 models, right?
Which one has the higher compatibility? Are you going to merge them?
Downloading to test now! 
duenez said:
So, We already have probably 3 technologies to handle MD5 models, right?
Which one has the higher compatibility? Are you going to merge them?
Downloading to test now! ;)
there r actually 4 versions right now with 2 of them being complete and working which r my md5importer and the really old md5reader.
in terms of compatibility, my version supports a little bit more jme features and its probably easier to use. but i think both versions work fine with all kinds of md5 files. however the old version may have some issues with the naming of bones.
please post any feedbacks possible after ur testing :D
checked again with fraps 640 - 540
your right
the jme fps counter updates are quick/erratic fools the eye looked like 680 - 503
but that aside, cvs needs house keeping…badly or a clearly visible read me 
mcbeth said:
checked again with fraps 640 - 540
your right
the jme fps counter updates are quick/erratic fools the eye looked like 680 - 503
but that aside, cvs needs house keeping.............badly or a clearly visible read me :)
thx for confirming that.
and the cvs is out of my hand right now. ender is doing some merging with it. my code is actually accessable through my googleCode.
neakor's code is read accessible also from CVS. I only temporary closed developers write access cause of some technical problems.
duenez said:
Which one has the higher compatibility? Are you going to merge them?
We are going to merge neakor's importer in to MD5 Reader 2 Refactor (refactor base structure is currently available under org.md5reader2 package).
Currently, the only importers that totally works are old MD5 Reader (original code) and neakor's importer. MD5 Reader 2 Refactor only loads joints and build skeleton, and has the base architecture ready to hold all MD5 data. I was about to complete animation loading, when neakor came out with his importer. MD5 format mesh/weights is something I consider trivial because all MD5 models depends on skeleton and animation. Building the MD5 static mesh can be done easily following the David Henry's specification page MD5Mesh and MD5Anim files formats.
The central problem of all the conversion is focused on 2 issues:
- the different coordinate systems: a) Blender; b) MD5; c) jME.
To achieve a solution we have to consider 2 situations:
-
[li]Loading models that are in MD5 format standard coordinates.
- Loading models that are in Blender standard coordinates.
A possible solution is to modify der_ton's exporter (or provide a new one) to support jME coordinates.
A possible solution is to use the well known BASE Quaternion to convert the root of the model.
[/li]
-
[li]My personal solution is that there should be a single root bone. Every professional 3D modeler knows that having more than one root bone means bad structured skeleton, that can lead to unpredictable results. If you need more than an root branch you can parent them to a single root bone that handles the whole model and you will get the same result. That is the recomended way of rigging a model. Read, for example, what the author says about COG in this document Preface: Rigging in Blender, taken from the Blender Summer of Documentation project. The COG principle can be considered valid for every 3D animation.
- Though, if users need something different for particular reasons we will see if it is possible to resolve this in another way. But I cannot promise any successful result.
Apart this things, MD5 Reader 2 Refactor is planned to be the most versatile of the 4 projects. And versatility will be his power. Actually a true API whit a up to date bridge to jME. Simple to use and simple to extend. In particular I would like to implement a lot of things and maybe support for other Doom 3 formats, like Maps, Cameras, Materials and many all the Doom 3 specification we can implement.
Ender said:
[li]the different coordinate systems: a) Blender; b) MD5; c) jME.
To achieve a solution we have to consider 2 situations:
Another solution is of course to alter jME's classes if there was an alteration that made more sense and was as fast or faster. iirc, momoko_fan had talked about changes a while back.
In any event, thanks for pushing this along. It's nice to see the collaboration in progress.
renanse said:
Another solution is of course to alter jME's classes if there was an alteration that made more sense and was as fast or faster. iirc, momoko_fan had talked about changes a while back.
Yes, of course. Though, consider that: BlenderCoordSystem != DoomCoordSystem != jMECoordSystem. I do not know if jME is able to satisfy both systems at the same time. For me the best of all solutions remain the Blender exporter approach. Though you are surely more expert then me :) .
renanse said:
In any event, thanks for pushing this along. It's nice to see the collaboration in progress.
Thanks. We hope to reach some results. Making an estimation (that could be an hazard, considering my spare time :D) we should be able to produce the first stable release of the Refactor before summer. I would like to make a better estimation but I have to be pragmatic. ;)
aside from the coordinate system, the way jme's bone animation system works is very different from the algorithm md5 uses.
md5 computes the vertices positions and normals using the weight positions, values and some other variables which cannot be stored using jme native classes. jme's bone animation simply moves the bone translation and orientation to calculate the vertex positions and normals.
from this observation assuming it is correct, the it is not possible to use only jme classes to support md5.
Yes. At least vertices computation must be custom, placed somewhere in the animation loop, for example the update() method of a custom animation Controller. As you did, neakor, I guess.
i just added in the support for oriented bounding box. u can use that by MD5Importer.setOrientedBounding(true);
and i also fixed some bugs which resulted in a significant performance increase.
i tested with the marine running animation, my implementation runs at 1400 to 1500 fps where the original md5reader runs at 1100 to 1200 fps.
fading featuer added.
dependent child feature added.
this is made to make ur life and ur artists lives easier. changing animated armor pieces and assembling characters using animated pieces just became so much easier. see top page for details.
Maybe a bit offtopic, but do any of the MD5 importers support vertex shader skinning?
From what I understand the MD5 format was made to fit to be used in the vertex shader, if so this could be a very nice feature if implemented.
The MD5 format was specifically made for CPU skinning, it is very unsuited for GPU skinning. The logic is, that the scene will be rendered multiple times, and it is better to do the skinning only once on CPU, and not muliple times by the GPU as the scene is rendered multiple times. It is possible to implement GPU skinning with MD5, but it is not simple and its not as fast as GPU skinning could be.
I think I read that quake4 does gpu skinning but technically its not md5, but md5 compiled into something else to facilitate it, can't remember where saw it or when
Momoko_Fan said:
Maybe a bit offtopic, but do any of the MD5 importers support vertex shader skinning?
From what I understand the MD5 format was made to fit to be used in the vertex shader, if so this could be a very nice feature if implemented.
thats certainly a nice feature to have. but i have to say i dont have enough shader knowledge right now to implement such feature. besides as the others have stated, cpu skinning is much faster than gpu skinning.
however, if anyone do wanna develop such feature, ill be happy to include in the package.
vear said:
The logic is, that the scene will be rendered multiple times, and it is better to do the skinning only once on CPU
Do you mean precomputing vertices positions of all keyframes before to start animation and store them in a RAM cache? Or better store them in GPU video RAM as a ready table for rendering? And then calculating only interpolations?
This is really interesting.
Though MD5 Reader 2 will support widelly some shaders features. I plan to implement the whole MD5 specification plus extra Shaders support. Interesting also this precompiling of MD5 format to suite GPU requirements.