I tried to keep the title post nice and short in the hope that this thread is as long lived as the coding one. So here's a slightly longer one with more information (and also more of my opinions you've heard three times before)

The mdl format was one of the first 3D model formats for games, and naturally is a little less advanced than anything seen today. Here's a rundown of the most important mdl limits:

1000 vertices
2048 triangles
256 frames

The other important limitation of the mdl format is that the vertices are stored with a precision of 8 bits per coordinate axis. The vertices are in effect "snapped" to a grid of 256x256x256 points. This means you can't create intricate detail in your model without it being lost when it moves. It is worth noting that the origin and spacing of this grid can be specified, so the level of detail which can be retained is relative to the overall size of the model.

Editing

One of the greatest barriers to making models for Quake 1 is the lack of good tools. The best tool which works with .mdl format natively at the moment is QMe. You can grab the full 3.0 from:
http://www.fpsbanana.com/tools/2544
and you can upgrade it to version 3.1 with the patch in
http://www.xs4all.nl/~renep/quakeme/qme31_p2.zip

Although QMe is useful for this reason, I'd personally recommend working with the mdl as little as possible. It is generally easier(in my opinion) to create your model in another format entirely, preferably one with a powerful editor which saves the vertices at high precision. Then just export the model to mdl each time you want to test it, much like you compile a new copy of the BSP each time you add to a map.

QuArK ( http://quark.planetquake.gamespy.com/ ) also handles .mdl format natively, as well as other more popular formats such as MD3. I've never been able to use it for any serious editing, but found it a useful tool for converting file formats. So it sits somewhere between working directly with the .mdl and just a waystation for converting files.

If you work in Maya, you are fortunate to have the most direct route to export to .mdl. Lunaren has written:http://lunaran.com/files/lunmodelgen.zip
One package which handles everything directly!

If you work in Blender, you can give a script for exporting to mdl directly a go:
http://www.btinternet.com/~chapterhonour/mdl_export.py
I wrote it a while ago, for blender 2.4.4, and I don't intend to ever revisit it. But it's written in python, so it should be straightforward for people to modify themselves. Alternatively, you can export your model to MD3, using either http://tremx.svn.sourceforge.net/viewvc/tremx/trunk/blender/
or http://cube.wikispaces.com/MD3+Export+From+Blender+Tutorial

Once you have an MD3 of your model, you can run it through QuArK to convert it to mdl. Alternatively (blowing my own trumpet here) you can use "MD3 to MDL"
http://www.btinternet.com/~chapterhonour/md3tomdl.zip
This is my new work in progress, and I welcome any feedback on it. It's a simple command line tool, requiring only a short text file and an MD3 to work from. I'm planning on extending the control file format to include things like model flags, multiple skins, named frame ranges and stuff, so suggestions of what could be useful will not go ignored.

Since MD3 is so well supported amongst editors, you can use the above to get to .mdl format from most major 3d modelling packages. If you don't have any of the more expensive programs (like me), then you could do a lot worse than getting a copy of Gmax. It's a stripped down version of 3d studio max intended for making gaming models, and it's free. Official support for the idea ended a few years ago, and http://www.turbosquid.com/gmax took over distribution. Make sure you also download the Tempest Game Pack, to get the md3 export you will need. Personally, I can't do without gmax...


This thread is pretty much a continuation of http://www.celephais.net/board/view_thread.php?id=60262 , a thread I'd forgotten about until I started researching for this post. Hopefully putting all this information at the top of the thread justifies starting a new one.

Finally, if the low polygon requirements of Q1 seem constraining, take a look at:
http://boards.polycount.net/showthread.php?t=41232
The things some of those posters do with 500 polys are just amazing. 

 

Lunaren's mdl export is at http://lunaran.com/files/lunmodelgen.zip
I previewed to check which links worked, and then messed up actually fixing that one.

Also, to get the ball rolling on actual models, here's a pair of screenshots of the ogre I made ages ago based off metlslime's drawing:
http://www.btinternet.com/~chapterhonour/ogrescr1.jpg
http://www.btinternet.com/~chapterhonour/ogrescr2.jpg
Last time I posted it, it didn't have any blood splatters, and that criticism has been answered. One of the reasons the first version lacked them was that the entire skinmap was mirrored, and so any blood splatter on the chest ended up looking like a rorschach blot. So I carefully unmirrored a few polys here to do the chest.

The other reason I hesitated to do it before is because quite a few of the original id models rely on excessive amounts of blood to mask horrible UV failures. I wanted to make sure this model didn't do that anywhere, which is why the blood is a bit restrained. Hopefully he still looks like a butcher! 

that ogre looks awesome,all it needs is a small amount of blood specks and splashes on its clean face and it will most likely be a widely used replacement 

Thanks for the toppic.
After my own experience with quake models I must say you skinned the Orgue well. In the overall making of models I find the texture part the hardest.

I must admit that if i hadn't had Quark4.07 I couldn't change the dimensions of the model, nor manipulate groups of vertices.

One of my greatest concerns of QMLE is the texture part.
What do I do with tex triangles that are mirrored after imported in Qmle?
If I delete the triangle and patch the vertices again the triangle:

comes back with the same texture, so it's useless work

comes back with a extensive texture subdividing, so texturing can only be done by percisely following the lines untill they make squares. 

Here's how I avoid the problems with the mirrored textures in qme: I don't use qme for that model - at all!

Now this is something I'd like you to try MadFox. Have a go at making a quake model without using qme, and see how it goes. If you don't like it, then that's fair enough. But based on the problems you've posted, I think you will like it. 

feels like asking how to learn riding a bike,
and then say don't use the bike. Start walking.

^^

I don't make the model with Qmle, I'm glad I can import them into Qmle with 3DS files. This goes with an animation programm which is more specificated. I have to change the export to one patch per polygon.
And as it only goes with squads, all triangles get doubled.

Then I'm confronted with importing the New Model from frame.
Saving this first frame also makes my skin frame.

Then I have the choise to turn this first 3DS frame by changing the skin adapture. According the import file it will be a front sight or a side one. So when a triangle gets mirrored I'm delivered to Qmle weary workarounds.

I already tried other ways, but the thing that knocked me out was the import/export to Max3D.
Everytime I seem to get two vertices more by exchanging. 

to put it under a restrictive license. 

Do you mean Qmle or Max3d?

Here's a new version of my Granito monster.
The first one was rather blocky.

http://members.home.nl/gimli/granito.gif 

still need many fixes but is looking great! 

feels like asking how to learn riding a bike,
and then say don't use the bike. Start walking.

But the bike keeps crashing, mostly because it has bent wheels, no handlebars and a loose chain. Under those circumstances anyone would recommend you try walking!

I don't make the model with Qmle, I'm glad I can import them into Qmle with 3DS files. This goes with an animation programm which is more specificated. I have to change the export to one patch per polygon.
And as it only goes with squads, all triangles get doubled.

Yes! The point at which you start importing the frames into qme is the point where the problems arise. This is what I'm driving at. You can avoid that problem by creating an mdl with all the frames in first, and then open it in qme.

I'm not saying it's impossible to make a model importing it frame by frame in qme. But if you import frame 1 into QMe, then change the original model, then try to import frame 2 from it, then it's very likely to fail. The import system from QMe just isn't designed well enough to do that(if indeed such a thing could be made).

The only reliable method is to re-export all the frames from the latest version of the model, and import them into a fresh qme file. Since then you need to scale them all, reimport the texture each time, etc - EVERY TIME the source model changes, it becomes a huge hassle. But if you stick with just QMe for the conversion, it's what you must do. 

this has bit me in the ass twice, once a few years ago, and then it happened again until i realized what was going on:

If you are modelling something like a laser or fireball or something, the temptation is to just fill the entire skin with the color or pattern that you want to use as a texture. The problem is, glquake and most variants will flood fill black into whatever color is in the top left corner of your skin. So if your blue laser has blue all the way to the corner, that blue will turn black and you will be saying WTF when you see it in the engine.

Fix: for solid-colored skins, put a single black pixel (or other un-used color) in the top left corner. 

Trinca, thanks, but explain me the need of fixes.

Preach, don't care my foolish waistblam, it was just the first thing that came up to me. Being modelling so long on my own way made me more curious to other ways.

Hassling the first frame is because I want to have a good skin.bmp
When the basemodel is imported it can be on different sides. At that point my model is already done. So I can import them as one load, and the only problem I reach is some verticemeshes. The way I described it was somehow confusing. My fault.

Something else got my attention in trying to avoid the mirrored texture.
When I delete a triangle in Qml and add a new one the original count gets different. This seems odd as logically this shouldn't be so.
After that I can't add frames to the original.
But when the model is full of frames, these changes don't seem to bother. 

The reason why you can change triangles like that is because the first frame you import to qme is given special treatment.

When the first frame is loaded, the program loads the triangles and the vertices. The vertices are assigned numbers as they are loaded, and the triangles are recorded as sets of three numbers, each number corresponding to one of the triangle's vertices.

For all the subsequent frames, the triangle information is entirely ignored. All QMe does is load the first vertex from the file, and move vertex 1 to it's location, then load the next one, and so on. The list of triangles from the existing model is always used. You could import a frame from an entirely different model, as long as it had the same number of vertices.

The obvious danger is that your modelling program might not always export the vertices in the same order, particularly if you change the model somehow between two exports. This is how triangles can start to go astray. There's no way to control this kind of thing, which is why the import process can get frustrating. As far as the exporting 3d package is concerned, one ordering of the vertices is as good as another. But for the import, it's the only important thing! 

You could import a frame from an entirely different model

This reminds me to the moment I had the last death frame of granito,
and used the expand function in Milkshape to make all polyhedrons
wide out as an explosion.
It took me quiet some time to make sure I had the right count.
The frame imported the well, but when I closed qmle and reopened the old death frame came back again.

So it are the vertice count that need to match, not the triangles? 

In my search to new monsters I'm fixed upon the need of some danger in Quake waters. Only the hartbreaking code part stopped me from doing. This doesn't avoided me to try and I came up with this creature.

In Quake defs it outranges the limits as it goes up to 507 verts and 957 triangles. But I still see it appear in Quake so my greatest concern is to have it good skinned.

http://members.home.nl/gimli/frogman.gif 

;] 

 

I restarted the frogman again because the base frame had a bad texture error. By doing so I got messed up with vertice errors that went so far that now on my x-th frame I became a little nerd.

I wondered. If I look at the dragon.mdl of DOE it seems they have cut the whole monster flat on the texture frame. If I look at my base frame I get the picture of the monster front and back. If I cut the monster into pieces (sure, one day) Qmle gives me the well known error: vertices and triangles are not the same.

How do they do it? 

found it. it has something to do with cheating qmle import and export abbilty's.
yes, this makes the texturing a lot more acurate. 

I plunged myself adding a new weapon in Quake1 and have come to the point I could compare it with the SuperNailgun. I added an arrow and add it to this weapon. Sofar sogood.

Then my perfektionistic habbits turned up and thought: how can I make this arrow fall to the ground instead of vanishing in space?

I'll stop because I want it's velocity not as fast as 1000 and I want it replaced by the axe and... so how make I fall it against a wall and it lies there for say a few seconds?

And post with content so here I go...
http://members.home.nl/gimli/cross.zip 

i did this for my stake gun a while back.

essentially, you're going to go into the projectile touch function and get rid of the the lines calling remove(self) or SUB_Remove().

now, it's a matter of changing the movetype, so where the remove lines were, you put it self.movetype = MOVETYPE_BOUNCE.

now, you don't want the thing to stay there forever, so we're gonna put SUB_Remove() back in, but in a different way.
put in self.nextthink = time + 4 and under that self.think = SUB_Remove. this will get rid of it 4 seconds after it hits.

finally, you can add in some extra stuff like making it spin around randomly with setting self.avelocity to some random values or you could spawn a TE_GUNSHOT for sparks or something else. 

necros, I will try it out.

But I was thinking, what if the arrow doesn't hit a wall but a monster?
Then it should disappear immediate. 

you're quite right.

luckily, it's very easy to do so.

simply make a check:

if (other.flags & FL_MONSTER)
remove(self);

this will check if other (whatever it hit) is a monster, and if so, remove itself. 

Look in the RQ code for nails.