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.
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.
mojomonk said:
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.
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.
snaga said:
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.
mojomonk said:
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.
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
I thank for the effort to you all 
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.
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 ?
JTroll said:
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.
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
mcbeth said:
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.
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.
mojomonk said:
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.
@mcbeth/ender . Do you really need marine? cant use any homemade md5? I only have a weighted and complex-rigged/constrainted cilinder(which proved to work with Kman's and jme) with some anim…We went 2d at the end for a first project…
@white_Flame
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. grin
Unweighted...If it'd be weghted, all to rigid (1.0 weights) then is useful for like using isolated bones for space ships, mechs, stuff. Unweighted...In blender I use those as IK solvers, constraint targets, etc...Dunno , maybe for make a use of em in code too...perhaps for IK, ragdoll future stuff...
I'm meaning a situation like a forearm on a humanoid model, where some points near the elbow would blend both the forearm bone and the upper arm bone (weighted multi-bone blend), while some points near the middle of the forearm would only reference the forearm bone (unweighted single-bone transformation), all on the same model.
oh,yup.That's essential. I mean, partial weights, that is, that elbow bones are affected by both fore arm and upper arm..(ie, upper arm bone with 0.83, fore arm bone with 0.17 weight , ove rthose vertices. really bad if it's 0.16 and then remaining 0.01...to, for example, upper leg... [artist error...and if it's something like 0.09238833229999...I bet is ... typical weight painting error ... ]) ... Actually, at least the way I do and seen done also in my mates at job, is... forearm middle zone, for example, usually has 1.0 weight of fore arm bone. That is, no other bone influencing it...if you needed by code to actually force more than one bone affecting every vertex....then it'd be 1.0 to fore arm, 0.0 for next one, for instance. But 0.0 , as 0.03 could be terrible. 0.000000001 or that trend, tend to not visually affect, but do messes th eexproters.This sort of crappy stuff is often weight painting in 3d packages. reason why I just do lasso selecting-weighting.
What i mean, is unrelated on how you implement it, is essential to be able to weight rigid stuff, like a forearm (tho advanced game rigs do allow forearm torsion, but that's another story) , with one only bone affecting it, 1.0 weight to that bone. While essential is also to be able to set up at least 3 bones affecting per vertex (the maximum possibility, as many times, only two...like elbow, knee. But in shoulder,one of the complex areas, there's often 3 or 4) , ideally 4. Unreal tournament 2003 maximum, I think I remember it was 3.
Yes, I would have already done if I have had the time. But I have been busy with other projects.
Though I have done this fix becouse I needed it (and mcbeth too), and secondly I decided to share it with the community. So, the initial aim of this release have not been to maintain a user friendly distro with resources for testing, models and may be manuals or guides; but, sharing with the community the new MD5 Reader that works with jME CVS (but in the substance unmodified), have been accidental.
Ofcourse this does not mean that I will never try to enance it and care requests from the community, but without help I will need a lot of time.
If anyone would like to help me, anyway, contact me, and we will try it.
@snaga/White_Flame - however the main problem in vertices wheights is how the wheight value is computed. I saw that each 3D application has a different method and results are often really different. So the most important part is to choose the right one for your needs.