I using 3dMax7 at work to make models for Quake1SP. They good I think. When I load those into qME I get a "numbers of triangles" not matching error message.

Can any one tell me how to convert from 3dsMax7 to qME? If no can you tell me the best ways to make new models or do I have to use the qME. 

I suspect what you're doing is using the import frames command, which isn't what you want to do when starting a new model. There are two commands for importing into QME, "import objects" and "import frames"

Import objects adds the triangles in another file to the current model. It takes the pose it reads from the file, and puts the triangles in that pose in every frame in the model's animation.

Import frames takes the pose it reads from the selected file, and creates a new animation frame in the model. It then moves the triangles that are already part of the model to match the pose that it has read. Obviously, this will only work if there are the same number of triangles in the current model as there are in the file.

So, when you create a new model, there are no triangles, and so you'll get the error message you mentioned if you try to use import frames. Use import object and it should work.

However, be warned, QMe will not import any animation or UV mapping that you did on the max model, just the triangles and the pose at time 0. To get the rest of the animation in, export each frame to a seperate .3ds file, and use import frames(not import objects) to load them.

The UV mapping is another matter, QMe has no support for importing a UV map, and only allows you to create 2 sided planar mappings in the editor. This is because that's the way the original quake models were made, and when QMe was written nobody knew .mdl supported anything else.

So, how do you get a model with a nice UV map into quake? Well, it's a bit more complicated. Track down a copy of the pop'n'fresh MD3 exporter for max(polycount is a good place to start). Now, rather than export the finished model from max to .3ds, export to md3. Finally, open it in the latest version of quark and save it as a classic Q1 model. You should end up with one mdl, with identical skinmap and animations as the md3.

I make the last step sound easier than it often is, Quark seems to have immense difficulty loading the skin with the md3 if you don't set up the directories exactly right. I've been intending for ages to write a detailed tutorial on making this md3 to mdl conversion, so if you get stuck here just say and I might actually get round to it! 

so .mdl DOES support more than just two-sided planar mapping of a speciall-deformed baseframe?

Hmm, if you set every edge to be a border edge, i guess that means you could map each triangle seperately... would that work? 

From what I understand of the .mdl format through my own recent fiddlings, the UV map will appear in Quark because it must be splitting the verts on the model for each actual animation frame in order to correspond to the pseudo-UV map. The .mdl stores not only the location of the verts for each frame, but their relationship to each other in the mesh as a whole ( which is why changing an existing model cause the .ms2 to look utterly screwed ingame ).
What I suspect you're left with is a .mdl with many more verts than it actually appears to be made of, because any vert that has been split for the UV map must be made of 2 or more verts occupying the same coords in the animation frames as well.
I think.
Preach, would this be the case? 

go finish what should be finished

^_~ 

ya, what vondur said 

I know I am just a greenhorn in this case...but

Making new models in QMLE gave me a rather strange experience in extentions in which the models are imported and exported.

I used a AM2000 animation studio, which gave me the intention it would work good with Quake models, as it used the *.mdl extention.
This was not true, because one has 1-4-16 polygons per patch. I couldn't load them in the animator. So I went searching for a manner they would.

First I tried excisting Quake1 models to change in extention so they would be campatible.
The first attempts I made was with the Q2mdlr9b modeller. This was capeable to import Q1
models and export them to ASC and 3DS. This 3DS I imported in Milkshape and exported again to DXF. This was the right extention to import it in the AM2000 animator.
Then I could manupilate the model, give it bones, so I could give it all the animated frames
it needed to export them to 1 spline dxf frames to import them in QMLE.
To my advantage I could make a skin base model and tear it totaly apart, because theanimated frames were already made. This gave me a good oppertunity to skin the model at the best.
I know Milkshape has it own way of doing these things. I have tried, but never succeeded.
In this way I managed to transport the Q2 model grrll to Qmle for Quake1.
I could transport the Q1 models to Q2, although it would tale some time.(and *.qc knowhow!)
http://members.home.nl/gimli/Q1grrl.jpg

So what I intentionally mean is, why not try the extention import and export of the Q2mdlr9b
and Milkshape to transport your model from Max3D to Qmle? 

Yeah, that's pretty much it, the number of vertexes in your model is exactly equal to the number of vertexes you can see on the UV map. This could potentially cause a problem, as the original GLquake vertex limit is only 1000. If you're making a model that has that nearly that many verts already, you may be stuck with the two sided planar mapping. It also makes the file that much bigger, but generally the animations are smaller than the skin every time. I suppose if the model had lots of frames you might notice.

On the plus side it doesn't seem to hurt rendering by a noticable amount, so it's just a matter of making sure you don't ever break the vertexes when you're editing/animating. There are two ways I can see of safely doing this. One is to animate the whole thing as an md3, before you convert it. The other is to have two copies of your model, one with the uv splits, and one without. Since QMe imports triangles not vertexes, you can animate the non split version, then import the animations into the split model. You just have to hope that the order of the triangles doesn't change...go for option 1 is my advice.

But it's very much worth it by my reckoning, the skins are much easier to paint and they use the skin space far more efficiently.
Finally, very important skin tip of the day: Make your skins in power of 2 sizes, like 256x256. You might object and say that none of the original quake skins are like that. This is because they were made before the advent of glquake and all that. Opengl/your graphics card will resize your skin to a power of 2 size when it loads it, so your skins will be sharper ingame if you make them the right size to start. 

Preach: thx, that's cool. Though the issue with animating in Max and having higher vert counts is already relevant to much of what necros and I have been doing ( note: necros now does all our animating in 3DSM then exports the frames - one by one - over to qME ); many verts, many many frames...
Also, re: powers of 2. Right off the bat I endevoured to make our model skins PoT, mostly out of habit from tex0ring. FitzQuake, afaik actually solves non PoT skins by initially 'padding' the skins out the next PoT and using those. metl r0x0rz y'see.

Von/PuLSaR: mapping etc. is done. I'm just waiting on necros getting his elven ass out of WoW and back on the hotdog - I need my codemonkey to fix0r some things. 

preach: actually it's the application's responsibility to resize the texture before passing the data to opengl, but you're correct that you get much better results with gl engines if you make textures powers of two.

kell: correct, fitzquake pads the skins instead of resampling them, because they don't have to tile like world textures do. I also do it for graphics like the console background and menu images and status bar images, since those don't have to tile either. 

damn this blizzard fuckers! argh 

Um...talking of both Chapters and FitzQuake...
Since there are a few skyboxes used in the chapters maps, is FQ 0.8 likely to be released soon? It would be unwise for players to be using 0.75 due to the skybug, but I really want to recommend FQ as the engine of choice for Chapters.

Von: I know. Bastards. Curse them for making addictive games! 

he'll never get his pool open at the rate he is going. My summer social life is screwed. Damn, Blizzard. Damn them to Hell. 

He'll be so into WoW in a few weeks, that he'll end up selling the pool on eBay to buy some rare item he needs in the game. 

well, maybe... i'm really close, but things are also going kind of slow. Maybe after E3 i can wrap it up. 

The pool is the only thing that gets the ladies to overlook my creepy outward demeanor that doesn't cost me an arm and a leg. 

Jumping in with both feet to the fore, what is it the causes us to need to limit vertexes to 1000? I am also playing with models and have strayed over 1000 and the model is not yet finished (super-strength warewolf type creature who spawns from dead... no, hang on, can't tell you everything!) 

Just watched Indie do his 'leap of faith'
and I swear that rock texture is a Quake original :-) 

I suspect the rock texture to which you refer would be rock3_8. It is similar.

re: 1000 verts - I haven't hit a vert or poly limit with Q1 .mdl, though necros and I did exceed the number of frames limit.
I guess it's just another limit imposed by the structure of the file format and how it saves the information. Don't really know what to suggest other than using a composite model i.e. two or more models coded to act in unison like Armagon's torso+legs. Not an ideal solution for what you seem to be making I'm afraid. 

I just popped a 2333 vertex model (it was a wall torch without flames that I downloaded from a 3DMAX site and it looked rather nice)into FitzQuake just to see what would happen and it crashes with a 'too many vertices' message.

Have you got a 1000+ vert model to play or is the 1000 cast-in-stone? 

no 1000+ vert models - the highest I have are in the low hundreds. I doubt it's a limit you'll be able to exceed in anything other than DP or the like. 1000+ is well above conventional Quake size for a model. 

OK, thanks. Clearly I am going to have to hone my modelling skills by some degree - perhaps if I made SuperWolf less hairy or give him less teeth and claws, or somehow chunkify him...

Damn, he was begining to look so good. Mind you, I hadn't skinned him yet! And when I say good, I mean I am the only one who has seen him, and he is the first thing I have ever created, and my mum said my scotch eggs were the best she'd ever tasted when I knew they tasted like soiled carpet. So for good, read 'partly recognisable'. 

well, at 1000 verts I'm sure there must have been some quality definition to the model. But yeah, take a closer look at the id models if you haven't already and see how they represent physiology in as few polys as possible. It's surprising how much you can achieve with only the basics.

And don't scotch eggs always taste like soiled carpet...? 

I've just checked that if a model has more than 1000 vertices then it can't be loaded in standard glquake. (although oddly enough dos/winquake won't crash until about 2000). Lots of custom engines bump this up, as there are a few mods that were released pre GLquake with 1000+ vertex models that won't run in GL.

As for the theoretical limit in the mdl format, I don't really know. I suspect it's higher than 2000 simply because that's a kinda odd number to be limited to, you'd expect a power of two at least. And QMe can load models with more vertexes in, and saves them without difficulty. So if you're using a custom engine you can up this one a fair bit. Then again, if you're gonna use a custom engine you might as well use md3 instead.

So, what other solutions exist? Well, what has been done in the past is to supply two copies of a model, one that works in GLquake and a better quality one for use in custom engines/winquake.
Bit on the messy side though. If there's an obvious break in a model, like a seperate weapon or something you could make two seperate models and just use the QC to tie them together. This doesn't work well with player models, but you should get away with it on a monster.

If you do, make sure you make the attached piece walkmove with the monster rather than teleport it to the monster's origin each animation frame. Frame interpolation moves the monster smoothly between animation frames if it's trying to walkmove, and if you teleport it per animation frame it'll look jerky. If you teleport it every server frame it'll be smooth, but also it's probably less efficient.

Finally there's good old optimisation - from cutting out unnecessary bits, to only unwrapping parts of the model with the UV split method, doing others with the planar mapping, then stitching the two together in a nightmare of fiddling and pain. Don't do the second one if you can avoid it, but if you must, try using qme3.0 rather than 3.1. For some odd reason it's actually better when it comes to editing skins. 

glquake has the max verts set at 1024 and dos/winquake has them at 2000 i think. I recently switched fitzquake to 2000, but in all cases, the reason for this maximum is just becuase they wanted to load models into a fixed-size buffer and since they knew how big their own models were, they set the number to be just big enough.