MD5 reader fixed

[Ender]

I have uploaded a new version of the well known Chaosdeathfish MD5Reader.

In this minor release I fixed MD5Reader to work with recent jME CVS changes (batch meshes and some method that have been renamed and changed). Also I managed MD5Reader to correctly translate root bone coordinates in to the jME axes system, that was messed in the previous one and caused root bone to move in the wrong direction if animated.

I worked in collaboration with Marlon Smith (known as mcbeth in the jME forum) who add some other minor fixes and general clean up, and, more important, managed model bounds to update correctly. Bounds are missed in the version we used as a start point.

A particular thanks to Chaosdeathfish that permited this release and suggest me which variable is responsible for the root bone flipping code.

To download the source code with the changes I made, please visit http://endercg.altervista.org.
Beyond the source code I puted also a link to the unified diff file that can be used to patch the release with the fixes made by Marlon Smith.

The only tests I done were about loading MD5 meshes and animation, with textures. Marlon explained me that shaders are broken and does not work.

There are really good MD5 importer and exporter for Blender, written by der_ton, which can be used to create models and test them. For the exporter visit Blender2md5 exporter 0.94 2006-02-09. The importe should be available somewhere in the same forum.

[mojomonk]

Great Ender, good work. What's the chances of moving to towards supporting the SkinNode system that is now in place in CVS. One thing that has been bothering me is the number of different skinning solutions (Milkshape, kman's, MD5 and now the "official" one), I'd like to see all these move to the official one, with improvements made to it as needed.

[Ender]

One thing that has been bothering me is the number of different skinning solutions (Milkshape, kman's, MD5 and now the "official" one), I'd like to see all these move to the official one, with improvements made to it as needed.

Thanks mojo. I also would like to remember again the other author of this fix that is mcbeth, and thanks to Chaosdeathfish for his support.

I know about the new internal skin system and I would like to see all the external loaders to match it too. Unfortunatelly my knowledge of 3D Graphics coding principles is really poor (I just poorly understand Matrices, Quaternions and Skinning principles). And if I would start such a port effort I will need a long time to reach the objective, as a single coder.

Though I hope that this new fix of the first MD5 Reader, can be a starting point to interests the coders community.

[snaga]

well, they provide different possibilities to the artist. Milkshape format support is great for Milkshape users(imo, only good for mechs and non organic articulated stuff). Md5, for a number of packages. collada, for  other different packages(ie: xsi). But that's an apart thing from having an internal single skinning method.

[Ender]

well, they provide different possibilities to the artist. Milkshape format support is great for Milkshape users(imo, only good for mechs and non organic articulated stuff). Md5, for a number of packages. collada, for  other different packages(ie: xsi). But that's an apart thing from having an internal single skinning method.

Yes I am agree with you. Though I think that a change of the internal code of these scripts to match new SkinNode class is possible and I think it will not affect the features of the different formats.

We could also choose to code a layer of compatibility with SkinNode, while keeping the original solutions as a separate layer to permit use of features still not implemented in the new internal Skinning system.

This discussion could also suggest that it can be interesting to implement a standard plugin system for extending jME, or at least to write some guidelines for coders who think to make some extension.

[mcbeth]

Great Ender, good work. What's the chances of moving to towards supporting the SkinNode system that is now in place in CVS. One thing that has been bothering me is the number of different skinning solutions (Milkshape, kman's, MD5 and now the "official" one), I'd like to see all these move to the official one, with improvements made to it as needed.

I'm all for it, if the animation blending and subseting capabilities can be easily ported along with some of the more useful convenience method, I suppose the cloned node stuff kevglass did might replace the instancing, my only regret is that I may not be able to assist in any deeper restructuring of the code.

[Ender]

As explained me by mcbeth in an email, I recived today, we should thanks also kman for this fixes.
It seams that the sources mcbeth sent me, at the begining of this attempt to revival MD5Reader, have been already modified by kman.

I apologise for this omission but I was not informed about it.

I quote the message that mcbeth sent me to explain:

good to know and if you haven't seen my pm you should also mention that kman did alot of conversion work while conparing his

Thanks to all

[snaga]

I thank for the effort to you all

[Ender]

It would be great to have some feedback with screenshots and logs (if any error).

I would be great to know what does work and what does not. Unfortunatelly I have not much time to test so any feedback could help me to know exactly what the MD5 Reader still need to be better.

Thank you for the response snaga.

[JTroll]

I want to use the MD5 Format. I played around with your MD5 Loader, but i didn't  get it runing. But probabliy I don't understand how to use it. I have a simple Model with two bones in MD5 Format. And want to see my Model on screen. My code looks like this..

   Model model = null;
        try
        {
            model = loadModel( "box.md5mesh" );
        }
        catch (IOException e)
        {
            e.printStackTrace();
        }
        ModelInstance modInst = new SkeletalModelInstance(model);
        rootNode.attachChild(modInst );

loadModel() works, but I see nothing on screen. Whats wrong or what is missing? What ist    necessary for a helloMD5.java ?

[Ender]

I want to use the MD5 Format. I played around with your MD5 Loader, but i didn't  get it runing. But probabliy I don't understand how to use it.

In the source files there is a MD5Test2.java that is quite easy too understand and can be considered an HelloMD5.java.

Though your code seams to be correct, even if I would like to see the output.

[mcbeth]

unfortunately the loader does not have a default material renderstate so if their is no texture in the file's shader definition or the texture cannot be found nothing will display, thats one of the things I want to "try" adding, not the best coder

@ Ender perhaps it would be a better idea to include the data files rather than the libs it would give people a better idea of what might be happening

[Ender]

unfortunately the loader does not have a default material renderstate so if their is no texture in the file's shader definition or the texture cannot be found nothing will display, thats one of the things I want to "try" adding, not the best coder

If it is that the problem, as you explained, I could start an implementation of that code. But I do not know if it can be based on standard jME material or it is a completly different code.

@ Ender perhaps it would be a better idea to include the data files rather than the libs it would give people a better idea of what might be happening

For data files, I have not included them becouse I do not know if they are freely distributable. The marine object is really similar to that of "Doom 3". So, if you know that it can be distributed freely tell me where I can find the license text and I will re-distribute it.

[mcbeth]

the model was taken from the doom3 demo as far as I know, it was for testing purposes at the time to show that a doom model can be correctly displayed, I understand your reservations about hosting it but not including it or a similar model would render the test useless, I do not know if a simple disclaimer then would be suffice then.

[White_Flame]

Great Ender, good work. What's the chances of moving to towards supporting the SkinNode system that is now in place in CVS. One thing that has been bothering me is the number of different skinning solutions (Milkshape, kman's, MD5 and now the "official" one), I'd like to see all these move to the official one, with improvements made to it as needed.

Well, as the author of Yet Another jME Skinning Package, there are some design performance differences that I took vs the "official" one.

• I did not make Bone derive from Node.  I went back and forth on this for a while, but the general case is that Bones do not have non-Bone children.  For a Bone to have a general Node child would be a special case.  Nodes carry along a lot of state, and calling down the scene graph every frame would run a lot of stuff in those skeleton nodes that wouldn't affect the skinned model at all.  So I opted for a lightweight skeleton-specific Bone class.  In my system, if you want to hang things off your skinned model, you can ask it to create a Node that keeps itself locked to a Bone.  This Node is directly under the skinned model's root node, keeping the scene graph heirarchy a lot more flat.  My skeleton also updates in a linear fashion (ArrayList of Bones, pre-sorted in descending heirarchy order), instead of traversing a tree.
• Special case for unweighted single-bone skin mesh points.  Since I'm not a modeler, I'm not too certain on the ratio of single-bone unweighted vs multi-bone weighted points on an average modern model, but it seemed like a good idea.   Drawing from this, I would also make special case classes or methods for the version that doesn't update the normals, instead of doing runtime checking in your inner loops.
• Apply the inverse binding transformation when the reference points in the mesh are set, instead of doing all of those transformations at skin time on unchanging data. I know there's methods for setting the binding transformation after the bone is created; in what situations does that get used?

I'm not done with my system yet, but I expect it to be a lot faster than the com.jme.animation.* implementation.   The last two points could probably be integrated into the "official" system, but the first one is pretty foundational.

[Tags:]

jMonkey Engine > Community Activities > User Code & Projects (Moderators: Outrunner, erlend_sh, Momoko_Fan, Vardamir, .:emp...imm0|82:.) > Topic: MD5 reader fixed