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) 

I want blinking lights for the enforcers, that was a good suggestion, whoever made it.

It looks from the models that the head gib was originally going to come from inside the main model, but it didn't work out.

Simple as export c+p import to put the pain head onto the normal guy for a dead skin. 

I was replying to Willem about the additional face parts etc. on id1 skins. Those are pretty weird. 

It seems the extra faces are there because the head and model were originally going to be combined, until they realised that hiding the entire body inside a copied head would be more wasteful. 

how awesome it would look if they did hide the body inside the head gib, now that we have engines that do model interpolation? 

Back in the day before I worked on mods that people would play, I made a quake mod where you fought vampires - aping Buffy and that kind of thing. One of the driving things behind it was to make the death sequences look cool (by quake standards), so when you staked a vampire through the heart they'd look agonised for a beat, then explode into a puff of dust.

Coming back towards relevance, when you killed them with fire the flames burnt upwards from their feet while their arms flailed. In order to make their legs disappear, the polygons were just folded up into the upper legs, then the torso, with the flame graphic concealing the interpolation which arose. I imagine the final effect is not too dissimilar to what metl's thinking of.

(ps: the head gibs are probably separate for the more mundane reason of giving them a blood trail, which is a per model effect...) 

is it possible?
i'd appreciate any help 

Sure, there were some mods with railguns I think. 

And I just remembered I once successfully completed this tutorial: http://www.inside3d.com/showtutorial.php?id=167 

Spy Parboil once change the qwprogs.dat to railmod i think... since u are russian is easy to ask in is forum :)

http://parboil.quakeworld.ru 

zomggg are you the spy from the old Parboil board?

hehe