I'm sure if someone started making a mod that uses .md3 content (I mean you can already use md3 in Darkplaces and a couple of other engines), then I can see Quakespasm following.

It's just nobody is currently making quake stuff with .md3 content so there isn't a demand for it.

People saying how much they'd like md3 is one thing.

But if you can say "I have a mod. It uses md3 and plays in Darkplaces but wouldn't it be great if it played in Quakespasm also?", then that's another thing entirely. 

Demonstrate a real, working example of a problem that the feature request solves. In the case of BSP2 it was created to solve a map that blew right through the clipnodes limit. The map existed, it was there, it could be loaded in an editor, but it wouldn't compile or load in an engine.

It's not good enough to say things like "has anyone thought about" or "it would be fun to build" or whatever. It's easy to forget that a feature requires work to implement, and that sometimes it may not be nicely compatible with other engine features. The feature may end up being cool or fun, but would anybody ever actually use it? To quote from john Carmack's .plan file from 1997:

Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web.

The trick is to pick the features that don't fight each other. The problem is that the feature that you pass on will allways be SOMEONE's pet feature, and they will think you are cruel and uncaring, and say nasty things about you.

That's as true today as it was back then.

A good rule of thumb is that if you're asking an engine coder to invest time and effort into implementing a feature, then you should be prepared to show that you've invested time and effort into thinking about the request to begin with. 

"wot Kinn said", in other words. 

I was asking because my shambler remake has nice teeth and Mdl makes it a gibbering mess. Not to mention more subtle muscle details and form that get all garbled by the MDL format as well. Its been driving me a little nuts. I like Quakespasm. Have not used Darkplaces yet so I guess I will test it there for now? No normalmaps though :P Don't care for normals on my retro art remakes.

https://dl.dropboxusercontent.com/u/1849053/Shambler_Wip_02.jpg

Starting to paint this guy up now finally :P 

Shamblers are furry!

Looks like you're off to a great start though!

I agree with Kinn/mh. I would say that there is already a fine case for having md3 models as the limits of mdl are plain and clear to anyone with eyes. The problem I think is that the standard mdl models are good enough as is and people still are making great quality mdl assets.

It's definitely a "would be nice" feature right now. 

the standard mdl models are good enough

Allow me to disagree.

Stock Q1 monsters look like baloon animals. 

In modern vanilla like QuakeSpasm you can push level art way further than mdl characters. I believe this is the problem md3 would solve. 

clear to anyone with eyes 

Stock Q1 monsters look like baloon animals.

I'm more worried about the guns - http://triptohell.info/moodles/junk/theblimpgun.png 

Stock Q1 monsters look like baloon animals.

I'm more worried about the guns - http://triptohell.info/moodles/junk/theblimpgun.png 

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...