monster <70 %

Some more blood around the chest and a little on the back, face and arms, some dripping down upper legs

monster <30 %

Big hole in chest, large exit wounds on back (i.e. gored up) more drippind down arms and legs

monster dead

Some blood particles flowing from the monsters midrift and maybe neck/face

monster -howevermuch it might be %

Gibbed!

It makes sense, you know it does. In a game so abstract that you can gib monsters in the style you can already, it would only add pleasure to my experience :D 

You could go whole hog and have a Mancubi style death - for example the Shambler's stomach could rupture when he dies, but then it probably wouldn't look very good with a single frame change and no 3d animation.

for the zdoom md2 models, they did seperate models for the monster deaths. the 3d mancubus death looks pretty good, as does the cacodemon.

i think if someone wanted to take the time, they could revamp the old death animations in that same sort of style for quake with new models. 

There's a mdl version of the health box (and indeed all the ammo pickups at the same time) included in quoth, which would be suitable for your testing. You'll have to extract it from pak1.pak, and it's called pickup.mdl. 

Sweet, will do! Thanks for the heads up, Preach. 

Oh, and it just occurred to me ... so THAT'S how you supported rotated pickups then. Neat! 

You can rotate pickups in their regular quake form. The only problem is that the bounding box doesn't change when you do that, which is compounded by the fact that the ammo boxes rotate about one of their corners, and not their centre. If you rotate them 180 degrees, the model entirely escapes the bounding box!

The quoth fix is just to put the bounding box in the right place relative to where the model get rotated to. The advantage of using the .mdl version of the ammo is that it saves you up to 10 model precaches, which can be helpful if you're pushing the limit(Stark Monstrosity showcases this feature).

The side effect of the .mdl version is that the crate is lit according to the ground below, rather than the baked in light levels of the regular ones. In order to stop crates getting lost in the dark, we a: disabled it by default and b: added small fullbright markings to all of the ammo. The shells and nails had these already, so it was natural to extend the idea to the other ammo. 

you can cut those out too.

I did however use the combined ammo .mdl flag at the same time as the one preach described. I like the fact that you add the two flags together, seems like a smart system. 

If it's a smart system, it was invented by a smarter person than myself. It is in fact the same system that spawnflags use - the spawnflag for "not in easy" is 256, "not in medium" is 512, and so "not in easy or medium" is the sum of the two.

In both cases, the values you have to set are chosen to by successive powers of 2( 1, 2 , 4, 8, 16, 32...)
These numbers are chosen because the sum of the first n-1 numbers is always 1 less than the nth number. That way, the sum of any subset of them is unique, and any number you chose corresponds to some combination of them.

There's also a connection with how binary numbers are stored as integers. So if you know about that, you can think of the nth 0 or 1 digit in the binary representation being on or off according to whether the nth option has been selected. 

Did seeting them fullbright look bad? 

OK, so I'm trying to get MDLEd fully functional and I have questions about QuakeC and MDL files...

Do you have to have a "$frame blah1 blah2 etc" for every animation frame in the MDL?

Do they have to match the internal structure of the MDL (do the frames have to be stored in the same order as the $frame lines in your QC file)?

What I'm getting at is this ... will I have to allow the user to have full control over the ordering of the frames in the MDL file or can I safely/automatically sort them alphabetically? Does it make a difference? 

the $frame walk1 walk2 at the beginning just macros those strings to a number, and that number starts at 0 on the first $frame declaration and increments by 1.

so walk1 actually means frame 0, so frame 0 needs to be your walk1 frame.

in other words, the order of those $frame declarations are important and so can't be re-ordered without re-ordering the frames too. 

ijed: as far as I know, there is no standard way to make a .mdl fullbright. It's just one of the differences in the way the two types of model get rendered, bsp have their own lighting info, and mdl use the map's light levels. I do think that medpacks looks pretty cool in .mdl format when placed in dark corners, it makes the lights blinking away on them really stand out.

Willem: You must at least make sure that you don't alter the order in which the frames occur without giving the user control over it. The actual names given to the frames in the .mdl aren't used by the engine/qc. It relies entirely on the enumeration of them in the order that they occur.

The $frame macros are simply a way of defining recognisable constant names for the numbers 0....n in a quick manner which only lasts for one qc file. The qc compiler has no knowledge of what the actual model file contains, so it just substitutes a frame number for each instance of $stand4 with a 3 - assuming that $stand4 is the 4th $frame that it encounters in the header.

So if your program loaded in ogre.mdl, reordered the frames into alphabetical order and then saved them again, the animations would no longer match up, so that would be bad. As long as you ensured that frames were exported in the same order they were imported, you would probably get away with it. But I suspect it would still be a desired feature...

(As a possible side note, people making qc files don't have to define the $frame things for every frame, they can just use the numerical indexes, or a mixture of the two. But just using the numbers can mean a lot of code has to be changed if you extend your first animation loop from 6 to 8 frames, so it's not encouraged to do that for anything with multiple sequences) 

"You must at least make sure that you don't alter the order in which the frames occur without giving the user control over it. The actual names given to the frames in the .mdl aren't used by the engine/qc. It relies entirely on the enumeration of them in the order that they occur. "

Beautiful. OK, that settles that then! Thanks. 

Hey coding thread.

Very sorry about this, never post in here since I'm not a coder, so tend to skim read and leave you guys to your scary quote text fun ;p

Just wanted to bump stuff above the flame thread again (I suggest anyone else reading this does same and avoids bumping again pls ;)

Kiss 

Man, this file format is fairly jacked up.

Anyway... Quick question:

Is the "onseam" stuff entirely necessary for texture coordinates or is that some sort of concession that was made to allow for easy skin creation back in the day? If I store all texture coordinates as full 0-1 values and set onseam to zero for them all, will Quake throw a fit? 

When making new skins, it's no longer really necessary. If you're trying to do anything more complicated that 2-sided planar then you pretty much have to ignore it, and just eat the extra vertices on the model. The md3tomdl converter does exactly this.

However, it's very important that you keep them for existing models, as it tells you which vertices need to be duplicated on the skin. I think if your program didn't preserve the original quake models like that, people would get confused to say the least.

If you changed models to duplicate vertices which were onseam, and then removed the onseam flag, there could problems in other editors. For example, if you saved one like that, then loaded it and saved it with QMe, then the vertex normals along the seams would be altered compared to the original, which might make the seam more obvious. 

Wow, so the whole purpose behind it was to save a vert or three in the mdl file? 

Bear in mind we're talking the first full 3D fps here.

What we now view as insane levels of optimisation was fairly necessary back then... 

I question some of the stuff, actually. Carmack did some crazy machinations in places to save very minimal amounts of space. 

We need to think about skin animations. Blinking lights on enforcers are neat, and I have a couple other cases where this could be useful.

Apart from that. Do the additional mouth/face textures often seen on id skins have something to do with this?

Were they meant for animation purposes? 

I think those are for the head gibs. 

Would be a perfect addition for death skins (if they get implemented somewhere) 

I'd guess the whole onseam system was created because at the time it seemed like an unintuitive system to have vertices occupying the same position in the model, but connected to different triangles - when they are supposed to be part of the same surface in the model. The onseam method was a fix to the problem "how do I display the same vertex in two places on the skin?". It's just unfortunate that the solution pretty much ties you to the front/back skins that quake used.

Although I usually advocate the detached vertex solution, detaching things like that can cause problems. For example when calculating the vertex normals at that vertex, you probably want to average all the surfaces meeting at the split vertices, and give that same vector to all the vertices. This is a lot harder to do once you've split the vertices. In fact, if an unrelated vertex just happens to collide then you're scuppered...

Thankfully, .mdl uses precomputed vertex normals, so as long as you're converting from a format that supports merged vertices with split UVs then you can probably get sensible smoothing groups. Also, worrying about smoothing groups isn't the most pressing concern with quake models.

Interestingly enough, I don't know that onseam actually saves memory over all, when you consider how much wasted texture space there is as a result of using it. On models with lots of frames it's probably beneficial as the extra vertices would be recorded on all those frames. But for weapon models and other simple models, onseam probably doesn't make up for the waste. 

I think headgibs use their own models, which use their own skins. 

How difficult would it be to copypaste the faces from the head gib skins onto body skins? (I'm no modeller so I can't tell)