I might be completely wrong, but this sounds like a bug with the skeleton. If it is rigged, and half the rig is simply flipped (arms legs) then the flipped bones can have a negative scale, which fucks up the position of the verts, which try to maintain their true position despite the negative scale transform.

Wild shot in the dark. 

I checked that this morning and found that to be the case for the left arm mesh object, the scale was negative, but even after fixing it still didnt work, and I sent that 2nd one to preach as well. I don't have any armiture/bone/skeleton for the mesh. I like to animate each frame by hand, it lends better to the original style I'm going for better.

@Preach, I'll give that a wack. In the editor, there are 3 objects, the 2 arms and the 1 body. I'll combine them as one and reexport and give that a whirl. Might be something to do with the way the blender exporter combines mesh data from multiple objects, or rather doesnt. I hope it works! I have a lot more npc's to maje after this one. 

do you mean you are moving vertices manually for each frame? That's hardcore man... but honestly, you should look into animating with bones. You can't get good proper movement without expending 10x as much work.
You don't need any fancy thing like max's Biped or anything. Just using primitive boxes as bones can save you hours and hours or work. 

I think I figured it out. Its to do with local origin placement. The object's local origin needs to be equal to global coord 0 0 0, the world origin in the editor. Any deviation from 0 0 0 will cause an issue when converted to mdl. Multiple mesh objects doesnt affect it. It all converts fine so long as I have an object origin of '0 0 0'.

Perhaps md3tomdl should check that the md3 origin value is equal to 0 0 0 and if not adjust each vertex by the origin amount to zero out the md3's origin before converting. 

I spent a long time looking at the code that was working out the bounding box for the model, thinking that's where the wrapping was occuring. MD3 files can have a different origin in each frame (but rarely bother), so when you mentioned non-zero origin, I thought it might relate to that. But the bounding box code accounts for that already.

Then I realised that it wasn't an overflow, but an underflow! The bounding box was accounting for the frame origins, but the code that actually exports the vertices does not. I need to get a compiler installed on this new computer, then I'll try and bash out a fix... 

Yeah i do and I dont use skeletal animation. It really depends on the model. For a very simplistic robot it doesnt make much difference. For a floating blob of goo: http://www.spriters-resource.com/resources/sheets/28/30623.png Theres really no better way. Anyways, it helps me keep to the original style by having fewer frames. 

Is a bitch. 

I'm gonna put a proper post on the blog later on, but for now grab the patched version

http://www.quaketastic.com/files/tools/windows/misc/md3tomdl-0.4.zip 

The mesh itself is healthy, but the offset from the origin is getting doubled. If the md3 is 16 units from the origin the mdl will be 32 units away (regardless of axis).

I noticed you added in " + f.org[0]" in mdlexport.cpp (line 215) which I'm assuming is what fixed the origin mix-up. See line 7 in md3import.cpp where you already added this to the frame.mins and frame.maxs... so is this doubling it?

Psst...if I don't actually even have any line for a skinfile in the compile txt then it crashes (yes I know I'm a basket case).
I'm thinking that writedummyskin(mdlfile) doesn't actually get called if skinfile == "". I guess it's something to do with !q1skin.height not being true in mdlexport.cpp->export_to_mdl{} (see Line 147)?

I'd try compiling it myself with some trial and error, but I haven't bothered to install any c++ IDE at the moment. 

Thanks by the way! It's awesome to get such quick feedback. You're a real coding guru around here, it means a lot that you can do all of this. You're the best! 

I'll try and fix all these things before I put 0.4 up. got a favour to ask first though: my tools don't ever create MD3s with an origin key to test, and I could really use a specific pair of models here. Could you send me two MD3 models, which are identical except for having different offsets? Like maybe 32 units from the origin on one, and 50 units on the other. It will make it easier to spot the doubling taking place. Thanks!

The skin issue is due to me failing to initialise some values properly, looks like it works in my local copy now! 

the 'q3_frame.org' field in the frame info is strictly a culling origin. apparently it can also be used for fog. It will not move the mesh up/down, unlike mdl.
using it to determine either the bounding box or the verticies is a bug. probably you should ignore it completely (in theory, you'll find a decent model has it set to the center of the frame's bounding box). 

 

That would explain everything, the correct fix (deleting the org stuff from the bounding box, not adding it to the vertices) is in place and the robot now hits a minimum of -24, which I assume was the intention. Here's a link to the new 0.4 download, once I hear a thumbs up from Qmaster I'll update the blog.

http://www.quaketastic.com/files/tools/windows/misc/md3tomdl-0.4.zip 

I'm not getting any different results? Maybe you uploaded the wrong exe or something? I deleted all md3tomdl's on my end and redownloaded again, but it still doubles away from the origin, and there's still the wierd crash without a skinfile line (not that it matters much, I have skinned it now, but it's nice to have for robustness). I checked the source code that you provided and it looks like you fixed it for both cases, but the actual exe doesn't seem to have the changes?

Dunno what's up. 

I'm going to the source. I think Preach's program works fine enough for his workflow...it's blender's exporter that doesnt provide a similar md3 file. From what I've read, Pop'n'Fresh's md3 exporter for gmax determines the bounding box for each frame. I found the source code for it here: http://forums.duke4.net/topic/1065-md3-exporter-for-3ds-max-2010-x86-and-x64/ I'll check it out when I get a chance and compare it with the katsbits exporter for blender. I might have to modify the blender exporter to match the gmax one. Translating from c++ to python here so wish me luck. 

I think the uploads might havegot mixed up, yes, try this one.

http://www.quaketastic.com/files/tools/windows/misc/md3tomdl-0.4.zip 

All good. Animation is working fine too so far! :) 

So what's the easiest path for someone who wants to make a static prop to get it built and into Quake in MDL format? I saw, to my surprise, that Milkshape is still selling full licenses (wtf?) and I'd like to stay legit if at all possible. 

I know Gb got a pipeline to get models from it into Quake. 

Oh neat, will check that out... 

http://quakeforge.net/ has a Blender plugin, taniwha is super nice and helpful in case it should not work. 

If you have Maya at home I've written some python doodads. They go through a hacked modelgen.exe atm but I'm planning on merging it with Preach's pymdl so it all works within Maya. 

The blender route seems the most sane at the moment ... I can still make the model in MODO and then just export/import into Blender and spit it out from there. I hope! 

Of course I'm totally biased toward blender but I'm biased for a reason, it's awesome. I was considering looking at creating a blender addon using Preach's qmdl python package since all of blender's addon's are scripted in python, but it currently has an md3 exporter which works nicely with Preach's md3tomdl, especially for static props (don't forget to unwrap them before using blender's md3 exporter! got my goat several times for that one)