Game Editing > Scripts & Support
[MD5] EXPORT script for Blender 2.6x (OPEN)
keless:
Here is the current WIP script:http://dl.dropbox.com/u/1556553/io_export_md5.9-15-2010.py
EDIT: for Blender 2.54 beta
* The joints section at the top of the file seems CORRECT.
* Actual vertex data seems CORRECT.
* Tex UV coordinates are WRONG.
* Bone weights are INCONCLUSIVE (since I don't export animation data to test them out yet).
This script will FAIL on line 500 on some models due to index OOB error, which I'm currently looking at.
kat:
Couldn't get this to run for some reason. Tried loading it into a text view and Alt+P'd it but that doesn't run scripts at present. Also dropped it into scripts/io and had to change the name to "export_md5.py" for it to appear in the export list, but it shows up as a list heading rather than an active script for me.
This is with 2.53beta running on Vista.
keless:
--- Quote from: kat on September 15, 2010, 06:58:53 PM ---Couldn't get this to run for some reason. Tried loading it into a text view and Alt+P'd it but that doesn't run scripts at present. Also dropped it into scripts/io and had to change the name to "export_md5.py" for it to appear in the export list, but it shows up as a list heading rather than an active script for me.
This is with 2.53beta running on Vista.
--- End quote ---
Sorry, I forgot to specify, this is for the latest public beta version of Blender which is now 2.54 (they changed the module registration methods which broke 2.53 scripts, so it wont even run if you try it in 2.53)
Also; small update to the script, which fixed the index OOB error, however the model that had that error now compiles but vertices are messed up when rendered.
kat:
Tried two tests with this once I got it loaded into Blender ... btw... "grrrrr" on the fact that they've changed things around internally yet again. Distributied scripts are in a different location, if you put customs in there they don't work, so thankfully it still seems that "scripts/io" is where they should be placed.
Tried the script with the source file version of bob (linked to above) loaded into 2.54 and got some output but just a few lines;
--- Code: ---MD5Version 10
commandline "Exported from Blender by export_md5.py by Paul Zirkle"
numJoints 0
numMeshes 1
joints {
}
mesh {
shader "body"
numverts 0
numtris 0
numweights 0
}
--- End code ---
Produces the same output regardless as to whether the mesh has a parent or not. A second test on a simple textured cube has Blender go through the motions of exporting without actually producing a file; it's been a long time since I used MD5 meshes so I can't remember if there were some necessary requirements for export - vertex_groups and or Armatures etc?.
[EDIT]Console writes the following error on the simple cube
--- Code: ---Exporting selected objects...
Processing mesh: Cube
Traceback (most recent call last):
File "C:\Users\[user]\AppData\Roaming\Blender Foundation\Blender\2.54\scripts\io\
io_export_md5.py", line 637, in execute
save_md5(settings)
File "C:\Users\[user]\AppData\Roaming\Blender Foundation\Blender\2.54\scripts\io\
io_export_md5.py", line 491, in save_md5
), matrix))
NameError: global name 'matrix' is not defined
--- End code ---
keless:
MD5 requires an armature
the samples I'm working with have 2 meshes (one head and one body) and a 30 bone armature which uses vertex groups to bind the bones: so I think yes, both are required.
Then to export, I select the two meshes and the armature (since the script pulls from the list of highlighted objects). You should only have ONE armature in the selection (the script will use the first armature it finds and ignore any others), but will export any number of meshes and ignore any other object types. The meshes can be Tri or Quad, but the script will cut quads down into tris, and throw away any faces with overlapping (forget the term; degenerate?) vertices.
looks like line 492 is a bug, since that should be "w_matrix" not "matrix" -- I renamed the variable from the original to be a little less generic (that is the obj.matrix_world matrix). Don't know why it not complaining about it in my tests, I guess its just accepting a null?
EDIT: just ran my samples thru der_ton's script on blender 2.49b and it seems like a lot of differences (not just a texUV Y thats flipped, but different bone coords and also more verts, tris and weights showing up!)
First thing I'm trying to address is the skeleton code, specifically the def treat_bone() function, since that should be the easiest.
Currently the position of the bones is wrong, but the rotation is correct.
In the original code, there is both a mat and pmat that is calculated, however pmat is stored in the Bone object but never used-- so I'll ignore it, leaving me with the following original code:
--- Code: ---matrix = obj.getMatrix('worldspace')
def treat_bone(b, parent = None):
...
mat = Blender.Mathutils.Matrix(b.matrix['ARMATURESPACE'])*matrix
...
bone = Bone( ..., mat, ... )
...
--- End code ---
Initially, I have translated this to Blender 2.5x as:
--- Code: ---w_matrix = obj.matrix_world
def treat_bone(b, parent = None):
...
mat = b.matrix_local * w_matrix
...
bone = Bone( ..., mat, ... )
...
--- End code ---
And the results of the first two bones in each case:
--- Code: ---"Torso" -1 ( 0.019181 0.011407 7.975472 ) ( -0.707107 -0.000000 -0.000000 ) //2.49
"L_Up_Arm" 0 ( 0.019181 0.011407 12.575473 ) ( 0.000000 0.017672 0.707106 ) //2.49
"Torso" -1 ( 0.019181 -7.975471 0.011409 ) ( -0.707107 -0.000000 -0.000000 ) //2.54
"L_Up_Arm" 0 ( -0.187871 0.180156 12.571256 ) ( 0.000000 0.017672 0.707106 ) //2.54
--- End code ---
In both cases, the rotations (the second set of xyz data) are correct, however the positions are off. Specifically the position of the root bone looks like "x -z y", while the second bone is much further deformed (probably error propagation). In which case the problem seems to be a coordinate system change in Blender from 2.4 to 2.5? Amirite?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version