Renderer FAQ

[illwieckz]

I noticed there is a lot of misconception floating around, and some misunderstanding too.

So I did a FAQ, so people don't have te re-explain things over and over, and people can redirect to the FAQ when needed:

https://wiki.unvanquished.net/wiki/Renderer_FAQ

[illwieckz]

Example with recent things I have seen on the chat, with FAQ answers:

the complexity of implementing software variants of stuff in modern OpenGL (3+) hinders the totality of actual players for no reason

• Q: Does the old-OpenGL compatibility mode slow down the renderer on newer hardware?
• A: No, the old-OpenGL or new-OpenGL execution path is selected at map load.

someone could of course also mention the insistance to keep more than antiquated openGL support (even recent openGL are obsolete, mind you) in the core rendering, preventing the use of nice features that allow mesh instancing, which have the potential to drastically drop the rendering cost

• Q: Do you have a plan for Vulkan?
• A: Yes, a Vulkan renderer is in development.

• Q: Will you provide a renderer free of support from very old hardware?
• A: Yes, the Vulkan renderer is meant to drop support for very old hardware.

the sRGB can be useful, as long as it does not impacts old maps

• Q: Can a legacy map be mistakenly rendered with the linear lighting?
• A: No, maps have to be explicitly rebuilt for the linear lighting for the engine to use linear lighting.

• Q: Is it still possible to rebuild maps the old way?
• A: Yes, we provide multiple old map build presets. The renderer keeps the support for what is built the old way.

there are hundreds of other dark maps we could see in nice light with adaptive exposure. but you blocked that
you dismissed it in favour of your srgb thing

• Q: Will you provide adaptive lighting?
• A: Adaptive lighting is planned, work is in progress but not merged yet.

• Q: Are the linear lighting (sRGB support) and adaptive lighting meant to work together?
• A: Yes, in fact, both linear lighting, tone mapping and adaptive lighting are not only meant to work together, they are cumulative. Adaptive lighting requires tone mapping to work and requires linear lighting to be correct.

you made considerable changes to how a map's lighting is displayed. thankfully, you rolled back the most invasive changes.

• Q: Did you change the way the map lighting was rendered?
• A: No, but we added a new way to process lighting (linear lighting, aka sRGB support).

• Q: Does the linear lighting (sRGB support) change the way existing maps are rendered?
• A: No, maps have to be explicitly rebuilt for the linear lighting for the engine to use linear lighting.

• Q: Did the overbright patches change the way legacy maps are rendered?
• A: No, they restored the way legacy maps were rendered. Previously we had a bug, so if you see a change, it's because a bug was misrendering something before.

• Q: Did you have to rollback the overbright support?
• A: No, our first fix was incomplete when we released it first, we then shipped an additional fix to finish the compatibility support. It's incremental improvement.

[killing time]

The overbright response is too simplistic. Some Quake 3 and Tremulous players/mappers were playing with 1 overbright bit, others with 0. It could depend on your OS and configuration. Our latest default of r_overbrightBits 1 is consistent with what players playing full-screen on Windows would have seen with default settings.

If you determine that a specific map was designed for overbrightBits = 0, it is possible to fix it by adding a key in the worldspawn entity.

[illwieckz]

Thanks for the details. Yes, the overbright bit thing is a bit more complicated than a sentence can tell, but the FAQ answers better be kept small. In id Tech 3 ecosystem, “players playing full-screen on Windows” is the reference experience. We also have actual and historical screenshots (like atcszalpha) showing unambiguously that such overbright setting was the expected behaviour in Tremulous time as well. The renderer did not respect that legacy and has been fixed. And yes a simple map entity key can just enable other options.

[illwieckz]

Instead of doing a very large paragraph for a single question, I added two questions with their answers:

• Q: Is the original overbright configuration used when rendering legacy maps?
• A: Yes, when rendering legacy maps (or maps built the old way), the default overbright settings are the ones from the reference id Tech 3 experience which was “players playing full-screen on Windows”, we also have historical screenshots showing unambiguously that such overbright configuration was the expected behaviour in Tremulous time as well.

• Q: Do you support other overbright variants?
• A: Yes, mappers can customize the overbright feature using specific keys in the worldspawn entity, it is modifiable both in map source and precompiled BSP using existing tools.

[killing time]

It's valid to say that overbrightBits=1 is the reference experience for Quake 3. However Tremulous had a huge Linux player base, so I would expect there were some mappers on non-Windows setups. Assuming that Linux clients in fact didn't implement overbright, there must have been a lot of people who only ever played with overbrightBits=0. We can find screenshots demonstrating overbrightBits=1 but I bet we can find ones with overbrightBits=0 too! I'm just trying to say that overbrightBits=1 was probably not an overwhelming majority of Tremulous experience.

In general, there's nothing wrong with an answer of more than one sentence. Dismissive answers that deny any complexities don't inspire confidence.

[killing time]

I added some more detail to one of these:

Q: Did you have to roll back the overbright support?
A: No, but when overbright support was reintroduced in 0.55.0, it mistakenly made the effect too strong (equivalent to r_overbrightBits 2). In 0.55.3 it was corrected to use the historical Q3/Tremulous value of r_overbrightBits 1.

[illwieckz]

In general, there's nothing wrong with an answer of more than one sentence. Dismissive answers that deny any complexities don't inspire confidence.

Yes, that's why I added those additional Q/A lines. What I meant is that it's better to split in smaller questions. It helps to explain why the answer is longer, and help to better picture the complexity.