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. 

Realized I missed to play an extra frame in the programming for the barrel to rotate smoothly during the shooting loop. Also fixed the non-fullbright pixels on the muzzleflash texture.

Quakespasm webm: http://webm.host/b2613/vid.webm
Darkplaces webm: http://webm.host/08742/vid.webm

Also, I have started working on the Nail Infantry, which is basically a recreation of Doom 2's Chaingunner. Taking the Enforcer as a base, I have 2 designs in hand, but I don't know which one to choose:
http://image.noelshack.com/fichiers/2015/42/1445001145-nailinfantryconcepts.png

Obviously the messy textures are temporary. I'm just looking for the right shape. 

I'd say the bottom one, since it will give him a slightly more recognisable silhouette. 

What does it look like when played against a Quake enemy? First impression is really good but just wondering if the muzzle flash might be a little too big?

Nevertheless, I like it. 

It does take up a lot of the screen, yeah. Resist the urge to put all your work front and center - AAA shooters that lavish detail on their guns and then make them cover a quarter of the screen are sort of irritating. When the gun is firing, the muzzleflash comes all the way up to the crosshair.

Still gives me Wolf3D flashbacks, too. :)

How did you solve the problem of vertex interp on the rotation? If I stop firing on the right frame does the gun collapse on itself? 

at least in fitzquake, any frame with a muzzleflash is not lerped into or out of. 

Depends on which firing frame is the last one before switching to the spinning down animation. The farther it is to the first spinning down frame's barrel rotating angle, the squichier the interpolation frame gets.
But because the firing frames have a self.nextthink of 0.05 instead of the traditional 0.1, the "collaspe" is barely noticeable when it happens.

As for the muzzleflash's size, I'll wait until level playtesting to see if the size needs to be changed.

Also, I modelled the muzzleflashes (there's actually 2 of them, I have to rotate the barrel 45� at each frame [360/45=8, it takes 2 frames for a proper minigun-like muzzleflash to animate, when one finishes its 2-frame animation, it goes back at the tip of the barrel, gets minuscule and let the second muzzleflash do its animation, and so forth], going further would make the barrel look like it's going so fast it would collapse by itself, like you said) so that it's extremely minuscule just at the tip of the barrel's interior, and it follows the barrel in every frames until the firing state, where it gets out just a few little units forward. 

I made a convoybelt with an injector.
It moves on 40 frames, so one cycle takes 4 seconds.
I also made a sprite that lights the injector.
It lights with 14 frames on self.nextthink = time + 0.01;
To make them work synchronical I need a wait time of self.nextthink = time + 2.7;

This works well for 42 minutes, then the sprite starts to act slow, after 65 minutes it's out of order, meaning it misses the synchronity and falls out of the movement.
I tried time + 2.69 and time + 2.71 but that doesn't seem to help.

Do time accounts excist in that timescale?
Of course I can say, finish the map in 42 minutes, but that's a hatch of the hat. 

as always, it depends on the engine.
sv_gameplayfix_multiplethinks 1
(this is always enabled in quakeworld servers and thus default-enabled in fte, and default-disabled in dp, I don't know of any other nq engine that implements an equivelent)

NQ servers normally only run one think per frame. if the entity thinks faster than a game tick then it can easily miss a think. the time global will be larger than the nextthink value used to be.

additionally, floats have limited precision, centered around 1. that is to say that as the float becomes larger, it can no longer hold smaller numbers quite so precisely.
this means the server's framerate might slow down as its own timing degrades. this is especially true of 'listen' servers.
it shouldn't really be a problem for 100fps at 42 mins though. 1000fps might start to have some issues though.
bigger intervals will be more reliable with larger time values.