With a glitch, I know.

I use a bone model to animate and it measures normal lengths (1m70). The Quake models are in this standard just 40cm.
When converting from this scale a lot of adjustments get lost, because the modelgrid is 512x512. Importing a giant in Qmle and scaling down is not the way to do it.

I'm convering down the bone-model, as it produces finer details in the movements. 

errrmm...aka "fundamental unavoidable artifact when using the mdl model format, irrespective of tools" jitters you mean?

I've often banged on about a hypothetical "mdl2" format that just uses higher precision for vert coords. This is what I'm going on about. 

Adjusting the bone model had a better result.
Still it's hard to make the right movement with the shoulders. There are two cubes in the upper arm that have a wicked connection.
Bow_Ogre 

I've often banged on about a hypothetical "mdl2" format that just uses higher precision for vert coords. This is what I'm going on about.

Something backwards compatible would be nice, what I'm picturing is:

[standard binary for an MDL]
[extra double-precision frame data]

The idea would be MDL standard, just with 16 bit precision instead of 8 bit on each coordinate. The most compact way of doing that is to treat the standard frame data as containing the upper 8 bits of the coordinate. Then the double-precision part is a second chunk, the same size as the normal frame data, but the vertex coordinates in this chunk are used in the lower bytes instead.

I suppose it would be healthier to add a small header between the two chunks, so further extensions could be added.

[standard binary for an MDL]
[extension 1 header]
[extra double-precision frame data]
[extension 2 header]
[shader language]
[extension 3 header]
[hidden bitcoin miner]
[extension 4 header]
[interpolation rules]

The header could be quite minimal, just a value to indicate what type of extension is coming up, then the size of the extension data. That way engines could skip the extensions they don't recognise and keep going. Existing engines wouldn't even look for the extensions, there would just be a bunch of junk at the end of the file they don't look at (this is how Extended-BSP format worked).

May be worth also adding a value that can be set in the standard MDL header to signal to compatible engines that there are extensions to look for. Otherwise any junk at the end of the file might be misinterpreted as an extension (and I think QME used to write bonus stuff to the end of files). 

How would an extension not cause a file read error? 

The header of the MDL file tells you how many of each repeating element the file contains (skins, triangles, frames). Based on the rest of the data in the header (vertex count, skin dimensions) you can pretty much predict exactly how much data you need to read for each one (animation groups complicate this a bit but you can read them one at a time).

This scheme relies on the loading code running loops of the lengths specified in the header, reading elements from the file until the correct count is reached. At that point, it just stops reading the file - in a normal mdl file that happens to be the end of the data anyway, but if there's more data it's just discarded*. This is known to work OK in the base engines because QME used to tag additional data on the end without making the .mdl file unreadable.

* There is the possibility that a source-port engine rewrote its mdl loading code, and by doing so made an error of excess data at the file-end. The QME files might mean the issue was already caught. Otherwise this engine would not be compatible with extended-mdl files until fixed. I'd say this is unlikely in practice, and would be easy to patch. 

When it comes to getting people to support new formats, you need both a carrot and a stick.

eg:
carrot: higher precision coords.
stick: an annoying message appears until its actually supported properly.

Without the stick its just something that can be put off for another day if anyone ever uses the format, and if no engines support it then noone will ever bother using the bulkier format that tools cannot even write. Think of it simply as a constant reminder that action is needed.
Without the carrot its just an annoying format that has no reason to exist.
So by designing your extended format to have no stick, you ensure that there's no reason for anyone to ever support the format, and thus that there's no reason to ever write it either. Never underestimate how lazy engine devs can be...

Another thing is that the reason to use mdl is qme. remove qme (because it cannot write the format) and you remove the reason for people to stick with such an ancient obtuse format too. Just use MD3 or something, QSS is such a minor upgrade. (ignoring bugs new to qss,) The only reason not to is if you're targetting vanilla, in which case any hidden extensions are pointless anyway.

Additionally, if you're trying to make it easy for engines to support then just add a new alternative type of framegroup - one that's 16bit instead (the stick being that engines that don't recognise it will glitch out weirdly putting the blame on the engine). Nothing drives adoption better than users constantly reporting horrendous glitches.
That way there's no need to go backwards or anything, its just a struct/datatype change (with the old stuff being padded where its read).

Either way, you still need tools. You already explicitly mentioned QME's additional data - part of that additional data being 16bit data. Find out+document the format of that existing additional data and you not only have a tool that can already write your extended mdls (one that people already seem to be using for some reason), but you also grandfather in all those models that were already (unintentionally) distributed with that data. Still needs a stick though.

Or just provide both an mdl and an md3 and throw in a little qc to select formats based upon the engine's supported formats (hurrah for in-game messages recommending users switch to another engine until a feature is implemented properly).
Or just use md3 exclusively and ignore anyone using an engine that STILL doesn't support that. Yes, it sucks for vanilla but in fairness its been a while since I(and presumably most people) ran quake in dos/dosbox. 

People have had 15 years to say "I'm using MD3 and you just need to switch engines", but nobody does that. Nearly all the engine additions that have been actually adopted (skyboxes, fog, coloured lights) succeeded because they were backwards compatible.

It's not about being able to still play it in dosquake, it's about being able to play it in any engine. That's pretty important if you want to keep all the players who don't pay much attention to engine developments, or who value the stability of engines with slow release cycles. Writing off a percentage of an already small audience seems unwise.

Nobody's ever tried to make backwards compatible enhancement to the .mdl format, I'd like to see if it works. Maybe it won't catch on, but the nice part is that it won't matter - because any content that experiments with it will also be forwards-compatible with future engines if it turns out to be a dead end. 

I'd like to see if I can make it work 

I agree that the model that seems to succeed is where there is an acceptable fallback for engines that don't support that feature, such as entity alpha, skyboxes, fog, fence textures, lit files, external textures, etc. In all those cases the content is mostly still playable in a vanilla engine.

There are exceptions: aguirre's extended bsp limits, and the bsp2 format are two cases where there is no fallback and it still caught on and became accepted. I was going to add protocol 666 to this list, but this is not something forced on people by a map or mod, so users still have a choice of protocols that provide the raised limits. 

protocol 999 

I agree that extended BSP limits are the rare exception that tests the rule (and this is coming from someone who usually doesn't bother playing maps in bsp2 format). To my mind the key difference there is that it's about breaking limits more than visual enhancement, and there's no obvious way you can do that in a backwards-compatible way. 

I always figured the reason to do a 16-bit mdl format is so you can make monsters that would otherwise look like total trash in mdl. The thought of having a large chunk (most?) of your audience just seeing the trash version anyway because of backwards compat will probably make you design the model in a conservative way to minimise this, which itself weakens the reason for doing 16-bit in the first place, so eh I ‘unno. 

It seems elegant despite my above misgivings 

wouldn't it be simple to code into the engine a search for a md3(or md2) version of the same model name? So much like the high def textures for those who want to use them.

It would mean that so long as the person modelling had released a lower poly version of the mdl too it would be available and wouldn't break vanilla compatibility. 

you could fall back to an existing entity in the pak. If I make a new monster md3 but the engine doesn't support it, fallback to an Ogre. Have that fallback mdl definable by the mapper. 

^^^^ that's stupid 

I still don't see how it would be possible to do the amazing effects (outside of full fledged particles a'la Maya or Blender) that Preach manages to pull off with the mdl format. I'm still at a loss on how to make polygons dissappear into themselves. 

The trick is that you take each particle, and on the frames where you want it to be invisible you apply a scaling transformation with scale factor 0 (typing the value numerically is the surest way to do it). There are variations on this, like on some models I only apply the transformation on one axis, so that the particle collapses into a line rather than a point. But it's all about scaling - it's the easiest way to ensure that all the vertices align so the polygon disappears. 

and this is coming from someone who usually doesn't bother playing maps in bsp2 format

This is heartbreaking. 

Is there anything that would bring cause for a bsp3? 

I have now made an arc_ogre, but I am faced with the problem that my splines are converted into four on each clip node when converted. The result is that a q1 model with relative weight triangles is converted to two triangles in each square. I can only save them in squares, which are converted to two triangles.
If I import this to qmle, the ratio of internal triangles has almost doubled.

Would this make much difference to a model with only half of verts / tris? As long as it stays below 1000tris / 2000verts, it should make little difference. 

Sepulcher allegedly came close to hitting the upper limits, and also it did something that required a change in Quakespasm, but I don't remember what.

The 3DRealms game has some gigantic maps, but IIRC they don't use their own map format.

I suspect Bal will be the first one to break bsp2 ;-) but at that point, adopting q3bsp would probably happen first. 

Although strictly speaking some engines (e.g. unmodified GLQuake) do have a limit of 1000 triangles, the original software engines allowed 2000 triangles, and pretty much every custom engine at least restored the limit to that level. So you're probably OK to exceed 1000 if you need to. 

In my case it is not the tri limit, but the question if I should simplify a working model with relative high counts into one with less for benifit of better performance.
It's quiet a lot of work doing this in Qmle.