Keep in mind, Quakespasm doesn't even support external textures for monsters! Which is more of pain than it should be in a FitzQuake engine because of gl_mesh.c

[Mark V does, another case of great code being available for the taking! Some of it being due to some great tips from MH.] 

I'll have to give that engine a look I guess. Never heard of it till now. Alpha Key would be a cool feature to support at least. I don't mind making textures look classic quake in palette or at least heavily reduced colors either to fit in with the games look. I would still be down with some shader support down the line like glow textures but for now MD3 on its own would be cool.

For model info like blood trails or spinning maybe include a text file with the same name as the MD3 with some prefix or suffix to include some flags? In the end I just want more vertex precision that is all or IQM for bones still running at 10fps so the game logic does not get borked. 

Yeah - I actually love the crunchily pixellated skins and chunkily low polycounts on the monsters; the vertex swimming is the only thing that could do with being corrected really, as there's no way that can be seen as a desirable artistic look by any sane person.

Eye-candy "creep" isn't really my thing, but fixing obviously bad things about the current look is cool. 

Why not have the md3 act as an extension for the mdl?
If there's a flappy.mdl, get all metadata from that, and then load the actual data from the flappy.md3 if it exists.
Kinda how lit files work.
Progs.dat refers to the mdl.
Trying to load a md3 without a mdl being present should be an error.
As I understand it there are already tools that convert md3 to mdl, so for content that has been explicitly crafted as md3 it shouldn't be too much work to convert it to a craptastic mdl that people running a good engine won't see anyway.

Though I have zero knowledge of the md3 format, so I dunno if there's some obvious obstacle.
The progs will have to be able to treat whatever new format as if it was a mdl anyway. 

I think if the md3 is present it should load that instead of the .mdl kind of like how texture replacements and lit files work.
But it should be a requirement for the .mdl to still be present.

Also Skiff, I hope you're aiming for the lo-fi cabnbubs implementation of your shambler model. It should still fit in with the Quake roster of monsters. 

i like it, do it that way! 

what czg said 

In the end the shambler I am making will be a more modern take on it. BUT if I do get this one done then I could make a more "true" to the original version for folks to enjoy... but seriously the old shambler is origami... its 200 triangles... the dog is almost 600 ha. I have no idea what went on in their heads when making that guy. 

Yea I like this implementation. MDL as a base with all the proper info and MD3 for more precise updated visuals... 

# of triangles is irrelevant. there was enough there to convey the shape of the monster.

it's a very efficient model and well constructed. 

I have no idea what went on in their heads when making that guy.

Every poly saved was a win back then. Also I imagine the 'bler was one of the early models, like the knight. Later on they had optimised the engine enough to allow for 400-600 poly characters like hellknights and dogs, but I guess no-one deemed it worth remaking the shambler. 

I will let that one pass because I do this for a living. Quake got me hooked on modding and game development after all when it came out.

I do agree with Kinn that it was most likely one of the first things and never got updated. Any game with a consistent art standard would not give a tiny dog enemy over 500 triangles and then 200 triangles for what is effectively an end game boss monster.

We love the shambler for its size, soundscape and evilness. It could have done with better construction and for dang sure better rigging back then though :P 

Quake originally ran in 8-bit and 320x200. At that resolution it truly makes no difference whether there are 200 or 2000 triangles on a model. 

But now we try to enjoy it with a little more detail... just a little bit. 

is the implication in your reply that the shambler is a bad model? not sure how you can come to that conclusion. with 200 triangles, it would be difficult to make a convincing model like the shambler. i am judging the model based on 1997 as that is when it was made. i guess you are judging it on 2015 standards, which is not really fair. 

There's also the disparity in triangle counts. The dog gets 600 while the shambler gets 200? I think it definitely smells like a case of the shambler got done first and the dog was done later ... and there was no time to re-visit the shambler. 

So, if I make an md3 I would still bother learning mdl stuff? MD3 is not an industry standard outside Quake world, right? So I would have to learn the tricks of two proprietary vintage model formats? Correct me if I'm wrong, please.

If my model's mdl version is just boilerplate, it would be... more boilerplate to care about. If I have to craft an mdl it would double my work, I would have to model for two formats, my monster would still have to look and work decent in mdl. 

.mdl is about as hard as downloading preach's md3->mdl converter I think.

I may be missing something, so others please jump in. 

it's really that simple. 3d app -> mdl involves md3 so you just keep doing the same thing. 

The issue of md3 backwards-compatibility would present a unique - and possibly quite annoying - quandary, because the more you make use of the capabilities of md3, the worse the fallback mdl is going to look.

Do you not care that a certain percentage of players will witness your awesome tentacle boss monster in the form of a horribly mangled soup of quivering triangles?

Do you purposely constrain your design so that the mdl will still look "ok"?

I think I'd take the latter approach because the thought of it looking terrible in certain engines would grind my goat a bit. But this approach does undermine the whole idea, I will admit. 

How will darkplaces deal with this md3 + mdl model you're planning? 

Do you purposely constrain your design so that the mdl will still look "ok"?

I wrote this article a while back and I think some of it would relate to MD3 upgrading MDL

https://tomeofpreach.wordpress.com/2012/11/19/progressive-enhancement/

The most successfully adopted features across all engines, like fog, skyboxes, external textures and alpha, all exhibit some echo of progressive enhancement, so I think it's a pattern to bear in mind. 

That is very sensible and sound. I agree. 

If I recall, DarkPlaces uses .mdl as the file name.

And then it checks the first few bytes of the file with the name "solider.mdl" for the word "IDP3" to see if it is MD3 (or some other model format). 

In standard quake engines, whether something is loaded as a mdl, bsp or spr is always determined by the header, never by the file extension. In theory you can use any extension you like for anything!

But the scheme that plans to rename an md3 file with a .mdl extension does fail to have any level of backwards compatibility. Something a bit more along the line of...

progs/cultist.mdl
progs/cultist.mdl.md3

...where precaching "progs/cultist.mdl" will first try to find "progs/cultist.mdl.md3" and load that as a substitute if it's available, would work a lot better. A bit like how .lit is a separate file with a name-matching convention, so it doesn't affect old engines but takes effect automatically in new ones.