I have one for GIMP somewhere, if someone interested...

I'm interested! Sorry I only replied to this post now; was away from my primary computer for a while and out of the loop. 

Might have drunk too much beer, as the width of the skinfile is 480,
not the height.
Always get confused with these latitudes and longitudes.

The height of the waterfall skin is 215, so it could be made larger to 320.
But that's qmle maximum extention. 

Which version of QME are you using? In my copy I can set the skin bounds to 512 by 512... 

max skin height seems to be either 200 or 480 in id's engines: https://github.com/id-Software/Quake/search?q=MAX_LBM_HEIGHT&type=Code

Not sure why it appears to be 480 in winquake but 200 in quakeworld. I guess someone would need to test specific exe's to be sure.

It's still 480 in Fitzquake and Quakespasm.

So I guess if you're going over 200 pixels high, and want the most resolution you can get, try 480 high? 

if it's still in fitzquake/quakespasm, that seems like a good idea to change from an error to a warning (load it, but warn that it won't work in standard engines) 

http://image.noelshack.com/fichiers/2015/41/1444334148-gatling-gun.png

Is there things that need to be fixed here, or is it good enough? 

Wow, I like it very much. Nice touch using SNG color or the barrels. 

looks great mate. 

-@ Preach: I use the qmle version 3.0 from Rene Visser.
I found that I could raise the standard skinfile from height:320 x width: 480 to a measure of height:380 x width:570.
When I go higher to 460 par example I get the warning maximum skinsize 480 exceeded.
When I try to use your version I can't find an excecutable.
Maybe it is my systym, winxp dunnoh. I use Fitzquake085. 

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 :)