News | Forum | People | FAQ | Links | Search | Register | Log in
Modeling For Quake (help)
hey, iv been having issues getting custom models into quake, if anyone can help me or knows any good tutorials for me to use it would be much appreciated, thanks! (this seems to be a mapping site, but i was directed here for this issue by someone else)
I'm in the same boat, I also just made my first Quake models. I found it helped that I had mapping experience, because in both cases, you build wireframe meshes of some sort and apply skin/textures to them.

I use QME, which can be downloaded from among other places; it comes with a pretty good manual which is an enlightening read.

For skins I use Wally and Paint Shop Pro 4.12, which is an older shareware program (whose trial phase never expires...)

I found it helpful to set the grid size in qme to 2 or 4 units, instead of 0.1. Just read the whole qme manual.

There is also a tutorial by Preach from Quake Expo 06, which is here:

Also use google to look around for tutorials etc. 
On The Subject Of That Tutorial 
I've been working on a little project to force me to learn some C++. The program takes an md3 file and a pcx skin, and outputs a mdl file. This would be a good way of skipping the bit of the tutorial which involves messing around with quark. Right now the program works, but it's pretty inflexible. For example, it combines the skins from all the components of the md3 by overlaying them onto the same skin.

It also runs on the command line, so you have to type things in each time you want to convert something. I'd like to give it a proper windows GUI interface, but that's a whole lot of extra learning I haven't got my head round yet. If anyone thinks they'd find it useful it it's current state, give a yell. 
I Have A Maya 8.5 -> Quake Path 
It's a python script run from within Maya that writes out an extended form of .qc that contains actual mesh definitions, coupled with a modified modelgen.exe that reads that mesh data (and .bmp files instead of .lbm). It works perfectly and I have one or two new monsters working in-game already, and they turned out pretty nicely. Doing all the modelling and animating in Maya makes everything so much easier I changed my plans on new monsters in Lunsp2 from "one" to "a bunch" just because the turnaround is so quick.

It is of course not perfect, still in a guts-hanging-out garage-inventor kind of a state, and the documentation exists entirely in my head, and I was going to post it once I'd polished up the rough edges and made it safe for public consumption, but if you have/wanted to use/are willing to try Maya I suppose I could upload something tonight when I get home. Plus, if you're familiar with scripting in your 3d package of choice you could always use just the changed modelgen.exe and write the extended .qc files yourself from Max or Blender or whatever heathen satanist 3d package you use. 
Maya -> Quake 
Bloody hell, that would probably get me back into quake modding actually.

unfortunately i'm in the middle of a crunch at work right now, and will be for some time :(

Bollocks >:{ 
I use Max, never got around to figuring out Maya joints.

I'm mostly just hacking up the Q1 monsters ATM, but the heavier stuff will be starting soon. 
Maya > Quake sounds good!

I have no interest in modelling or animating characters, but it'd be nice to be able to make/export basic props from Maya and use them in Quake (I'm assuming it's easy to add custom models using Quoth). 
Custom Models In Quoth 
Yeah, we added that in the latest version, use a "classname" of "mapobject_custom" and model field set to the desired path and model. Spawnflag 1 makes it a static entity, and if you set mangle then that will be used in place of angles - to make odd rotations easier. 
Custom Models 
i'm playing around with making props for a map i'm working on but having to skin them the 'quake' way instead of doing it all in 3ds is incredibly annoying. :( 
I'm Getting Used To It 
you can kind of plan around it. I've modelled all my characters thus far with the modelgen projection in mind and gotten pretty good results, without any unsealed edges either. The main thing to remember is, don't have any faces that are parallel to the front - make your legs and heads diamonds or hexes in cross section so that when you do the roadkill you can pull those verts out a bit and pancake the guy to get more even pixel density on those faces that slope away from the z axis.

It helps that next to the existing monsters anything looks good. :) 
it's not that it's hard to do, but that you can efficiently unwrap a model. and that in turn means you can get as much resolution out of the skin as you could. 
Pretty Easy 
to unwrap the UV's the Quake way with Blender. Line the camera evenly with the front face choose an unwrap mode called project from view for the front selection. Invert selection you have the back face, then you can spread it out as you see fit. Blender pretty much emulates Maya methods so that might translate over, or might not. 
The converter I've got for MD3 to MDL preserves the existing UV map on the MD3. It turns out that MD3 models do just duplicate the vertices in the same way that it's necessary to do for quake 1 models. So you can map the skin in as efficient a way as you desire. 
the md3 vertex limit is higher than quake's mdl vertex limit, right?

Is there a quake vertex limit? 
Hey Luddits 
Do you walk up to people who are drawing in sketchbooks, or carving something out of a block of wood, and say that to them too?

Sometimes the pleasure in doing something the hard way is in the doing. 
I walked up to ppl who had said "I wish I could use the technology" and pointed them into the direction... 
i don't really use model props in quake much. if i want to do a map that would require detail models like that, then i do it for doom3. :P 
Alright Cool, Thanks Speeds 
Now how can I do it in a good engine? 
Yeah, the md3 limits are 2 to 4 times higher than the quake ones on both triangles and vertices. The thing is though, unless you're making a really weird model with loads of breaks, then the number of vertices is always going to be lower than the number of triangles, but both have the same limit. So you don't usually run into problems, and if you do, the solution is just grouping more things on the skin, which is basically what taking a planar map is heading towards. 
Model Limits 
what *are* the limits for quake .mdls? 
Ok, I made a slight mistake there. The standard limits, found in winquake and the released source are 2048 triangles, but only 1024 vertices. The compiled version of GLquake from iD actually has the triangle limit halved to 1024, but you can pretty much ignore that as just recompiling the GPL source gives you GLquake with this limit restored. There's no reason anyone should have trouble with that limit.

It's also interesting to note that unlike the max number of frames, which is 256 for networking reasons, you can increase these limits a long way without doing anything besides changing the headers.

In general I'd still say you're gonna hit the tri limit at about the same time as the vertex limit on most models. Once you've counted the vertices on the perimeter of a segment, a mesh of quads increases by 1 vertex for 2 triangles added(roughly speaking). So if you're unwrapping lots of small pieces the vertices are the rub, but for larger pieces the triangles will be more trouble. 
i had no idea the tris limit was so low o.o but thanks for the info! 
Unless The Model Is Huge 
you shouldn't be using near that many anyway, because
a) it'll look totally out of place amongst the boxier stock models (and if you don't care about that, you should)
b) integerization will tend to destroy any fine geometry anyway. Remember the faces in Nehahra? Woof. 
Model Property 
my bones model took 1082 triangles/ 382 vertices.
And the mdl was large, 1150kb.

the granito model was 574 triangles/169 vertices and was 622kb. It is a huge monster I intended as end boss. The only problem I have it stops its attack in pain frames so one can easily kill it by constant shooting. 
Monsters' attacks are interruptable by default - you can cut off a hell knight's fire attack in mid-sweep for example. You just need to change your boss's pain function to cause pain every time (or nearly every time) and it should work, although that's if your .qc works like the original .qc, and I can't be sure that it does. 
And In Reverse 
Madfox, open up shambler.qc. The first thing you should look for is a series of functions; sham_pain1 to sham_pain6. These should look something like the pain functions of your boss monster, and I'll call them the "pain animation" functions. Now if you look at the spawn function for a shambler, right at the bottom of the file, notice the line:

self.th_pain = sham_pain;

What you should notice is that this is not the same function as sham_pain1. sham_pain is an additional function, which I'll call the "pain controller" function. It decides whether or not to bother sending the monster into pain. If you change that line to read sham_pain1(the first "pain ainmation" function), then every time the shambler takes ANY damage, it will run the pain animation, which I think is your problem with the boss. You might want to try this with a shambler, just to see it go wrong.

So now we need to see what the "pain controller" function sham_pain does differently.

void(entity attacker, float damage) sham_pain =
sound (self, CHAN_VOICE, "shambler/shurt2.wav", 1, ATTN_NORM);

if ( <= 0)

if (random()*400 > damage)

if (self.pain_finished > time)

self.pain_finished = time + 2;
sham_pain1 ();

The english language version of this code is:
Play the pain sound.
If I'm dead, return.
Make a random number between 0 and 400, and if the damage taken is less than that, return.
If the current time is less than my pain_finished time, return.
Otherwise, set my pain_finished time to 2 seconds into the future, and play the animation starting with sham_pain1.

I'd say the two most important things the "pain controller" function does are:
1) Create a random chance for the pain animation to play or not (although many smaller monsters don't have this in their pain controllers)
2) Keeps track of the pain_finished variable - not playing the "pain animation" if this variable is greater than time, but also updating it to some time in the future every time a pain animation IS played. This is basically setting a minimum time between pain animations, and that minimum time should be long enough for an attack to occur.

So basically what you want to do is copy this "pain controller" function, rename it, and replace the call to sham_pain1 with granito_pain1, the first of your "pain animation" functions. Then make sure that th_pain is set to the name of the "pain controller" in the monster spawn function. Once it works you can tweak the values further. Hope that helps. 
Bootleg Liquor 
sham_pain and wiiiine

I will justify this post (and turn the thread away from qc back to modelling) by saying I'm putting together my Maya export stuff for you all right now. 
Here You Go, Buttasses 
Version 0.01 of lunmodelgen.exe and .py:

[ ]
[ ]

The .txt should explain everything, but only if you read everything in it. I also included an unfinished example monster! 
Great Thread 
If You Are Modeling 3dsmax 
i found a useful utility that will deform a mesh into the shape of your UVs. you can use relax and pelt mapping now for quake models. :)

when you use it on a mesh, it creates a new mesh with a morpher modifier on it so you can go between the unfolded mesh and the original. now you can just export the skin from with the unfolded mesh, then use the morpher to bring everything back together, slap a skin modifier on top and start animating! (if you use the original mesh and then try to combine it with the unfolded mesh, the vertex numbers will be screwed up) 
So I can finally have the skins painted properly without all the annoying black space outside. 
OK, stupid question (well, stupid person...);

How is the skin information in Quake different to normal texture/skin information in 3d apps?

I'm curious as to whether I can use the funky new 3d painting shiznat in PS CS3 Extended to skin quake monsters (or at least, a combination of PS and maya/lun's script) 
UVs In Mdls 
There are two types of UV vertices in a quake model, onseam and offseam. The offseam vertices are the ones not on the perimeter of any shape on the skin. These are exactly like UV coordinates in any other app: each such vertex on the skin is paired with one on the model, and every triangle which meets that vertex will have the corresponding triangle meet it on the skin.

The difficulty arises once you get to a vertex on the edge of a piece on the skin. You don't want all of the triangles which meet at that vertex on the model to join onto it at that UV point on the skin, because you would like to unfold them as separate pieces.

The quake mdl format allows such vertices to be designated "onseam". Then two copies of this vertex will be made on the UV map (but not the model) - one on the left hand side of the skin, and another half the skinwidth to the right of it. To determine which triangles connect to which copy of the vertex, each triangle in the model has a flag "facesfront" which is set by the model compiler. If the triangle faces front it is connected to the left hand vertex, otherwise it connects to the right. As you might guess, the original quake model compiler calculates this based on whether the face is front or back facing, which is why you get the front/back pairing on the original skins.

The alternative, which I support despite always listing it's negative effects, is to make none of the vertices "onseam", but instead make actual duplicates of those vertices in the model which are on the edge of a skin segment, so that they can be moved where you like on the skin. This allows for much better packing of the skin, since you can do things like mirroring halves, devoting more space to things which face front, all the tricks basically. 
Preach, that gave me more perceptive!
Point is I gave the granito.qc three pain sessions so
the = granito_pain_decide
I can change it but how do I calculate the other three pain session?

a closer watch: 
It looks like most of what you need is there. First thing I would try is change all those pain finished things to equal time + 5, if it's meant to be a really powerful monster.

There's a small bug which means the first pain animation won't ever be called, you should change

if (r < 0.66)


else if (r < 0.66)

otherwise when r < 0.33 it's also < 0.66 so the second pain sequence overrides the first one.

To make the pain animations less likely to happen, you could change to something like

if(r < 0.05)
{ first sequence...}
else if(r < 0.1)
{ second sequence...}
else if(r < 0.15)
{third sequence ...}

That way if r > 0.15 none of them happen. You could even finish that with:

self.pain_finished = time + 0.5;

so that if it doesn't go into pain that time, don't even bother to check for the next half a second, which would defend it against pain from nails/lightning a bit more.

You may find putting all these things in might go too far the other way, I'm just throwing them at you so you have the options. 
That goes great!

First I copied the shambler's part of the sham_pain, but then I lost the other two pain sessions in the statement.

But indeed it has more power now. It can't be shot so easily and that's what bothered me in the first place for an end boss.

Hey, thanks for that splendid cham_pain explanation! 
wouldn't gl engines copy the vertex anyways for rendering? 
Yeah, but that copy wouldn't count towards the limit of 1024, only the ones that are loaded from the mdl structure count for that. 
Was just browsing Polycount and someone made a script like the one necros posted for Maya:
Thought it might interest someone maybe. 
do I create the last death frame of a monster,
so its death scene leaves in another skin index? 
just add = # in the last frame function.

but seriously, madfox. post this stuff in the programming thread. :\ 
thanks for advice.
nice thread. 
if anyone's interested in modeling and uses milkshape i have a tutorial i wrote that might help you out.

it's here: 
Interpolated Vertex Animation And Mesh Volume 
model & animation: A rotating disc (like a gear, for example) comprised of 20 frames for 1 full rotation (frame 1 being 0 degrees, frame 10 being 180 degrees, etc). When the animation loop is interrupted, the gear will idle at frame 1.

scenario: the animation loop is interrupted at say, frame 12.

problem: the engine's interpolation adds frames in a straight line between each of the vert's positions, causing the disc to collapse briefly as it transitions from frame 12 to frame 1.

I need some way to constrain the mesh volume so it will appear to rotate naturally between frames. Is this possible with a skeletal format such as IQM? 
Is there a QC command (in supported engines) to suppress interpolation for one frame, or am I imagining it? 
Nolerp Per Frame 
there's this:

//idea: id software
//darkplaces implementation: divVerent
//effects bit:
float EF_TELEPORT_BIT = 2097152;
//when toggled, interpolation of the entity is skipped for one frame. Useful for teleporting.
//to toggle this bit in QC, you can do:
// self.effects += (EF_TELEPORT_BIT - 2 * (self.effects & EF_TELEPORT_BIT));

Which I haven't tried yet because because the disc in question is just a small part of a larger mesh and I don't want to nolerp the entire entity.

I could split the disc off as a separate entity but that's something I'm trying to avoid... 
QC Manged Looping 
You might need to animate it yourself using qc (like for enemies) to let you stop at any frame? 
It Is Animated That Way 
the loop is dependent on player input which can change at any time. Unfortunately forcing a full loop before stopping the animation isn't possible here. 
Loops Versus Interpolation 
Maybe not the same, but an answer to my experience in making a convoybelt. The intention was to create a production line with an energy cell with twenty frames. I have noticed that the method that uses darkplaces is different from fitzquake.

I animated one cell/1frame, going to the half part, then hide the cell under the convoybelt, and then sweeping it up after the other half part was gone.
The convoybelt went easy, as it is a straight line.
The claw made an angle , so I had to hide it in three frames before the next row.

When I finally got the animation right, the interpolation was discussed.
After a lot of sliding and fitting I finally got the series running, but then I realized that each engine applies its own way of "turning".

here are the model versions I used. 
What Do You Mean Loops? 
I'm not understanding what you are doing. 
Loop = Frame Sequence 
what I'm doing:

if player is pressing 'x' play frame sequence indefinitely; if player isn't pressing 'x' go to frame 1.

Interpolating any frame other than 20, 19, 18 and 17 to frame 1 results in poop because of the reason stated in post #44. 
Which I haven't tried yet because because the disc in question is just a small part of a larger mesh and I don't want to nolerp the entire entity.

What else in the mesh is moving apart from the disc? I'm trying to visualise how the nolerp for a frame option would look bad... 
It's A Viewmodel 
the mesh is in a very different position during that particular sequence than it is in any other, so that lerp is critical for a smooth transition (especially since it's right in your face). 
So I assume adding a transition animation where the weapon spins down to a rest state when player releases the button is out of the question? 
The Transition From Fire To Spindown 
is where the problem is occurring. to adjust the mesh position of the first few frames of the spin down anim to smooth the transition between the two looks terrible (artistically, needs that sudden jolt), worse than the gear issue itself.

looks like my options are 1) learn/setup/test yet another model format just to figure out how it works and see if it will solve the issue and lose valuable time while doing so, 2) remove the gear (rather not), 3) remove time slowing down (possible, but rather not) 4) make the gear a separate entity and achieve rotation via qc rather than vertex animation (this sounds like another giant can of worms and I think it will look jittery), 5) do something else with my life. 
In qmle is an option for frames setting to interpolation.
Not sure if it has anything to do with qc, but when using a model it sometimes angles back to the start frame, in stead of rolling on. Creating a strange turn of the animation.

I just call it a criple loop, may sound strange. 
Frame Seqwhatnow? 
Are you using framegroups or are you stepping it through frame by frame like on monsters

playergearwep1 [0, playergearwep2] () { self.weaponframe = 0;};
playergearwep2 [1, playergearwep3] () { self.weaponframe = 1;};

Viewmodels are a whole different ball game. Not sure if most engines even support framegroups on viewmodels (FTE does). 
if you want to get fancy, csqc is the way to go.
combine with modelevents too or something, and you can have particle effects etc handled in a generic way.

but yeah, if you want something to spin, do it in csqc. a little spinup+spindown makes it feel more real, and definitely smoother.
skeletal models potentially allow you to control each part of a model independently. 
The Hack Way 
If you want to do something that's supported in all engines, here's a hack to skip the interpolation:

Have two separate model files for your weapon, v_spinning.mdl and v_standing.mdl. Change the weapon model when you want to switch between two poses without interpolating them, just change the frame when you want to have interpolation.

It's not a pretty solution, but it works! 
Thanks For The Ideas 
@qmaster - we use both framegroups and hardcoded frames depending on the situation. The anims in question are using framegroups, I believe.

@spike - I'm leaning toward making the gear a separate entity but won't even have to do that if IQM would allow me to control a particular bone and nolerp that one bone for one frame.

@preach - that's an interesting hack :D 
In Fitzquake-derived engines, EF_MUZZLEFLASH will disable lerping for one frame.

But I think Preach's answer is the best. 
The issue with EF_MUZZLEFLASH, DP_EF_TELEPORT_BIT and Preach's solution (unless I'm missing something) is that I don't want to nolerp the entire model, just a part of it.

Looks like splitting it off into another entity is that way to go about it (lame!) 
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.