Remove the logging calls (or port them to the new logging system), and replace amesh.setVertexBuffer(rm.getVertexBuffer()) with amesh.setVertexBuffer(0,rm.getVertexBuffer(0))
Thanks 
I did infact try the solution with adding 0 as the int parameter, but the result looked weird as the screen flicked a lot, so I though I'd broken something, and didn't want to bother you with this
Now I've also removed the logging code from the other MD5 reader's tests, and now it runs, but with the same type of flickering.
I'm sure this is a completely different issue belonging in a different thread.
Zta said:
I'm sure this is a completely different issue belonging in a different thread.
Correct, and there has been some discussion about it, eventually leading to Ender fixing the issue. A forum search for "md5 flickering" or "md5 twitching" should eventually lead you here:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=4858.msg44807#msg44807
Splendid.
But it seems my X has lost its hardware acceleration in mysterious ways, and glxgears (OpenGL test app) is flicking too. I'll fix this first
Thanks so far.
Infact, I think that if your problem is screen tearing (sometimes also called screen flickering) it is caused by 3D acceleration drivers.
If, after you reactivated your 3D acceleration, you still see the same problem, try reading this thread: jME display tearing under Mac OS X.
Hardware rendering helped
Now, which one of the MD5 importers should I choose?
Try them.
And please post feedback. The MD5 Reader 2 shoul still have a little trouble with textures. I still have not tested if the latest fix I made about model twitching also resolved texture flickering cause of a lucky coincidence, as often happens fixing code :D.
About kman's loader, I cannot help you and is a lot of time that I do not test it.
A quick workaround for the flickering with MD5 Reader 2 might be to set the NormalsMode yourself. For example, if your model only has one mesh then you could do bodyInstance.getMeshes()[0].setNormalsMode(SceneElement.NM_GL_NORMALIZE_IF_SCALED);
Now if I could only get my models smoothed as well as lighted! But that I think has something to do with them having "discontinuous uv" perhaps? :? They are smoothed if I uv-wrap them myself, but I can't figure out how to wrap them correctly with their provided textures…
Now if I could only get my models smoothed as well as lighted!
Try hitting 'SetSmooth' button , models are not smoothed by default.
I have tried setting them to smooth, removing all duplicate vertices, and even subdividing them. I even tried feeding the meshes into duenez Normal generator but so far no luck. They still look ugly and blocky when lighted.
If your model has a MaterialState applied, check the specular level. It might be so high that it is "blowing out" any transition. That is, it's so high that a triangle is either lit or unlit.
I just checked and there is no MaterialState. It also doesn't help to create one.
I could post some screenshots, but you might as well take a look at the ones duenez posted for his Normal Generator. I have the same situation with 3-4 normals pointing in slightly different directions from every vertice.
BUT if I wrap a new texture around the same model in blender, for example just Project From View some image, then the same model with no other changes appear smoothed in jME and all vertices seem to have just one shared normal…
Thanks for the feedback, Gathers, and for the suggested code. I will try to implement it someway automatically as soon as possible.
Gathers said:
bodyInstance.getMeshes()[0].setNormalsMode(SceneElement.NM_GL_NORMALIZE_IF_SCALED);
The smoothing problem could be a MD5 Reader 2 problem, once again. There should be no reason to implement a separate Textures and Materials code for MD5, but I do not know if ChaosDeathFish did it. I will investigate the code to know if he did either if some obsolete line of code could be fixed to resolve this problem.
Currently I am more concentrated in Animation/Model and Migration. Moreover, I have few time to work on it because I am busy with other projects, currently. Furthermore, from the update of the CVS code, I haven't had almost any news from the other developers. So I am basically alone.
If this is not enough :D , in the lates 3-4 days, I have been fixing my Gentoo broken update. Still working on it. For this I should thanks some missing libraries, that some new packages decided to delete. :'( :| :-o
So any feedback or help (patches, code, ...) is really wellcome.
For what it might be worth, I apologize for not having worked on the normal generator for quite a while . I have been extremely busy with school (I had not expected it to be this bad :()
The NormalGenerator is not finished yet (there has been some unposted progress, however), and it is very possible it just ignored the model because it didn't understand the model ://.
If you have not been able to solve this in a while, I might have a new and more general version of the generator soon. 
duenez said:
If you have not been able to solve this in a while, I might have a new and more general version of the generator soon. ;)
I don't thing that the problem is Normal Generator. Instead I think that I have to do a lot of work on the MD5 Reader 2 code. XD
Thanks for your quick responses. 
I think the main problem is that the model itself is strange/broken, I just tried looking at it in a standalone md5-viewer and it has exactly the same problems there. (not smoothed unless I reapply the texture, which I can't do correctly myself) So the fault isn't really with MD5 Reader 2.
Ender said:
Thanks for the feedback, Gathers, and for the suggested code. I will try to implement it someway automatically as soon as possible.
Gathers said:
bodyInstance.getMeshes()[0].setNormalsMode(SceneElement.NM_GL_NORMALIZE_IF_SCALED);
I don't know if it's the correct fix though, it was just something I tried that seemed to help the flickering. :)
Any work you do on improving the MD5 reader is appreciated, but I'm afraid I won't be able to help you very much. If I make any useful local changes I will of course share them though.
I look forward to trying your next Normal Generator duenez, perhaps it can mend my broken model.
Gathers said:
I think the main problem is that the model itself is strange/broken, I just tried looking at it in a standalone md5-viewer and it has exactly the same problems there. (not smoothed unless I reapply the texture, which I can't do correctly myself) So the fault isn't really with MD5 Reader 2.
This is interesting. If you are using the Blender export script to create your model, the causes could be:
- check if there is anything to pay attention when you prepare your model, in Blender, for exporting;
- der_ton's exporter could have some problems with your particular case.
der_ton's exporter script, though, is based on the old blender2cal3d export script, the same I modified to work with kman's Cal3D Loader for jME. Recently, after I modified blender2cal3d, a Blender developer, made a new (refactored) and more stable, they say (I have never tested it), Cal3D exporter. It could be possible to create a MD5 exporter based on this new Cal3D exporter to obtain a more complete and compliant script.
Anyway I tested different MD5 models with a C++ based viewer without any problem. If I remember well, I linked it somewhere in these forums.
About helping MD5 Reader 2, I thanks code submissions in advance, if any.
Thank you.