Some excerpts from EricW Tools doc:


QBSP:

This version of qbsp supports detail brushes which are similar in concept to Quake 2’s detail brushes. They don’t seal the map (previous versions did).

...

SKIP
Any surfaces assigned a texture name of skip will be compiled into the bsp as invisible surfaces. Solid surfaces will still be solid (e.g. the play can’t walk or shoot through them) but they will not be drawn. Water, slime and lava surfaces can be made invisible using the texture names *waterskip, *slimeskip and *lavaskip respectively.

HINT
Hint surfaces cause a bsp split and portal to be generated the on the surface plane, after which they are removed from the final bsp - they are neither visible, nor structural. Strategic placement of hint surfaces can be used by a map author to optimise the PVS calculations so as to limit overdraw by the engine (see also: vis(1)).

Use a texture with the name hintskip on any surfaces of a hint brush which you don’t want to generate bsp splits or portals. All surfaces of a hint brush must use either the hint or hintskip texture name.

LIGHT:

"_color" "r g b"

Specify red(r), green(g) and blue(b) components for the colour of the light. RGB component values are between 0 and 255 (between 0 and 1 is also accepted). Default is white light ("255 255 255").

All of which are compatible with Quakespasm. 

Eh well, some of those things are possible with various engines, some aren't, some have been tried and don't look great in Quake-like content. I won't try to enumerate the details (muk has tackled some of that, and maybe someone else will also jump in), but a couple of general things I'll throw out into the thread:

For developers, if you're going to make a new game in 2018, a Quake1-based engine is unlikely to be the best choice.

For players who are specifically interested in playing Quake and Quake-like content, new features are not always needed. I'm not suggesting "no new features" is the right answer, but from a player's perspective it's not necessarily an issue when a Quake engine doesn't have a particular bolt-ons buzzword. 

the q1 standard for RGB lightmaps is .lit files, which most modern light tools can produce. These files can be used in conjunction with normal quake BSP files and also BSP2 files. 

the only stuff in your list that you *can't* do with bsp2, ericw tools, and quakespasm - is q3 bezier patches (which isn't really a big deal).

Higher res lightmaps we're trialed (.lit2) but I don't know if that's supported in the main quakespasm build, someone else has to answer that one. 

and it doesn't support a fancy model format yet. 

It's up to the mappers to decide whether they want to use the new features made possible in DP and FTE. In this community (i.e. the mappers based mainly in this forum) they tend not to. If the content is there, more widespread engine support will follow. The content isn't there though. 

...I think the main reason mappers don't want to target FTE/DP is because the players (who are basically also the mappers), don't want to play quake under FTE/DP for various pretty understandable reasons (don't like the physics, don't like all the aesthetic stuff it changes etc. etc.) 

thanks everyone for all the info. this doesn't look as restrictive as i first thought. i would not do a whole game, more like a little partial conversion.

so if you were to create a terrain made of mesh, is the collision handled well? is it computed via the vertices of a separate collision mesh?

how good would the light look on it? this is a main reason why large lightmaps are useful to me. since large models need more lightmap.

i'm also interested about animation support of the models for making animated map models or making new monsters.

are any of the engines going to support realtime radiosity / raytracing? graphic cards this year are going to bring this feature, and it will become the standard going forward in games i think. 

Quake creates one lightmap per face (atlassed into fewer, larger textures at map load), so a large terrain made of many faces does not need large lightmaps -- it will just use many small ones.

In terms of how good it will look, there have in the past been bugs with visible lightmap seams at the edges between too faces, especially with odd angles. Not sure if those are solved with modern versions of the tools. But when the system works, you will not see the seams. 

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?