Game Editing > Scripts & Support

[MD5] EXPORT script for Blender 2.6x (OPEN)

<< < (5/46) > >>

keless:
Okay this is weird as hell. I'm comparing the actual matrix values found in 2.4 and 2.5

The actual matrix values before the multiplication match up. Specifically:

obj.getMatrix('worldspace')  == obj.matrix_world ==
[1.000000, 0.000000, 0.000000, 0.000000]
[0.000000, 1.000000, 0.000000, 0.000000]
[0.000000, 0.000000, 1.000000, 0.000000]
[0.019181, 0.011407, 7.975471, 1.000000]

and

b.matrix['ARMATURESPACE'] == b.matrix_local ==
[1.000000, 0.000000, -0.000000, 0.000000]
[-0.000000, 0.000000, 1.000000, 0.000000]
[0.000000, -1.000000, 0.000000, 0.000000]
[0.000000, 0.000000, 0.000002, 1.000000]

however, it seems like the matrix multiplication result is DIFFERENT?!

in Blender 2.49b the result is:
[1.000000, 0.000000, -0.000000, 0.000000]
[-0.000000, 0.000000, 1.000000, 0.000000]
[0.000000, -1.000000, 0.000000, 0.000000]
[0.019181, 0.011407, 7.975472, 1.000000]

in Blender 2.54 the result is:
[1.000000, 0.000000, -0.00000, 0.00000]
[-0.00000, 0.000000, 1.000000, 0.00000]
[0.000000, -1.00000, 0.000000, 0.00000]
[0.019181, -7.975471, 0.011409, 1.0000]

ARRRGGG!! order of multiplication changed!

instead of multiplying the bone space * world matrix in 2.4, we need to multiply the world matrix * bone space in 2.5

updated script in place (http://dl.dropbox.com/u/1556553/io_export_md5.9-15-2010.py )

now I need to figure out why there is a major difference in the number of verts/tris/weights section. Probably a problem with the whole face_vertices code, and how it does or doesnt cut quads up into tris and handles cloning vertices (since I didn't fully understand the code when I was translating it to 2.5)

kat:
If I'm understanding what you're saying there would it make any difference to *require* meshes be properly prepped *before* export so the script isn't doing what is effectively unnecessary work?

[EDIT]Good job so far. Results of export in the MD5 viewer. Mesh seems to be solid and everything in place, only UVW's are a messed up as per your comments above about that.

keless:

--- Quote from: kat on September 16, 2010, 02:12:01 AM ---If I'm understanding what you're saying there would it make any difference to *require* meshes be properly prepped *before* export so the script isn't doing what is effectively unnecessary work?

[EDIT]Good job so far. Results of export in the MD5 viewer. Mesh seems to be solid and everything in place, only UVW's are a messed up as per your comments above about that.

--- End quote ---

The md3 exporter for 2.5x _requires_ that the mesh already be 'triangulated' (CTRL+T) before its run. Personally, I'd rather not have this requirement, but it may be possible to copy the mesh data and run the Quad->Triangle algorithm on the copy and cull the degenerates before parsing into Face() s

I dont think the UV code is technically the problem right now, since flipping the Y/V coord worked. I think the texture problems you see are related to the improper way I'm counting up the faces/tris, and should work itself out when thats done. I know you dont see vertex problems with the guard char, but I dont see vertex problems with my frog character, and I do see plenty with my panda character.

keless:
I've nailed down another problem in the script, specific to the getVertexInfluences code I had hacked out earlier.

In this example, the left bone name is what my function returns (always the same as the last bone name) and the right is what a hand-crafted lookup of the bone name returns.

influences for vert 1115 are:
R_Hip vs: L_Hip
R_Hip vs: L_U_Leg
R_Hip vs: R_Hip
influences for vert 1885 are:
R_Hip vs: Torso
R_Hip vs: L_Hip
R_Hip vs: R_Hip

This would probably account for the difference in WEIGHT values since there are less unique bones associated with each vertex as a result. We'll see how much this helps when I fix it.

EDIT: I've now fixed this issue, the bone influences are now returned correctly.

However, this does NOT increase the number of entries in the VERTS and WEIGHTS section. In my frog character the result is not graphically noticable. In my panda character, the body looks less like a mess of spaghetti and slightly more like a stick figure, but still not a panda.

I'm now looking into why exactly my number of VERTS/WEIGHTS doesnt match the original.

The latest: ( http://dl.dropbox.com/u/1556553/io_export_md5.9-16-2010.py )

EDIT2:  (sorry for all the updates, but it helps me think about it clearly to write out what I know)
* the number of VERTS in the Body sub-mesh of frogger.md5mesh generated from the 2.4 script is 2298
* the number of VERTS in the Body sub-mesh of frogger.md5mesh generated from my 2.5 script is 2010
* the number of vertices in the Body mesh of frogger in memory in Blender 2.4 AND Blender 2.5 is 2010
* weights are generated as a direct result of the list of verts
>> conclusion: the old mesh generates 288 extra verts that my script does not
* there are 3 places VERTS are generated; (1) once for each vertex in the blender mesh, (2) once AGAIN for each vertex shared by non-smooth faces because they have diff normals, (3) once AGAIN for each vertex with two separate UV coords for different faces

... carp, the original script has a weirdly tabbed for-if-else section that I 'fixed' the indentation of.. this might have broken something

keless:
Progress: the frogger character is now 100% correct, but the panda character is still messed up.

(I made these models myself, and I'm a programmer, and there is no lighting in this shader, so dont worry about how crappy they are  :D )

Upon exporting the panda from the 2.4x script and comparing the results, I realized that the left/right hip bones aren't actually attached to the intended root bone (so there were effectively 3 root bones). However, after fixing this I still get the exact same result as the previously posted screenshot.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version