I guess I can safely say that I won't resume my tinkering with Quake models any time soon, so I'll just share the only thing that's somewhat finished.

https://drive.google.com/file/d/0B9DxOfPvG2G1Sk41OEpBYlhTZGM/edit?usp=sharing

Old shot:

http://i.imgur.com/R5G56tM.png

Animation is interpolation-friendly. 

very cool, kind of organic vibe to it. the model could also double as a lightning gun variant. 

I was going to ask for that model so i can look into why glquake is messing up the texture coord vs winquake :-) 

Awesome work Dwere :D 

of pixel shells (lid is optional extra) 

You know what'd be cool? If ammo could detect map types, that way you could have runic, medieval and base type boxes! :) 

You know what'd be cool? If ammo could detect map types, that way you could have runic, medieval and base type boxes! :) 

All it takes is a simple QC modification. 

that could easily be done. (keys already do it) 

I guess the next version of Quoth can add it as a feature then. ;) 

 

Some examples of the hellknight in paper, made with pepakura.
Now he will be my action figure ever!
Little hard to paint on the skin right.
1 2 3 

@Preach: I'm trying to create a model and it looks ok in darkplaces if I simply use the md3 file, but whenever I "compile" the mdl file from the md3 file it comes out all poly garbled, like the faces are pointing the wrong ways and small faces get stretched or combined and folded inwards on itself. I suspect it's the exporter that I'm using with blender because the skin works and the model is visible so I think md3tomdl is working fine.

Preach, what md3 exporter are you using? and what blender version? I have 2.71 and am using katsbits md3 exporter version 1.6.3 (for blender 2.63a from this page: http://www.katsbits.com/tools/ 

Maybe this might be useful: http://www.quakeunity.com/file=481
I use it when importing md3s exported from max, but you could try just importing the blender md3 and see if anything looks wrong then saving from that application before using preach's converter. 

I use GMAX and the md3 export which comes with that - by pop'n'fresh I think... If darkplaces loads the md3 fine then it's more likely a bug in md3tomdl, probably some edge case that the parser I wrote gets wrong. Can you e-mail me a copy of the file so I can take a look. 

Don't forget about http://www.icculus.org/qshed/qwalk/ 

actually, you'd probably be better using qwalk as the npherno tool is ancient. 

Hey @Preach I sent you the md3 file and a screenshot of what it looks like on my end. 

Hi Qmaster. I've got your e-mail and taken a look, but I don't have a complete fix yet. I can reproduce the bug - when I compile with md3tomdl I also get a corrupted model. It's not all bad news with the model though. It seems correct topologically - the triangles are all connected to the correct vertices, it's just those vertices which are out of place.

Specifically for this model, if you translate the right sets of vertices about the place you can get it looking normal. The place where the conversion suffers most is the right arm of the robot - half of the vertices have been displaced to the robot's far left. Then the head vertices have been moved to the bottom, and a few vertices from the front have been displaced to the back.

It's almost like lots of the vertex coordinates are overflowing and wrapping round to the other side of the model. That might be possible if md3tomdl miscalculates the bounding box for the original model. Having multiple surfaces in the model might be the issue here - can you combine the whole model into one and re-export to md3? Since you can't get multiple surfaces in a mdl file, I tend to only use one and that code may be under-tested... 

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.