well done, i really like the shadows around the barrel. 

 

did you use a tutorial specifically to get this done? any resources or steps that you followed?

I would love to dabble in quake models at some point. 

I used experimentation, assumptions on how things work, basic Blender knowledge, and help on that board, but I can help you on some points:

1.I use Blender, a MDL importer, a MD3 exporter plugin, Preach's MD3 to MDL converter tool and QME to properly save the mesh's texture and check if the actual model is Quake-compatible and see if the initial result in Blender is very close in here.

2.For scale references, import quake models from the actual pak files.

3.Do low-poly meshes. Import more quake models if you want references or look for low-poly tutorials.

4.Mark Seems properly depending on the mesh's elements, so texturing is comfortable. You can then organize them better by splitting the image in two and manipulating the UVs here. Don't forget to snap them to pixels.

5.Do texturing in Photoshop or Gimp. I used photoshop, I always start with a 216*216 resolution, and used various Blending options while taking colors from the quake palette, and noise filter to make things more grainy. I go back and forth between Photoshop and Blender to see if the texture's elements are placed right (Use "Reload Image" option in the UV editor). When it's done, I scale down back to 200*200, darken the texture to fit into quake's lighting if necessary, and apply the Quake texture on it. Final exture must be a pcx file with the quake palette applied on.

6.Apply the texture as a Material. Preach made a post about this earlier.

7.MD3 export, MDL convert, QME check/texture save.


For animations, you have to use Shape Keys. It works like this:
https://www.youtube.com/watch?v=ecAHLfp9Nw8

To apply them as actual frames, you have to use the Dope Sheet editor type, where you apply the percentages of the keyframes and register them as frames. It works like the TimeLine, so frames are made consecutivally.

Hope that helped. 

ah so you use blender?

I dunno what it is about blender, find it a bit difficult to work with. 

It's just the one I have the most experience with. I'm sure using 3DMax is good too. 

Ok so for * reasons * that are too long-winded and boring to explain I am writing my own .mdl utility.

Anyway, there are a couple of minor things about the format that I'd like clarifying:

using this page as reference: http://www.gamers.org/dEngine/quake/spec/quake-spec34/qkspec_5.htm#CMDLF

In the file header:

scalar_t radius
----------------------
Should this be the radius of a sphere that bounds the entire model over all frames? Or something a bit more fuzzy like the average bounding radius of each frame? What does the engine do with this?

scalar_t size
--------------------
Average size of the triangles over all frames apparently?? Trivial to calculate, but a peek inside some .mdl files suggests not everyone bothers with this! Naughty.

Of the ones that do bother with it, their value often differs subtly to the one I get when I recalculate it (assuming it's the average over all triangles over all frames) and I'm sure my code is perfectly pukka.

What does the engine do with this? Is it just some obtuse software quake relic? 

From what I remember, Carmack's software renderer would just paint vertices if a model got too far away from the camera ... so know how large the triangles were, on average, was probably tied to that.

I imagine nobody sets it because it's sort of a non-useful optimization these days. 

From what I remember, Carmack's software renderer would just paint vertices if a model got too far away from the camera ... so know how large the triangles were, on average, was probably tied to that.

Fantastic prompt reply cheers! And yes that rings a bell now.

Anyone know about "radius" ? 

radius appears to be parsed but never used by the original engines: https://github.com/id-Software/Quake/search?q=boundingradius

I imagine it was put in to reduce loading time in case the model radius was needed, but they didn't end up using it and didn't bother removing it from the format. 

Ah nice one! So another useless value, like eyeposition. 

If you still use QME as your model viewer (which I still do) then the eyeposition determines where the ground plane for the model is placed. Useless in-game but sort-of handy outside it.

Another useful reference for the format is:

http://tfc.duke.free.fr/coding/mdl-specs-en.html 

There's an error in the link you posted, as well as in the link I posted, which both describe the .mdl format.

Both of them include the same error in their descriptions of the framegroup structure, i.e. they both say

struct
{
long type; // Value != 0
trivertx_t min; // min position in all simple frames
trivertx_t max; // max position in all simple frames
float time[nb] // time for each of the single frames
simpleframe_t frames[nb]; // a group of simple frames
}

but it should be

struct
{
long type; // Value != 0
long nb; // number of pictures in group
trivertx_t min; // min position in all simple frames
trivertx_t max; // max position in all simple frames
float time[nb] // time for each of the single frames
simpleframe_t frames[nb]; // a group of simple frames
}

I guessed where those tasty bytes of crucial extra info were stored and turned out to be correct. 

I imagine the radius thing was probably being used as a culling shortcut at some point ... test the sphere against the frustum, discard the entire model if it's outside of it. But then never shipped ... 

FWIW, ToeTag included the source as a download and it read MDL files successfully ... So if that's of any use to you, it's here:

http://wantonhubris.com/toetag/ToeTag.html

Can't promise it's pretty, but it works. :P

No writing tho... 

Cheers, I've actually got things pretty much working now though :) 

Another error in the quoted text (kinda)

float time[nb] // time for each of the single frames

Aha, you wish! It makes you think that you could have a variable framerate in a framegroup animation. And in software Quake you can. But in GLQuake (and basically all engines nowadays) this is broken, and the time value of the first frame sets the animation rate for the entire thing. So the only option compatible with all engines is having the entire sequence animate at the same rate.

To add insult to injury, you still need to set the values correctly for software compatibility (plus any engines which might try to fix the bug - a futile effort by now). And they aren't set how you'd expect:

wrong:
[0.1, 0.1, 0.1, 0.1, ...]

right:
[0.1, 0.2, 0.3, 0.4, ...] 

http://image.noelshack.com/fichiers/2015/42/1444897285-gatling1.png
http://image.noelshack.com/fichiers/2015/42/1444897286-gatling2.png
http://image.noelshack.com/fichiers/2015/42/1444897284-gatling3.png
http://image.noelshack.com/fichiers/2015/42/1444897284-gatling4.png
http://image.noelshack.com/fichiers/2015/42/1444897282-gatling5.png

Quakespasm webm: http://webm.host/5aed6/vid.webm
Darkplaces webm: http://webm.host/9f98d/vid.webm 

But I think that muzzle flash is a bit over the top. I would tone it down a bit, it looks cartoony as it is now. Or was that the intention? 

 

Preach - Cheers! That's some useful info to have. It sounds like it could be nice to have the corrected .mdl format info in the Quake Wiki :)

Daya - I like the cut of that weapon's gib. I think I'd have gone with a smaller/subtler muzzleflash, and I'm not too big a fan of the raised "idle pose" of the weapon, but basically do what you want and don't listen to me. 

I may update the quake wiki myself with all the .mdl info. Could be a fun little distraction. 

You worried that team fortress might outcode you, but there's no doubt now your model surpassed what they could do. 

that's really awesome to see in game, love it mate! 

Nicely done man. Look forward to seeing a map use that weapon.