In hearing why are BSPs so ill-fitted to host trees, that is causing all these glitches you mention? 

The bsp algorithm starts to really creak when you have a lot of detail involving faces at arbitrary angles. You've seen HOMs right? Where a face is dropped and you can see the grey void. When trying to make a tree that's slightly more attractive than something from 1992, the probability of the bsp process b0rking and you getting these dropped faces is rather high. The bsp algorithm just isn't really cut out for dealing with arbitrarily detailed and complex mesh geometry. You're in "here be dragons" territory in terms of bsp tree complexity. At the very least you will need to make each tree a func_wall or func_illusionary so the bsp tree mangling doesn't also affect the rest of the map (which can result in odd PVS glitches amongst other horrors).

I gotta scooch now but I'll elaborate more on the mdl idea later. 

some example maps of way back when you attempted to create those BSP-supported trees still available? I’d love to see these artifacts and glitches by myself, try and understand what’s going on within the engine with them. 

Foliage would probably require additional lighting mechanism in order to look acceptable.

First: in order for trees and what not to cast shadows, some simplified impostors/low LOD models would be used in vis to cast shadows on a static geometry.
Second: Vis would probably need generate low frequency lighting information (spherical harmonics every 64 units or whatever) which could be used for foliage shading. This way shadows would not be baked onto models and swaying trees (or grass) wouldn't look too jarring. 

Now that I think about it: SH would also affect trains and enemies plus SH exported out of the bsp could serve as a rough lighting hint in TB. 

Would love post-processing options. Even basic color tinting to high, low, and mid values would add so much power.

Proper height fog would also be nice, instead of just distance fog. 

progs_dump 1.1.0 RC3 has persistent keys so you can use multiple gold / silver key doors with the same key (as in DooM.) 

I mean being able to have different kinds of keys instead of multiple gold or silver keys. It's something that I think would be cool. 

some example maps of way back when you attempted to create those BSP-supported trees still available?

I had a look but I only keep the last 5 iterations of any given map, and that old stuff has long been cast into the digital abyss.

To reproduce, just go as far as you can with obj2map buggery of organic mesh structures and see how far you can get before it starts causing problems that make you think "this is such a dumb thing to be doing using existing q1 tech". 

So let's keep in mind that engine features should be thought out with engine standardization in mind while mapping features only rely on progs distributed by third-parties.
Some mapping features are not worth to "hard code" into engines imho 

Yeah the idea is to come up with ideas for obvious (and realistic!) engine features that would get a lot of use and deserve to be widely adopted on all engines, not just the niche "eye candy" engines that none of the mappers here seem to be interested in. 

That sounds like a feature that would sit great within the existing quake vibe, and in fact enhance it, like the distance fog does. Literally every map now uses distance fog and I would imagine height fog would be similarly popular. 

Is this different than volumentric fog or an updated way of referring to the same thing? 

While height fog could fix this a bit, i would be interested in seeing real fog, one that needs to be lit and in which the increase of fog per distance and the formula can be changed like with lighting attenuation, as it is now it looks cool, but the fact that has nothing like real fog save if i make it real thick or light the entire map strongly has made me not use it ever, even after trying on several maps.

On the other side i see the current one good to use as a sandstorm/heavily concentrated dust, or as darkness to make it look like the player lights around. 

Fog volumes could also be nice, but that's different.

@cocerello are you talking raymarching fog? Or some other tech? 

What I would like to see in Quake, are rain effects (like in AD Sepulcher under QS Spike), realistic snow storms, thunderstorms and lightning effects. More realistic fire and smoke...

And better looking trees and bushes. 

Can you lot stop beating around the bush and just rename this thread "Stuff we want in Quakespasm because it's not like any of us are ever going to give a shit unless it's in Quakespasm".

May as well at least be honest about it. 

"honest" says the anon 

As I've said a number of times now, it's "Realistic ideas for engine features that would be broadly popular amongst the contemporary mapping community and thus have a good case for being standard across all engines in the same way that coloured lights and distance fog are".

Not sure if thread titles can take that many words.

May as well at least be honest about it.
Thanks for that advice, "anonymous user". :ohtheirony: 

beaten by dumptruck! 

Rotating skyboxes?
Multiple skybox layers (e.g. cloud layers) with ability to independently rotate the layers?
Lerp different skyboxes over time?

Just shooting the shit here... 

I forgot about that, was totally on my list to ask for! 

I do not know what would be required, but probably not much of a change, but i do not know much about code.

I am talking in results' terms, so i will use examples instead:
- In my last map, i put on a side of a big room a hole from where an enemy will ambush the player and another with some items, so i kept them in the dark so they would be harder to spot, but with the fog on, those holes are lit by the fog because it is always lit like water, making the hole stand out with light instead of being hidden. And there is no way around save for making the fog almost non-existant, as if i darken the fog it will no longer look like fog and i would need to turn it almost black to achieve it.
Another side of this is that darker parts stand out in general more than bright with the fog on, so the fog needs to be dark like dust clouds like in most Quake maps, or to be used to blur the farthest parts of the map like in honey.

- Another is that fog is a lot thicker in real life and more sudden, and with this linear attenuation, it end up sticking out more in the corners (because they are further) and not working for anything else apart from blurring the horizon, or block most of the line of sight if made a bit thick. Also if intended to be used as fog most rooms need to be of similar size and the rest way different and even with that it still does not look like fog. If we could change the attenuation (best would be something like a logaritmic formula where the distance at which it begins can be changed), there would not be even a need for height fog or fog by area, as we could work around it to make it look as intended in each room with a global key.

If i think about it, i still have not seen a Quake map with fog, only blur in the distance, dust in the corners, or tricks with darkness like OTP did in mapjam1. 

I've added new request that would benefit from input of mappers. It boils down to "it would be nice to have a single map that works on engines with and without new features". Technical details are here:

https://github.com/quake-mapping-community/quake-engine-features-wish-list/issues/4

On the topic of fog - I'll have a look at the ability to define arbitrary volumes in the map and specify what should happen in those volumes (e.g. sepia tint; green fog within this volume; etc.). Initial implementation would make it impossible to have crossing volumes (well, behavior would be unspecified) but ultimately I think that falloff around the volume edges and interpolation between adjacent/crossing volumes would be a must. Does this sound like something that directly answers your needs? 

Engine feature requests typically fall into 3 categories.

1. "I really should be using the Q3/HL/whatever engine but I don't want to for some reason. Can you port this feature from it to Q1 so that I can continue not using it?"

This is an arms race nobody can win. Better off working on resolving the reason why the mapper doesn't want to use the other engine.

2. Stuff that's actually content rather than tech. No further comment necessary.

3. Vague, ill-defined stuff; it must be "Quake-ey", if must be "subtle", it must be "tasteful", but it's never actually clearly stated what it actually is. This is also a waste of everybody's time as chances are nobody's going to be happy with the end result.

Getting into detailed discussion about how something might be implemented and how it might interact with light/etc can be useful, but it can also be useful to just throw a working prototype together and see how it looks. Chances are it might look just fine, but even if it doesn't you've now got something to work from, rather than spending more and more time on complex and arcane discussions with nothing to show for it.

The best engine features, the ones that last, are in response to real problems that mappers are actually facing. "How do I deal with format limits without compromising my vision?" "How do I have animated lightstyles on the entire world without performance that sucks?"

Pie-in-the sky wishlists are fun and novel ideas that might otherwise never happen can and do come from them. But mappers - people actually, currently making maps - also need to be talking about what problems and frustrations the Q1 engine is causing for them.

My challenge is: list the one major problem you are having. Don't say what you think the solution is - the actual solution might be something completely different - say what the problem is. If somebody needs to ask "but what would this actually solve for you?" you're probably doing it wrong. Be as specific as possible. Help engine people to actually understand what you actually need.

Enough people do that and we should start getting a nice idea of what kind of engine features are needed to be more useful to mappers.