Cheapy's been demanding this for a long time, so yesterday I sat down and wrote it. It's basically an adaptation of the MD2 code for blender, since the file formats are somewhat similar. It took me almost as long to create some test models that would export to md2(and so be a good test for the mdl code) in blender as it did for me to write the modifications to the code! So I'm still not gonna be getting rid gmax any time soon, but it's useful to have a utility like this for greater control of the export process when needed. Anyway, here's the first beta, exporting animated frames is broken at the moment, but everything else seems to be in order.
http://people.pwf.cam.ac.uk/~ajd70/mdlexport.py
Drop it into your Blender/.blender/scripts folder. Tested with 2.4.3, let me know if you find anything bugs besides the animation one : - ).
Blender MDL export
I swear I tested it and it saved, but I didn't check the file I got was the real thing, turns out it was just an error page.
http://people.pwf.cam.ac.uk/~ajd70/mdl_export.py
It's based off the md2 exporter because that's the one that comes with blender, and also because mdl is much more similar to md2 than md3 - both formats compress vertex coordinates to a single byte, for instance, although most of that code got rewrtten anyway.
I'm pretty sure the vertex normals code should work, to the extent that quake allows. There's a list of 162 allowed normal vectors, and the code chooses the one that minimizes the dot product of the vertex, then records that that index as the 4th byte of the vertex coordinate. The md2 code added 2 to each index, which I don't think should be done, maybe that was causing the problem. Anyway, that's gone from this version.
(aside:this part of the code is pretty inefficient, making it take a noticably long time taken to export the model. If anyone knows a good optimisation for calculating with anorms.h, like what order the normals are in, let me know...)
I've not noticed dodgy vertices in this version, although admittedly only a day's testing so far. I did test it with a model that broke previously in the md2 exporter, and it seemed to work. The vertices do have to be handled quite differently for mdl format, since you need to add multiple vertices where triangles are seperated on the skin, even if they are joined on the model itself. One warning that should come with the file is that the program uses the first frame to determine if vertices are joined. If they occupy the same position in the first frame and on the skin, they are in effect welded. So you may need to add a "seperated" first frame to the model if this causes problems. For most models it shouldn't be an issue.
The origin thing is still there, I'll look into why it does it and if it can be fixed in a later version. Also, the models are rendering all black in glquake but fine in winquake/darkplaces. Changing the skin seems to fix it, and so I'm not that concerned, but I can't see what's up with it so any suggestions are welcomed.
http://people.pwf.cam.ac.uk/~ajd70/mdl_export.py
It's based off the md2 exporter because that's the one that comes with blender, and also because mdl is much more similar to md2 than md3 - both formats compress vertex coordinates to a single byte, for instance, although most of that code got rewrtten anyway.
I'm pretty sure the vertex normals code should work, to the extent that quake allows. There's a list of 162 allowed normal vectors, and the code chooses the one that minimizes the dot product of the vertex, then records that that index as the 4th byte of the vertex coordinate. The md2 code added 2 to each index, which I don't think should be done, maybe that was causing the problem. Anyway, that's gone from this version.
(aside:this part of the code is pretty inefficient, making it take a noticably long time taken to export the model. If anyone knows a good optimisation for calculating with anorms.h, like what order the normals are in, let me know...)
I've not noticed dodgy vertices in this version, although admittedly only a day's testing so far. I did test it with a model that broke previously in the md2 exporter, and it seemed to work. The vertices do have to be handled quite differently for mdl format, since you need to add multiple vertices where triangles are seperated on the skin, even if they are joined on the model itself. One warning that should come with the file is that the program uses the first frame to determine if vertices are joined. If they occupy the same position in the first frame and on the skin, they are in effect welded. So you may need to add a "seperated" first frame to the model if this causes problems. For most models it shouldn't be an issue.
The origin thing is still there, I'll look into why it does it and if it can be fixed in a later version. Also, the models are rendering all black in glquake but fine in winquake/darkplaces. Changing the skin seems to fix it, and so I'm not that concerned, but I can't see what's up with it so any suggestions are welcomed.
Re: Blender MDL export
Slightly off topic as I have not tried this MDL export with Blender, but your GMax/Quark/QME tutorial from Quake Expo kicks major ass.Preach wrote:Cheapy's been demanding this for a long time, so yesterday I sat down and wrote it. It's basically an adaptation of the MD2 code for blender, since the file formats are somewhat similar. It took me almost as long to create some test models that would export to md2(and so be a good test for the mdl code) in blender as it did for me to write the modifications to the code! So I'm still not gonna be getting rid gmax any time soon, but it's useful to have a utility like this for greater control of the export process when needed. Anyway, here's the first beta, exporting animated frames is broken at the moment, but everything else seems to be in order.
http://people.pwf.cam.ac.uk/~ajd70/mdlexport.py
Drop it into your Blender/.blender/scripts folder. Tested with 2.4.3, let me know if you find anything bugs besides the animation one : - ).
I have been foobar'd in every attempt to make a valid .MDL from an MD3 made in something else so far up to now.
I've not seen a tutorial addressing such a complicated issue done so well and so thoroughly.
/is humbled by your effort and investment of time in it
Re: Blender MDL export
Glad you found it useful. It's something that really frustrated me as well, I saw that with was possible for the first time with some models in Q1A, and so tried to replicate it. At first it seemed to always fail, then I got it to work once or twice, but couldn't see why quark would load some models but not others. So once I had a way that worked, I thought it was the kind of thing that really should be shared. I kinda want to go back and tidy it up still though, I'd do some things differently, there are typos and badly phrased bits I'd change. Once I get a proper website sorted...
Re: Blender MDL export
New version up!
http://people.pwf.cam.ac.uk/~ajd70/mdlexport.py
Features include:
*Assigning the proper size of texture to the model(The last version would give the model the right dimension in the header but export the amount of texture data for 256X256, which would usually create invalid models)
*Reads the actual colours from the texture! The texture now must be entirely in the quake palette, there's no conversion to the palette for other images. I did have the export abort if any such pixels were found, now it's just a warning and those pixels are made black.
*Removed the restriction on translating and scaling the object in object mode, the transformations are now applied to the model. The same is not true for rotation, since correcting this would involve applying the transformation to each frame. Scaling and translating can be done through the model header.
*Fixed the frame list loader, thanks to dayfive
Not included yet are settings for modelflags and all the nice GUI improvements. And I still don't think animation is working, although all the mechanism is there to export multiple frames. The problem seems to be blender isn't updating the mesh correctly when the frames change. The problem with black models seemed to just be a problem with writing a totally blank skin, now that non-placeholder skins are written the models work fine. Guess it must just be some weird engine thing...
http://people.pwf.cam.ac.uk/~ajd70/mdlexport.py
Features include:
*Assigning the proper size of texture to the model(The last version would give the model the right dimension in the header but export the amount of texture data for 256X256, which would usually create invalid models)
*Reads the actual colours from the texture! The texture now must be entirely in the quake palette, there's no conversion to the palette for other images. I did have the export abort if any such pixels were found, now it's just a warning and those pixels are made black.
*Removed the restriction on translating and scaling the object in object mode, the transformations are now applied to the model. The same is not true for rotation, since correcting this would involve applying the transformation to each frame. Scaling and translating can be done through the model header.
*Fixed the frame list loader, thanks to dayfive
Not included yet are settings for modelflags and all the nice GUI improvements. And I still don't think animation is working, although all the mechanism is there to export multiple frames. The problem seems to be blender isn't updating the mesh correctly when the frames change. The problem with black models seemed to just be a problem with writing a totally blank skin, now that non-placeholder skins are written the models work fine. Guess it must just be some weird engine thing...
Been a little busy with Travail and Quoth2 to get any work done on this, but since the latter is only a few days away from release(documentation only), I'm free to work back on some old stuff. So yeah, why not?leileilol wrote:Are you still working on this?
I guess the most obvious next thing to do would be to make a corresponding import script so everything can be worked through blender. I think something's going wrong with the animation settings so that instead of reading each frame of animation, it's writing the first one to each subsequent frame. So that should be fixable, I hope. Anything else pressing about it?
Try this new version, which should fix texture coordinate exporting(which was broken through my lack of foresight) and animation exporting(which was broken by blender adding features to getFromObject then making the new behaviour the default). Tested in 2.4.4, it might work in 2.4.5 if they haven't changed things again.
http://people.pwf.cam.ac.uk/~ajd70/mdl_export.py
And yeah, assuming that your model only uses one texture, then this should now be able to handle any UV setup you have by adding vertices. The only time it could fail is if the base frame(frame 1) is weird in some way. The exporter has to try and guess at the topology of your model based on the UV's and the first frame, testing every frame to see if the vertices need to be separated would be too taxing.
http://people.pwf.cam.ac.uk/~ajd70/mdl_export.py
And yeah, assuming that your model only uses one texture, then this should now be able to handle any UV setup you have by adding vertices. The only time it could fail is if the base frame(frame 1) is weird in some way. The exporter has to try and guess at the topology of your model based on the UV's and the first frame, testing every frame to see if the vertices need to be separated would be too taxing.
Adquedit or QMe will do it, and it's something that should make it into the next release of this script. If you only have a hex editor, you want to change the 20th digit in the file, the preceeding four values in order should be # verts, # faces, # frames, and then a 1 for synctype.motorsep wrote:Awesome! I gotta try this one. Btw, what util allows to change flags in Quake MDL files?
I don't really want to have to reinvent the wheel, when there'sP.S. Would be nice to have either blender2md5 redone into blender2smd or blender2dpm. Can you do that, Preach, please?
http://forum.moddb.com/thread/13334/?page=1 already. My understanding is that smd is the same for hl, hl2 and compiling models for darkplaces.
LordHavoc has written a modeltools program that changes flagsPreach wrote:Adquedit or QMe will do it,
The SMD export/import is very broken and the author isn't very interseted at fixing it.Preach wrote: I don't really want to have to reinvent the wheel, when there's
http://forum.moddb.com/thread/13334/?page=1 already. My understanding is that smd is the same for hl, hl2 and compiling models for darkplaces.
i should not be here
It's be just as easy for you to fix it as me though...leileilol wrote: The SMD export/import is very broken and the author isn't very interseted at fixing it.
Also, the quickest way to change flags right now is probably to hack the script, go to the line that reads
Code: Select all
mdl.flags = 0