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.

[illwieckz]

Actually, the FAQ already answers to such another misinformed comment I've recently seen on chat, but then I added details to the FAQ to make it even more explicit:

in contrast, daemon's rendering code takes paths to support as many standard at possible at runtime which is bad for performances because it means the CPU, which is a serious bottleneck, have to run more code each frame, instead of less

• 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 game start and map load. It is not done while playing.

I also stumbled into such comment in chat, which was also misinformed:

glDrawElementsInstanced was introduced in OpenGL 3.1, which exists since march 2009. Take into consideration that unvanquished's 1st commit was either on 29th Marsh 2013
in practice, ioq3 is now a more modern engine than DaemonEngine, on this hardware question.
It have actual support for OpenGL 3.1 as evidenced by the presence of glDrawElementsInstanced in the source code, unlike DaemonEngine.

So the FAQ answers to these questions as well:

• Q: Does the OpenGL renderer supports the most recent OpenGL versions?
• A: Yes, it supports OpenGL 4.6 (which is the most recent OpenGL version) and can even rely on OpenGL extensions that are not part of OpenGL 4.6 like bindless textures.

• Q: Can a single engine executable run either on old or new hardware?
• A: Yes, the wide compatibility range is achieved by loading OpenGL 3.1 as a baseline and selectively enabling extensions from higher OpenGL versions when supported, this is done when the game starts. For even older hardware, older OpenGL versions and extensions are selected when the game starts and functions with alternative implementations are selected at map load.

Of course the comparison with ioq3 is mistaken, the said symbol came from vendored libs, and not every game has to use every symbol. It should surprise nobody that some renderer contributor names can be found in both ioq3 and Dæmon as there is some shared history and community, and (unlike that person wrongly assumed) Dæmon has the most advanced maintained id Tech 3 OpenGL renderer. It happens that some people may infer wrong things out of other things, so we better be explicit to avoid misunderstanding. Mistakes can happen, I hope such FAQ will reduce the risk of misunderstanding.

[illwieckz]

This Q/A also addresses the same misunderstanding about compatibility being a performance eater (which is not true), this removes more doubts:

• Q: Is the code running on my GPU contains alternative code paths for every supported hardware?
• A: No, the renderer implements an advanced templating system generating the smallest possible GLSL code for your hardware before the map is loaded. No compatibility branching is executed on the GPU and no superfluous code is stored in VRAM.