I have no idea who's responsible for whatever's on that screen, but they should be banned from using a computer. 

looks like someone put meshsmooth into the engine???? 

 

Yeah that screenshot's like a bingo card of terrible programmer art "enhancements":

Ultra-hi-res replacement textures? Check.

Replacement textures look like they were made with Gaussian Noise?Check.

Parallax mapping on textures dialled to 11? Check.

And so on... 

JoeQuake 0.15 has an implementation of MD3 that mere mortal engine coders could work with. source

But the MD3 implementation in JoeQuake is different than DarkPlaces or FTE.

There are also several outstanding questions like how to communicate eye position?, spinning (unless you don't care if ground weapons work), blood trails, frame groups? and the other flags/info in .mdl not present .md3. And where the texture go, which should be the folder the model is in but I don't think DarkPlaces does that. And how will you colormap the textures or do you just say to hell with it.

Then you have the idea that the implementation should be compatible with DarkPlaces, which could be awkward because you might be talking effectsinfo.txt (name?) to have compatibility for the extra flags.

Then you have the the idea of what MD3 extra features will or won't be supported. Shaders? Alpha?

But JoeQuake has an implementation. Does it work with monsters? Tea Monster MD3 ogre

/Extra info.

If there is *serious* demand for MD3, someone should see if the MD3 implementation in JoeQuake works with monsters and find out how hard it is to make it work. Or even make a prototype for DarkPlaces. Did Spirit's engine inherit MD3 support from JoeQuake?

If people aren't willing to do that, the Quakespasm team has an empty bag of test case scenarios.

/One opinion maybe even wrong. 

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.