that sounds right for brush-models, but what about static mesh models such as ase, md3, md6 or whatever models quakespasm is using? pretty sure it only uses one lightmap per polygroup or per shader or something along those lines 

models are lit using the value on the lightmap below its origin, or something to that effect. so a large piece of terrain as a mdl would look odd.

you could export it to obj then use a tool maintained by khreathor called obj2map.

bal has used it with success in his xmasjam2017 map. theres also an instance of it in otps jam9 map.

obj2map + phong can create some really nice looking terrain. 

Quake engines these days are very much focused on the look and feel of the original game but with as much quality/fidelity as possible. Replacement content, etc is of considerably lower importance than the original look and feel being as high quality as possible. If you want replacement content then this site is not going to be so helpful. "Pimp my Quake" doesn't really live here. 

Lightmapped terrain can mostly be done using _phong in ericw's light tool when compiling the map. That should smooth it out for you. Also the _dirt setting can add something similar to SSAO baked into the lightmap. 

i think you are describing vertex lit models muk? lightmap should behave differently. you can usually specify the lighting type in the shader it uses.

also if i recall, there might be a key like _origin which allows you to light the model in one place and let it spawn in another?

yeah i know there are quake-purists don't want to change the look of anything, but the water was never meant to be transparent, no colored lights were meant to be had here, and etc. where do we draw that line? is it too much to ask for some quality lightmaps and models? if we aren't using original bsp file or texture wads why do we have to stay with original alias mdl models? how have i overstepped the line here mh? :) 

No need to be sensitive about overstepping lines. mh is merely pointing out the preferences of many of the mappers here. There are plenty of exceptions. No one is stopping you from using features you want if they actually are supported. You just might be limiting your audience as engines like QS and Mark V are slow to adopt new features by circumstance or design.

In other words: you do you. 

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.