So as a wrap up today,we’ll be looking at the mdl format, what it can and can’t do, and how to get the most out of it. We’ll start by looking at the level of precision of the quake mdl format, by performing an experiment. Make a copy of wizard.mdl from the id1/progs directory.
Pick some vertices at random in frame hover1 and move them in each direction several hundred units, so that the model looks something like this screenshot. The objective is to make the model extend much further in all directions than the model currently does. Then save it under a different file name and close QMe.
Now, reopen the model you just saved, and take a look at the fly animation. Even though you didn’t edit it in any way, you’ll see that it looks much cruder than it used to, with the vertices making bigger jumps or not moving at all, and a lot of the shape has been lost.
The reason for this is that quake stores the positions of the vertices as three bytes, one for x, y and z. A byte is a single integer between 0 and 255. So you can imagine a 256x256x256 grid which all the vertices are snapped to. The grid doesn’t have to be a cube though, the scaling can differ in each direction. So if you have a very tall but thin model, the x and y coordinates will allow fine detail, but the z won’t accomodate so much. The grid is the same size in all of the frames though, so it has to be stretched to the largest extent of the model in each direction. By moving the vertices of the wizard about, we made the grid much larger, so snapping the vertices to this grid in other frames causes the degraded animations we saw.
The fact that the grid is scaled according to the size of the model allows us to scale a model we exported without impacting the quality, as long as we scale over all frames. Then it’s equivalent to just changing the scale factor of the grid. If we only changed some frames, then the smaller frames would lose quality. We can also move the model about in all frames without changing the accuracy of the model, as the grid also has an offset vector. Rotating by 90 or 180 degrees is also safe, since the grid can also be “rotated” by 90 or 180 degrees. Any other rotations will cause problems though.
So, what practical things should be done to deal with the grid? Well, the first is to make sure your models are roughly the same size in all frames where possible. An abnormally large frame will affect all the other frames, and any small frames will probably look bad since they’d be better suited to a smaller grid. If your model remains the same size but moves about the frame a lot you’ll have the same problems, so try to move things in QC where possible. This is especially true of rotations, the grid isn’t really accurate enough to handle them well. If you had something rigid like a gun turret, having it rotate in QC will keep it rigid, where rotating it in the model will probably cause jello wobbling. Organic models are more forgiving in this respect, which is fortunate as they usually can’t be animated in QC that well…
Another important thing is not to work from the quake mdl when you can avoid it. If you save in quake format, then open it, make some changes that affect the size of the grid and save it, the vertices will be snapped to the grid for a second time. Let this build up, and your models will accumulate noise. Of course, if you’re doing the safe transforms like scaling in all frames, the vertices will snap to the same coordinates on the grid they were in before, so you haven’t changed the accuracy. The best thing to do is to make sure that the final version of your model is exported straight from gmax, converted to mdl, scaled and translated in ALL frames and then left alone, at least as far as animations are concerned.
Knowing how the grid works can be used to your advantage. Suppose you wanted to make a model that integrates seemlessly with the geometry of a level you were making. What you’d need is for the grid for the model to be the same grid that brushes are snapped to, ie one quake unit apart. So, what you do is put an isolated vertex at -128 -128 -128, and another at 128 128 128. As long as your model lies in between these two vertices, the grid will be one grid unit to one quake unit.
Margin note 11
Ah, a classic fencepost error. Because the grid has 256 points, you actually need to do something like ‘-127 -127 -127’ to ‘128 128 128’ to get points to always fall on integers. If you wanted something to be 256 units in size AND have integer points elsewhere, you need to double the grid size to something like ‘-254 -254 -254’ to ‘256 256 256’, giving you an excess of space instead of falling one unit short…
If you were doing some machinima in quake, one thing you might want to try is seperate the head from the rest of the body of your actors. The head would be basically compact, and quite a bit smaller than the rest of the body, so as a seperate model it would have a grid with a fine level of detail. You could probably get some facial expressions or even crude talking in, and the fact you could have a high polycount dedicated to just the face would help. Which brings us to:
How many polys?
A rundown of the numerical limits of the quake model format.
Polygons: 1024(but 2048 really)
If you want your model to load in any official quake engine, you are limited to 1024 polygons. The original dosquake and winquake exes had a limit of 2048 polygons, at the time a seeming huge amount to deyote to a single model. When GLquake came on the scene, none of the graphics cards supporting opengl were up to much, and so the engine restricted models to 1024 polygons, which broke a few mods at the time and is kinda annoying now. I’m pretty sure that the released source code for glquake restored the limit to 2048 limit, and some custom builds set it even higher. So should you make models with more than 1024 polygons? Well, you can probably get away with it, but be prepared to field troubleshooting e-mails over it. See also the comments on vertices.
You can get 256 frames in a model. This is probably enough for anything you should want to do with it. I suspect that it would require a network protocol change to change this, as currently frame updates can be sent as a single byte. If you somehow exceed this, you may have to think about your design. If you’re doing a monster, see if you can’t split it into two models with the same mesh, but different animation in each. It’ll require a lot of care in the QC to make sure the right model is being used in each frame, without actually resetting/checking the model every frame. Putting only uninterruptible animations like pain/death in one of the models will help this.
This is more important than it seems. In normal models, the number of vertices is a bit less than the number of triangles, so unless you’re pushing 1600 or so triangles you won’t hit the vertex limit. The problem is that this isn’t true of models made in this way from MD3s. So this can also be a limiting factor. So, what part of the process makes all these extra vertices?
Well, it’s the skinmapping, and we’re gonna investigate why.
Open the mdl of the crusader we made preyiously, go to the Utilities menu, and select Run Skinmap Wizard. Select “Reconstruct base frame from skin map”, click Next, and then click Finish. A new frame should appear, and look something like this. Compare the shape of the front row of triangles to the left hand side of the skinmap.
What you should notice is that the model has unfolded into the shape of the skin. Looking at the model though you wouldn’t think that would be possible, it looks like the helmet was one continuous piece, but here it’s unfolded into 3? Take a look at this screenshot and you’ll see that even in it’s normal pose, the pieces of the helmet can be seperated.
In fact when I tried it could be seperated more than I expected, all the triangles have become seperated, and this has pushed the vertex count about 1024. You can use control-m to merge them back up, but be careful not to merge anything that shouldn’t be joined on the skin. The skin frame you just made is a good place to start, but beware of welding vertices on sections of skin that are mirrored, you might weld the two sides together in places they shouldn’t join. If you were only just aboye the limit and there was a really obvious way to fix the model you might whant to fix it by hand like this. Here, do ten or so, then realise it’s tedious and I’ll reveal what to do to repair this.
This step has been a voyage of discovery for me too, I honestly didn’t know how to fix it when I started writing. Since then I went back and fixed the original model so that you won’t have this problem during the tutorial, but here’s what the fix was in case you encounter it in your own models. The problem is that the model has many smoothing groups, and this is causing confusion. Since the smoothing groups don’t affect the quake model to my knowledge, we can safely reset them. Open up the gmax version of the crusader, and 1: click the editable mesh modifier below the skin modifier. The warning that pops up should be heeded sometimes, but what we’re about to do doesn’t change the topology, so press ok. Now, 2: go to face selection mode and select all the faces. Then 3: clear all the smoothing groups before 4:assigning everything to smoothing group 1. Now you’ll have to export and reposition the model, all that hassle again.
Margin note 10
Smoothing groups in fact DO affect Quake models, they have support for vertex normals and the conversion from MD3 to MDL preserves the smoothing settings from GMAX. This tutorial was what got me to investigate them in the first place. The idea that you can reduce vertex count by smoothing your model is still correct.
This screenshot shows the result of the fix, the connected parts of the model now have the same topology as the pieces of the skin. This is as good as it gets though, and while there are still less vertices than polygons, it’s not by a great deal. You’ll probably find that the number of polygons in your model is more restricted by number of vertices than the format’s limit of 2048 triangles. One thing that does affect it is the number of pieces your skinmap is in. The more pieces you make, the more vertices you’ll create. Of course, it’s often a case of getting a much better skin if you use more pieces. So you’ll have to trade off these competing factors, and reach a compromise between high poly, good skin and still running in all engines. Phew!
That just wraps up my two cents, but more needs to be said about QuArK before I finish. Getting md3s to convert in QuArK is quite hard, and I hope that I’ve made the tutorials strict enough that if you follow them to the letter it can’t really go wrong. When you branch off and start making your own models though, you’ll need to know why what we do in the tutorials works, and what can go wrong.
Margin note 12
I’ve said it often, but the following ought to convince you that md3tomdl is a much safer option than struggling with the errors below.
The three things that can go wrong are Quark can refuse to open the MD3, even if other programs will open them, that the model opens but not it’s skin, and the model loads but you get an error when you try to export to mdl.
Quark refuses to open the MD3:
“QuArk needs the file ‘scripts,-‘c:.shader’ from Quake 3 and cannot find it”
Assuming you did install this script correctly as per the first tutorial, this most likely means that you don’t have smart paths checked when you export. Without smart paths QuArK has some trouble, and the only way round it I know is to go back, and export with smart paths.
“QuArk needs the file ‘scripts/c:.shader’ from Quake 2 and cannot find it”
Or substitute any other game for Quake 2. This means you aren’t in the correct game mode. In the main quark window open the games menu, and select Quake 3. Then try again.
Quark opens it, but not its skin
This should usually come with an explanatory error message that it hasn’t found the bmp or jpg. If you are sure that the files are in the right place still, try using tga format, this usually clears up the problems. You could in theory just export even without the skin, but then you’ll have a 50×50 skin, and trying to resize that is going to distort the skinmap loads.
Quark fails to convert it to mdl
“quarkx.error: This operation is not supported with 24-bit images; it requires a
256-color palettized image.. [00553A30]”
This one’s actually quite intuitive, your skin has to be an 8 bit image in the quake palette. The format I find works best is tga, as gmax will read it fine, and it supports 8 bit. Note that the skin you use at this stage doesn’t have to be your final skin, so in a pinch just apply check.tga from these tutorials until it’s in mdl format.
Ok, I guess that’s it, hopefully we’ll see a great new crop of models for Q1 out of this. Remember to e-mail me if you’ve got any questions about the tutorials or making quake models in general.