I'm not sure that looking at Quakespasm to develop a game project if you are interested in things like RayTracing, md6 models and using static meshes to construct the environment is the most 'sensible' route.

Quake is brush based, and Quakespasm is meant to reflect that. The .mdl format is actually quite atrocious, and making terrain with mdl meshes is not going to work. I think the idea behind QS is to be faithful to 1996 Quake.

Although I love all manner of crazy and ridiculous ideas involving Quake, it really sounds like an idea of this scale would be better suited for Unity, etc.

It would also stand a chance to actually generate consumer interest in that case too. 

...who has been using Unity for the better part of a decade I would say try Unreal first, for the sake of your mental health. Unity is great for banging out shovelware minigame type stuff, but try to do a proper game with it, and all of its dumb limitations and performance issues will gnaw away at you until you are a desiccated husk, devoid of joy or life. 

Yeah, it's 1996 Quake with some additions inspired by Quakes 2 and 3, and others from elsewhere. As a general rule the goal is high fidelity rendering of the original content rather than replacement content.

Shortly after the Quake source released there certainly was a push towards adding eye-candy features, but as the years have gone by things have settled more towards a realisation that the original look was a classic and that cleaning it up and presenting it in a modern, accessible and high quality package is a better goal.

There is no "line" here; when it comes to features (and pheaturez) it's a matter of testing what the community has appetite for, and choosing those which have fewer barriers to implementation but maximum return on investment. Picking fights you can win, in other words. So, implementing BSP2 for example is a couple of hours work, it coexists peacefully with everything else, and even software engines can join the party.

There's an argument to be made that if most of what you want is features from another engine, maybe you would be better off just using that other engine to begin with. "I want MD3, bezier patches, Q3 lighting" - the Q3 engine is a great platform that already supports those, maybe you should use that instead? 

i agree, quake looks like crap with a bunch of randomly downloaded replacement content and badly implemented eyecandy like bumpmaps lensflares and fog everywhere. that's not what i wanted at all.

is there any reason though that quakespasm supporting iqm would be a bad thing? it was supported in rmq which you were part of mh.

i realize i can just use another engine. if everyone went to another engine though there wouldn't be quake anymore.

the reason we were given qc and engine source at all was to expand and go nuts. has been this way since the beginning. i think if we are artificially constraining ourselves to an idea of what quake was, that's not quake at all. we wouldn't have had qrally or tf or malice or all sorts of other things without innovating and using quake as a platform. quake-movies, now known as machinima for example.

quake the engine is not the same as quake the game. you can still do a classic looking map with access to extra engine features. switching all the features on like a spastic kid in a candy store isn't the answer. having it there as a feature for modders to make use of is the way.

ericw's light is using texture-based radiosity which originally came from hl, it doesn't mean these maps are all going to look like hl maps when compiled under it though obviously. we need more features like this, not less. 

You are basically just saying "why can't we make Quakespasm the same as Darkplaces and FTE".

The easily answer is of course "Just use Darkplaces and/or FTE". 

engine popularity comes and goes with time. right now it's quakespasm, and tomorrow who knows what it will be.

i don't really want to force people to use a particular engine. i want to know my sprites and models and maps will just work.

there used to be a quake standards group to make sure everyone was supporting common file formats and things like that. 

I think it's reasonable to say that absolutely nobody likes the MDL format. Not even John Carmack liked it back in 1996. What it's trickier to get consensus on is: what should replace it? There's solid arguments to be made in favour of a number of different options, of which IQM is only one. 

Considering the currently way-too-high barrier of access in modelling for Quake, how much would a wide implementation of IQM help eliminating it? 

I like either of these 2 options if we're talking about a better model format in the 'spasm:

1) A conservative update of .mdl that simply bumps up limits, most crucially making vertex coords 16-bit instead of 8-bit. The model equivalent of bsp2 basically. Because it's similar to vanilla mdl, it should involve the least amount of bollocksing around to get engines supporting it.

2) md3. This has the advantage of already being a standard. It lacks stuff like quake's model flags though, so there's other bollocks to consider. It has the advantage of existing tool support with blender scripts and whatnot. 

Already - Darkplaces, FTE and Quakespasm-Spiked support md3.

Number of quake mods from funcsters that use md3 models: 0

No content, so why should any other engines bother with the support? 

MDL sucks except for where it doesn't which is morph animation and the ability to make polygons dissapear in certain frames such as some of Preach's effects models or as completely different poses such as mushrooms or candle models from AD.

I don't know of any other format that let's you make each individual frame as if it were a separate model except for source engine's .MDL which is pretty much the same thing but you can have skeletal animation and use a separate mesh for collision.

All else uses a skeletal armature as far as I know. 

Still can't find anything other than blendshapes and even that is 't as powerful as the .mdl format. 

md3 is a vertex animation format too. 

mdl, md2/3/4/5/6, and iqm are all a quake specific model format. that's both good and bad, but mostly bad as far as the modeller and animators are concerned.

i think without question the best model format would be either FBX or collada, these are the most common formats and modelers and animators will be able to export for it easily from many different tools.

as far as removing the barrier to modelling of quake: this might get more serious modellers interested to make models for quake since they don't have to work with ridiculous formats they've never heard of. fbx and collada are so common the exporter is installed by default on most modelling packages. this lets a modeller make models for quake without knowing anything about quake at all. also lets you download these very common files from the net and use them directly for people who can't model things.

https://en.wikipedia.org/wiki/FBX
https://en.wikipedia.org/wiki/COLLADA

these files could be parsed with a standalone utility to add flag data or any other data into the file itself, because it should support arbitrary data within.

might be possible to add this data in the model editor itself by hand. like to a blind data field or on a non-rendering polygroup in the model.

collada is a non-binary text file so it would even be possible to edit that file by hand.

iqm is not too horrible though, i've tested it out. supports fairly high polygon counts and skeletal animations, as well as multiple shaders. also works good as non-animated static mesh.

collada and fbx file formats though are basically futureproof and support an unlimited number of triangles, and etc. whatever limits your engine decides to support will not need to be adjusted in the file spec at all, just the engine. you'll want to allocate as high a limit as possible. 100k triangle mesh is almost considered low poly in some circumstances today. consider the high-res monitor resolutions when quake was released, everyone was playing 320x240 and yet it supported really high modes to future proof it. 

both collada and fbx support blendshapes, if the game engine will support parsing that data and using it. you can have blendshapes and skeletal animation in the same file so it's ideal.

it perfectly replicates the vertex animated behavior of the .mdl alias triangle models.

when doing blendshapes the winding order of the vertices is important, so keep it in mind when creating your file parser. 

My vote is on md3 (if it matters) as a standard extra format to support. DP and FTE already have this I believe.

Relevant Exporters here for everything:
https://www.katsbits.com/tools/

FBX is not bad but it can be a lot harder to fully support it. Unless someone has the time it prolly won't happen. 

the .mdl files originated as .tri files from alias power animator. they only become a .mdl when they are compiled by a model tool that came in the original quake sdk. this compiler was named modelgen and in q2 it's called qdata.

the direct decendant today of that file would be blendshapes stored as an FBX file, exported from autodesk maya. so blendshapes are indeed as powerful as the .mdl file, it's identical.

alias was sold to autodesk in the 90s. power animator became maya.

blendshapes are able to be created by almost any program, so maya is not needed.

saving blendshapes as FBX or collada does the exact same thing. either file format works fine. 

Theres been over 200 single player maps made for Quake in the last 2 years. I think Quakes doing just fine without all this stuff you're asking for that's already implemented in other engines no one wants to use. 

some implementations of these model formats are only partial. for example in spikes version of quakespasm he doesn't support shaders or tags on the md3 file. so you have to be careful here what you're asking for.

it would be great to have one solid implementation of a model format that can do it all and be used across all the quake engines.

converting a md3 into collada or fbx would be easy, you could batch convert them over with no user interaction required i bet. 

Theres been over 200 single player maps made for Quake in the last 2 years. I think Quakes doing just fine without all this stuff you're asking for that's already implemented in other engines no one wants to use.

Indeed. This is the stark reality. I'd like to think there's all these incredible maps and mods that are just sitting idle, waiting for Quakespasm to implement md3 before they unleash themselves into the world, but I think in reality if quake content creators actually want to use other model formats, we'd have seen some content by now. 

Seriously who are you going to retain to perform the labour behind developing a new Quake engine that will support fbx format, static mesh with collision, and 'ray tracing'. Do you have a 7 figure budget?

Honestly just call up id and ask to license idtech 6. This is absurd. 

kinn, i noticed that you were asking when qs would support q3 map format in another thread... in this thread you said nobody wants this newfangled crap!

the reality is people do want these things, including you, but every time it gets brought up on here there's a huge backlash against whoever asked for X new thing. quake doesn't need this shit blablalba. i think people have just given up mentioning stuff like this because it might get into a flame war for no reason. but this thread was created specifically to talk about it so here we are!

anyways, lots of great information in here so far, and in case anyone wants to consider it we have lots of ideas for improvements to make maps and engines better than ever.

@Redfield, i don't think its absurd, we already have mesh with collision or you would fall through the floor of the brushes you stand upon. none of what i mentioned requires a 7 figure budget. 

kinn, i noticed that you were asking when qs would support q3 map format in another thread... in this thread you said nobody wants this newfangled crap!

this weird obligation people have to pull up old opinions(3 years old in this case) of people to use against their new, current, opinion is pretty absurd. 

I'm taking about the actual reality of how and why things get implemented.

Of course I think it would be cool to have md3, q3bsp etc etc. Doesn't mean I can't drop a few sodding truth bombs every now and then does it?

I'm not saying we shouldn't have these things, I'm saying this is why we don't have these things, and this is why the programmers don't think it's worth their time supporting these things. 

i keep hearing stuff like "if people wanted it we'd see X by now", here and in other threads.

i don't think it's that easy to dismiss. for example why didn't we see many q3 format maps?

because darkplaces didn't support the full implementation of the q3 shader system. this basically killed it for me and probably everyone else. and FTE uses and ungodly complex glsl shader, i would have to convert all my shaders over to that after learning glsl.

as well, model/anim implementations vary so wildly and are partial at that. if it won't support what you want to do because it's partial, it's as good as no support at all.

if you don't agree it's fine, but this is my take on things.