I used der_ton's exporter but in JME the model is messed up like the follow: (some IK is added to bones) - model is working fine in MD5 Modelviewer though:
public class FishTest extends SimpleGame {
private static final String BODYMODEL2 = "models/aaa.md5mesh";
private static final String BODYANIM2 = "models/aaa.md5anim";
// private static final String BODYMODEL = "models/fish/fish.md5mesh";
// private static final String BODYANIM = "models/fish/fish.md5anim";
private Model bodyModel2;
private Animation bodyAnimation2;
private AnimationController bodyAnimator2;
private SkeletalModelInstance bodyInstance2;
public FishTest() throws IOException {
bodyModel2 = loadModel(BODYMODEL2);
bodyAnimation2 = loadAnimation(BODYANIM2);
}
public static void main(String[] args) throws IOException {
final FishTest app = new FishTest();
Quaternion rotate3 = new Quaternion();
// angle in radian no degree
rotate3.fromAngleAxis(3.14f, new Vector3f(1, 1, 0));
bodyInstance2.setLocalRotation(rotate3);
"In the *.md5mesh and *.md5anim file those "CONTROLS" seem to be not exported. Can you confirm?"
I don't understand MD5 file detail, I just use the exporter export mesh + anim
You only have to read the joints names and see if there is any CONTROLS in the list. No need for MD5 format knowledge.
Moreover, I would like to understand if the model is animated correctly by MD5 Reader 2, if you export it using the steps you wrote:
tobycraftse said:
Just do the following will fix the problem:
1) remove Skin modifier
2) re-add Skin modifier
3) re-add bone to Skin
I am not able to open *.max files. I have not 3D Studio Max.
tobycraftse said:
ORIGINAL MAX FILE is uploaded:
http://www.oniva.com/upload/1356/Man.max
Furthermore I analyzed the *.md5mesh file, the part regarding joints (bones) declaration. And I found that several bones/joints are root joints: they have no parent.
I think model is fine, see MD5 model viewer perfectly loading model animation:
http://www.oniva.com/upload/1356/man8.jpg
but same model is loading messed up using MD5reader2:
http://www.oniva.com/upload/1356/man.jpg
I understood this. What I wanted to know is if the joints names list, in the *.md5mesh file, corresponds to the joints names that should be exported.
tobycraftse said:
I suggest you repeat the same step by:
1) download the Man.max
2) mess around Man.max by add / delete stuff
3) re-export using der_ton's exporter for MAX
As I already told you, in the previous post, I haven't 3D Studio Max so I cannot do those steps.
If you take a look at the mesh and animation file i uploaded in pervious post
As you can see, some of the above "ARE NOT BONES", see the green boxes in follow picture, they are box/points.
http://www.oniva.com/upload/1356/man10.jpg
but the green boxes (NOT BONES) is exported as joints too
P.S. Is Joints in MD5 files same as Bones? i notice they have same names
If you take a look at the mesh and animation file i uploaded in pervious post
As you can see, some of the above "ARE NOT BONES", see the green boxes in follow picture, they are box/points.
http://www.oniva.com/upload/1356/man10.jpg
but the green boxes (NOT BONES) is exported as joints too
In the image there is a hieracy tree expanded. The first name I notice is Slider01; the second EyeTarget. Are they the green boxes (helpers, controlls)? And their siblings are helpers/controls too?
I ask that because there is no Slider01 or EyeTarget in the *.md5mesh file.
stmarsp5910 said:
P.S. Is Joints in MD5 files same as Bones? i notice they have same names
Joints are Bones in the syntax of MD5 format. But there are no other entities called Bones. Joints are Bones. It is simply a different way to call them. Probably they refer to the fact that they basically rapresent only the root of a bone.
In the image there is a hieracy tree expanded. The first name I notice is Slider01; the second EyeTarget. Are they the green boxes (helpers, controlls)? And their siblings are helpers/controls too?
I ask that because there is no Slider01 or EyeTarget in the *.md5mesh file.
Slider01 and EyeTarget when selected is show in the follow
1) Slider01 is not a box it's a 3 axis slider thing that i don't know what's use for
http://www.oniva.com/upload/1356/con1.jpg
http://www.oniva.com/upload/1356/con2.jpg
2) EyeTarge is the write box the eye is looking at when selected
http://www.oniva.com/upload/1356/con3.jpg
All controls when selected in 3ds max are show below in white boxes
http://www.oniva.com/upload/1356/con4.jpg
What I was asking you was to help me verifying if the controllers/handlers names appear also in the .md5mesh joints hierarchy.
Though, looking at the last image (http://www.oniva.com/upload/1356/con4.jpg) consider for example the L_TOE name in the Select Objects window; in the .md5mesh file there is a “L_Toe” but different character case, so I think it is not one of white boxes selected in the last image.
This, in conclusion make me think that der_ton’s exporter did not exported controller and handlers. So the problem remain how you constructed your bone hierarchy.
I still do not know what the MD5 Viewer (C or C++) does, that MD5 Reader 2 does not. But it would be really helpful if you try to add a “origin” bone placed at (0, 0, 0) and parent to it all the bones that still do not have a parent. In a previous post I listed all of them.
NOTE: I have a little new idea about this known bug. I will test it, meanwhile.
In animation rigging, usally, human characters are rigged with a hierarchy summarized here.
Basicaly only one bone is at the root of the herarchy. In this case the Hips bone.
For example, Doom 3 models have one root bone: you can open marine.md5mesh with a text editor and easily see that it has one bone named “origin” as its root bone. In a *.md5mesh file you can easily verify wich one is the root bone by reading the first number next the bone name: if it is equal to -1 it means that the bone has no parent bone, that means that it is a root bone.
In your file there are about 10 bones with the number -1.
I tested it to re-assign the Hip (L_Hip and R_Hip re-assign to ROOT instead of -1) + Hand (all fingers re-assign to Palm instead of -1) like the following, then the model loaded and animated correct:
Can MD5reader2 be modified to deal with the -1 values? since MD5 model viewer program display the model animation perfectly, Is this an easy fix for MD5reader2?
Can MD5reader2 be modified to deal with the -1 values? since MD5 model viewer program display the model animation perfectly, Is this an easy fix for MD5reader2?
Consider that having more than one root bone is not a good rigging approach. If you need to have more then one indipendent bones you can parent them to a single root bone and move them in the root bone space. That is the same that happens to legs and first spine bone, that are alla parented to hips in a standard human rigging.
If I correctly analyzed the problem, the C and C++ MD5 Viewers work because they are engines made from scratch. No dependencies. Just OpenGL code. So the author coded them to make the world axis orientation matching the MD5 world axis orientation.
Furthermore, there is a remote possibility. I remember that somewhere in this board Renanse or Mojomonkey were talking about the possibility to setup differently jME applications (or jME camera?) axis orientation when system/game are initialized.
But, the right approach would be to modify der_ton's exporter (or make another one from scratch) that supports user custom axis conversions during export.
Moreover, there is a part of the MD5 Reader 2 that I have still not explored. It is animation part. In his MD5 specification rules, the author of the C, C++ viewers, explains that joints transformations of the skeleton bind pose (rest position saved in the joints section of all *.md5mesh file) are saved in object space, and are indipendent from each other. There is no need for more computations. So, I guess that each bone/joint is placed relatively to the model local space. In jME to have a local space it is needed to parent the bones/joints to a Node object (SkeletalModelInstance is a class extending Node). This means that I have to investigate how MD5 Reader 2 sets up this Node object.
There is also the possibility that MD5 Reader 2 converts each bone transformation to its parent bone local space. That means each bone is relative to its parent bone (or Node in the case of the root bone). This could be useful for interpolations, ragdoll and other uses where is needed to have a scene graph like bone hierarchy. But this last possibility, for me, is quite remote, considering the positive result of the last experiment and the fact that MD5 Reader 2 joints are not scene graph objects.
For me the bug you (and many others) experimented is caused only by the different axis system.
