Instructions:
Extract the zip and put the file in scripts/addons.
You'll need to turn it on in the user preferences menu.
Version 1.6.1
Change log:
- added triangulate
- added auto scaling
- added default user settings variables (near top of script)
- changed skin path look up (custom prop., material name, then 'NULL')
io_export_md3.zip(5.72K) Number of downloads: 1202
Version 1.6
Change log:
- fixed object transform data not being exported.
- added support for armature transform data. (must be named "Armature")
- cut the need for a custom property in order to export uv map. (still supports encoded skin paths)
- cut ignore uv option entirely
- changed default dump all setting to false (no more 40MB logs)
This post has been edited by Drek: 28 March 2017 - 03:43 PM
Does this one export normals as-is or does it force-regenerate them before exporting?
It still generates normals on export. That's all very old code that I haven't touched. I don't see any mention of face normals at all. Only this one section from the module md3vert mentions normals.
# copied from PhaethonH <phaethon@linux.ucla.edu> md3.py
def Encode(self, normal):
x = normal[0]
y = normal[1]
z = normal[2]
# normalize
l = math.sqrt((x*x) + (y*y) + (z*z))
if l == 0:
return 0
x = x/l
y = y/l
z = z/l
if (x == 0.0) & (y == 0.0) :
if z > 0.0:
return 0
else:
return (128 << 8)
lng = math.acos(z) * 255 / (2 * math.pi)
lat = math.atan2(y, x) * 255 / (2 * math.pi)
retval = ((int(lat) & 0xFF) << 8) | (int(lng) & 0xFF)
return retval
I read into this more and I don't think it's possible to keep face normal data in the md3 format. There is no place to store it.
Here is the section from savemd3 that calls nvert.Encode
for vi in vertlist:
vert = fobj.vertices[vi]
nvert = md3Vert()
nvert.xyz = my_matrix * vert.co
nvert.xyz[0] = round((nvert.xyz[0] * settings.scale) + settings.offsetx,5)
nvert.xyz[1] = round((nvert.xyz[1] * settings.scale) + settings.offsety,5)
nvert.xyz[2] = round((nvert.xyz[2] * settings.scale) + settings.offsetz,5)
nvert.normal = nvert.Encode(vert.normal)
fobj is the mesh itself at the current frame. The script isn't changing normals here, and I don't think that nvert.Encode actually changes anything either. So I am saying that it does indeed export vert normals as is, then forces face normals to be square to the face itself. Please correct me if I am wrong on any of this, it's a tricky thing to test.
The only thing that I am really missing at the moment is the ability to use modifiers in the stack during export - specifically the edge-split, which is vital for controlling smooth-groups. I've not tried it with either an array or lattice either, which would be rather usefull, for something we were talking about earlier.
I just ran a basic test using Suzanne the monkey. Gave her an edge slit modifier, left it in the stack. At this point it has 507 verts in edit mode (original count) then 1200ish in object mode. The md3 I export has all 1200 verts, and the extra edges. Is there an issue with how the edge split looks in the md3? Or is it giving you errors?
This is from the blender manual:Blender Wiki
Quote
In a modifier stack the order in which modifiers are applied has an effect on the result. Fortunately modifiers can be rearranged easily by clicking the convenient up and down arrow icons. For example, (Stack ordering) shows SubSurf and Mirror modifiers that have switched places.
In the tests I've done with your sample .blend I have, as long as the edge split is put in front of the armature it exports a good md3. The only oddity is that it comes out with more verts than what Blender says should be there. (MD3 15K verts, Blender in object mode says it should be 13K verts.) I can't really explain why that is happening.
I just ran another quick test using array and bevel on the default cube. Array works!! Bevel is a no go as it makes quads, so for the time being at least, some modifiers may need to be applied and triangulated before export.
I would like to publicly thank you Tea Monster for all your time and work beta testing this script with me. Couldn't have done this without you.
I'm thinking what is happening is that it is literally splitting the mesh at certain points. So each time you break an edge, you will get twice as many verts in those edges as you now have two, where before there was one.
This post has been edited by Tea Monster: 24 March 2012 - 06:20 PM
- How do I set the number of frames to be exported? The dafault seems to be 250.
- I exported a test cube but in md3 compiler it seems there is no object in the file. Is anything more than selecting the object needed?
1. Go into the 'Time' window and on the main bar, set the 'Start' and 'End' frames for what frames you want to export.
2-a. UV Unwrap.
2-b. Convert to tris
Also, there is some strangeness where you have to scale up your mesh by a factor of 20 or so or you can get some distortion on complex meshes.
I want to touch on the subject of scaling. I just want to add that scaling objects either way too big or too small is a bad idea for this format. A good rule would be that your exported md3 should nicely fit the view window in Npherno, or at least be recognizable without zooming. There is a scale setting in the export gui if needed. The reason this happens is because the script rounds vert location data to 5 decimal points in order to save file space.
Also, I never used modifiers much before the past few days. Especially leaving them in the stack like this. I love them!!
I love them as well. The reason I want to use the edge split is to 'break' the normals at certain places. this creates hard edges on certain seams and leaves others intact. The reason you would want to do this is the breaks in certain types of machinery for example, or the edges of armour on a critter. You would want to keep the critters skin smooth, but you'll want to break the edges of armour to keep them looking 'crisp' to get the correct lighting and shadow under Polymer.
As to scale, I'm wondering if there is something in how Blender scales objects and how that translates into other soft. You can see the number of files in the HRP that have scale figures in double digits.
Looking forward, have you thought at all about bmesh?
This post has been edited by Tea Monster: 24 March 2012 - 06:32 PM
Yeah, I've read up on it. It is all there available to me via scripting, but it is also being changed practically every day in preparation for the next release, a few days away like always. I'm fairly certain I can use it to do "proper" triangulations, as the results of using quad to tris in the exporter was a big disappointment. I don't see how it will break anything in the script too bad. I've already started moving forward with another version, although slowly for now, waiting for 2.6.3
I will need input from the EDuke32 team members, but I think it would be a good idea to add your plugin to the Build tools once it is feature-complete and stable, since Plagman already has his one for 2.4 there. With your permission of course.
This post has been edited by Hendricks266: 24 March 2012 - 07:20 PM
I will need input from the EDuke32 team members, but I think it would be a good idea to add your plugin to the Build tools once it is feature-complete and stable, since Plagman already has his one for 2.4 there. With your permission of course.
I have quads to tris working much better for me, good enough that I will post an update soon. Check the first post in a few hours.
It will not triangulate a screw modifier for me. Oh well, edge splits, armatures, arrays, curves, and more all work now with quad meshes.
I still recommend exporting with triangles. You can only leave so much up to scripting assumptions before something goes wrong. And you get more control over your results, but this is great for testing work in progress.
More ramblings about Blender scaling and md3 world space: I added a float slider to the gui to replace the default rounding value of 5 decimal places. With tests up to 30 decimal spots I still get that squarish bouncy vert issue. So I conclude that Blenders microscopic scaling just doesn't export well. Blender is different in that you can scale something infinitely small then infinitely large and lose no detail in the process.
MD3 coordinates are 16-bit integers, so yeah you lose precision when converting as-is from small floating point values. What you really want is to find the bounds of the model you're exporting and scale your coordinates in the exporter such that these bounds end up lining up with the max/min value that you can represent in these MD3 coordinates, and then print which scale to use in DEF to counterbalance that such that the scale ends up being fixed between blender and BUILD units. This way people can build models with an exact in-game scale and export it without having to worry about precision issues when storing it on disk.
Note that you're very lucky, MD2 can only represent coordinates in an 8-bit integer, which is 255 different values at most.
I had thought of that, but bounding box values can change during animations so I left it be. My idea had the modeler entering the "in game size" of the model in feet, from there I can get the bounding box info and scale it to closely fit the desired size, therefore making the def scale very close to 1. I am totally willing to code it, as a check box option.
Can I ask you to name one sprite, model, or other easy reference place and give it a "height" for me? I will use that as reference for scaling.
io_export_md3.zip(6.11K) Number of downloads: 1002
Here is my quad to tri version if anyone wants to test it. I will save a big update for after I try out this scaling idea.
My idea had the modeler entering the "in game size" of the model in feet
I don't like the sound of this idea because:
1. There is no true reference point between in-game and the real world (and it probably varies based on map and mapper).
2. Most people would just throw out a random estimate giving it little actual worth.
3. Regional differences of units (feet vs. meters).
Would it be possible to implement Plagman's idea by cycling through all the animations and finding the model's net boundary coordinates? Really, that is what you should strive for. This would involve no guesswork on the part of the modeler and would be absolutely correct.
This post has been edited by Hendricks266: 25 March 2012 - 04:31 PM
I slept on this idea, and I woke up with this.
1) Find avg. bounding box size for entire scene being exported.
2) Scale scene to fit nicely into md3 world space. From (0,0,0)
3) Return my export scale factor to the user.
Assuming we come up with a good ratio for blender units to build units scaling, and the model is made with this in mind. The scale in def will be 1/export scale. If the model isn't built with an exact in game scale then we are no worse than before.
I'm off to work, will start on this tonight. Does my plan seem sound to you guys?
It is not the average you are looking for, but the actual min/max coordinated over all animations played out. Think of it as a box that expands whenever the model pushes its boundaries when an animation crosses them but never shrinks, and all animations are cycled through causing the box to represent the boundaries of the entire animation set with nothing outside it.
Ya that's right. It was the death of the md3 for ID. Mesh animations multiply file size with each frame.
An update for where I'm at. I've got min/max sizes out of blender, and I have a min value for "good" md3space. I am getting stuck on finding the max size to export an object. I get errors if actual md3 values exceed binary short format SHRT_MAX, but the error happens with different bounding box values depending on the object being exported. I think I will let the error show for massive objects (1000ish blender units) For now the script will only scale objects up if they are too small.
Next, to find that conversion formula.
x build units = y blender units
IPO animations and UV mapping and triangulate work nicely.
I'm going to test the model size thing later.
At the moment you get a really ugly python error on top of the screen if you try to export without a UV map, and there is no warning if you don't triangulate.
Now you can argue that if you are doing either of these things, then this is the least of your problems , but you may want to have a more elegant user warning rather than the python default one.
######Find scale value for fitting very small objects to md3 world space
scale_md3 = True
if settings.scale != 1:
scale_md3 = False #Allows manual scaling to override auto scaling
scene_maxs = [0, 0, 0]
if scale_md3 == True:
for obj in selobjects:
if obj.type == 'MESH':
obj_maxs = [0] * 3
for frame in range(bpy.context.scene.frame_start,bpy.context.scene.frame_end + 1):
bpy.context.scene.frame_set(frame)
for i in range(0,3):
if obj.dimensions[i] == 0:
scale_md3 = False #Cancel if any object has an axis dimension of 0 (2D Objects)
obj_maxs[i] = round(max(obj_maxs[i],obj.dimensions[i]),5)
if dumpall: message(log,"Object bounds for"+str(frame)+str(obj.dimensions))
if dumpall: message(log,"Object maxs"+str(obj_maxs))
scene_maxs = max(scene_maxs,obj_maxs)
if dumpall: message(log,"Selected objects maxs"+str(scene_maxs))
if scale_md3 == True:
scene_minimum = min(scene_maxs[0],scene_maxs[1],scene_maxs[2])
scene_maximum = max(scene_maxs[0],scene_maxs[1],scene_maxs[2])
if dumpall: message(log,"Selected objects min single axis dimension "+str(scene_minimum))
if dumpall: message(log,"Selected objects max single axis dimension "+str(scene_maximum))
if scene_minimum < 25:
my_scale = round(25/scene_minimum,2)
if scene_maximum * my_scale > 750:#Selected Objects bounding box ratio for auto scale is
# 1 min axis dimension to 30 max axis dimension
scale_md3 = False #Cancel if autoscaling makes any object too big (??750??)
if scale_md3 == True:
settings.scale = my_scale
message(log,"Scaling export by a value of " + str(my_scale) + " to fit MD3 space")
En Anglais, I took the largest value of each axis dimension for each frame in each selected object. If the smallest axis ends up with a value less than 25 blender units (approx min size for higher detailed MD3s) then scaling is set to make that axis 25. Unless it makes another axis exceed 750 (educated guess at a max boundry) If scale is set manually on export or if any object is 2D it skips auto scaling.
I am well aware that this is not the most accurate method and may not auto scale when it probably should. I ran loops to get the true min max bounds of every vert in all selected objects. It was slightly more accurate on when it can auto scale, but it doubled run time for the script and crashed blender on me more than once, so I tried a less cpu expensive method and am happy with the results.
If anyone finds something that should be scaled, yet manages to slip through the code, please share it so I can try to improve this feature.
PS. The scale factor used is printed out in the log file.
@Tea Monster, Blender doesn't have a 'more elegant' error message. I've run some scripts that have had this error message "ERROR: for now look in console" It says the same thing in the console HA. Maybe soon they will add something I can control easier. About triangulating, default is now set to True, but will only run if it finds non-tri faces.
Added March 31st: Wow, big post but this isn't bump worthy so I will just tack it on here.
I missed a line of code cancelling auto scale if it just isn't needed, because the export fits properly already. Opps, I updated the first post with it fixed, sorry to the one downloader
This post has been edited by Drek: 31 March 2012 - 06:55 AM
dreks_cube.zip(167.38K) Number of downloads: 1335
I've found a blender to build units ratio. 100 blender units = 1024 build units
I included my work, a simple map, duke3d.def, a scale increasing animated cube model, and its .blend but I would appreciate someone with more experience confirming this for me. My ratio is very, very, close, but I don't think it's "perfect."
As an easy reference for people. This makes the default cube equal to about 20 build units, or just a little bigger than a box in the smallest grid in mapster.
From here I am working an Eduke32 export option into the script, where the modeler can use either this ratio or input his own and the script will return a scale value for def code.
dreks_cube.zip
I've found a blender to build units ratio. 100 blender units = 1024 build units
I included my work, a simple map, duke3d.def, a scale increasing animated cube model, and its .blend but I would appreciate someone with more experience confirming this for me. My ratio is very, very, close, but I don't think it's "perfect."
As an easy reference for people. This makes the default cube equal to about 20 build units, or just a little bigger than a box in the smallest grid in mapster.
From here I am working an Eduke32 export option into the script, where the modeler can use either this ratio or input his own and the script will return a scale value for def code.
How did you find it? Technically one Blender Unit is supposed to by equivalent to a meter, so my question is what is a Build unit? This is very critical for me, since my models are to 'scale', and the reference you are defining would eliminate guess work.
This post has been edited by Hank: 31 March 2012 - 03:11 PM
How did you find it? Technically one Blender Unit is supposed to by equivalent to a meter, so my question is what is a Build unit? This is very critical for me, since my models are to 'scale', and the reference you are defining would eliminate guess work.
I used mapster x,y BLD units as foundhere, lol(I was just reading this page and came back here to correct a mistake I made)
I have my script returning a def code if you tell it which one axis you want to use for scaling and how big you would like it in build units. PM me an email if you'd like to test it with me, it's still WIP to be released when 2.6.3 comes out this month.
I figured 6'3" using the "generic scale" on that RCTM page thats 800 x,yBLD units. Let's not start an argument about Dukes height, I just read through one on the old 3DR forum.
This is going to be harder than I thought, with 3D mode using separate units than 2D it gets to be pretty confusing. My thoughts are that if the user selects to use the z axis as scale reference then the size should be measured in zBLD units. Either that or we agree that a certain value in zBLD units = x,yBLD units. My quick ratio, based on what I just read is that: 1zkey = 1 pgup = 1024 zBLD units = 64 x,yBLD units
Added:
Did some in game tests 32 pgups = 2048 x,yBLD units this verifies the ratio. Now what do you guys want, a script that only uses x,yBLD units or should I allow for one or the other depending on axis used for reference?
Added some more:
I'm going to make a drop box style selector for whatever build unit the modeler wants to use. Say a choice between x,yBLD units, zBLD units, or zKEY aka PGUP units. I will also look into using sprite x,y measurements. That would be good for replacing 8-bit art tiles with models. Built to scale using the tile as a background pic, then just give the exporter the tiles width or height. Def scale in the log.
This post has been edited by Drek: 31 March 2012 - 06:29 PM
Help
Duke4.net
DNF #1
Duke 3D #1
io_export_md3.zip (7.31K)
