renderer: implement native sRGB support

[illwieckz]

Implement native sRGB support.

Obsoletes #1543:

• WIP: implement colorspace support (sRGB, etc.) #1543

It includes the commit from #1686:

• tr_shader: fix “flags & RSF_2D” #1686

This is based on an even older branch from 2019 as I initially tested native sRGB support before attempting to implement it in GLSL.

I rebased on current master and merged improvements from the srgb-naive branch as it implemented more corner cases than this one.

It still suffers from the problems I faced in 2019: 2D colors are wrong. I need help on that part.

---

Status:

color source	conversion implemented	when is converted	how is converted
color map	✅️	sampling	metadata
diffuse map	✅️	sampling	metadata
glow map	✅️	sampling	metadata
specular map	✅️	sampling	metadata
animMap	✅️	sampling	metadata
skybox	✅️	sampling	metadata
light map	✅️	sampling	metadata
light grid	✅️	loading	conversion
map tris vertex color	✅️	loading	conversion
map patch vertex color	✅️	loading	conversion
expression_t	✅️	uploading	conversion
CGEN_CONST	✅️	uploading	conversion
CGEN_WAVEFORM	✅️	uploading	conversion
CGEN_ENTITY	✅️	uploading	conversion
CGEN_ONE_MINUS_ENTITY	✅️	uploading	conversion
polyVert_t::modulate	✅️	uploading	conversion

[illwieckz]

Hmmm… I don't know where to write the line glEnable( GL_FRAMEBUFFER_SRGB );, should it be called at the beginning of every frame?

Edit: Nowhere, it should not be used in our case.

[VReaperV]

Hmmm… I don't know where to write the line glEnable( GL_FRAMEBUFFER_SRGB );, should it be called at the beginning of every frame?.

You only really need to call it once, it's global state and will affect all sRGB framebuffers.

[illwieckz]

Which framebuffer should be sRGB there?

[illwieckz]

As a matter of fact, I have zero confidence this implementation is correct, unlike the GLSL alternative implementation.
I expect this to be wrong because I lack some understanding of how sRGB stuff are done the OpenGL way.

Said otherway, I know how to implement the whole computation myself in GLSL, but I don't know how to configure OpenGL to let it do the computation by itself without me writing the explicit computation.

The GLSL implementation is a math algorithm, the OpenGL implementation is a puzzle.

[illwieckz]

@VReaperV what is expected if I, for example, set upload an image with GL_SRGB format instead of GL_RGB but do glDisable( GL_FRAMEBUFFER_SRGB )?

[illwieckz]

what is expected if I, for example, set upload an image with GL_SRGB format instead of GL_RGB but do glDisable( GL_FRAMEBUFFER_SRGB )?

The question is now likely irrelevant.

[illwieckz]

It now works with both maps built with and without the -sRGB q3map2 compiler option.

But you have to disable the tone mapper when running maps compiled with -sRGB, otherwise that looks very surreal.

I don't know anything about the tone mapper so I don't know if something is wrong.

Right now the camera post-process GLSL shader doesn't run in linear space because colorgrades were done for the non-linear space.

[illwieckz]

The 2D rendering is done like before, as @slipher suggested:

We should probably stick with naive blending for the 2D rendering since that's what HTML/CSS do.
-- Unvanquished/Unvanquished#3390 (comment)

Actually it makes many things far easier, especially it doesn't require to know how the map should be rendered to render the UI, and it means the UI isn't affected by what's done there.

[slipher]

Wait, why would we even want GL_FRAMEBUFFER_SRGB? I don't think it can do anything useful for us. Apparently it is only useful for converting from colors linear to sRGB at a final stage of rendering, as described here. In principle, this is something we need to do at the point of the cameraEffects shader. But our current color grade and tonemap operations are designed for sRGB inputs. So it would work a lot more smoothly if we convert the colors from from linear space ourselves in cameraEffects before feeding them into color grades and tonemapping.

I wonder why GL_FRAMEBUFFER_SRGB would have any effect in the current version of the code though. Supposedly you have to create the framebuffer with an SRGB format for it to have an effect but the code does not appear to do that.

[illwieckz]

What I understood (but maybe I'm wrong), is that once GL_FRAMEBUFFER_SRGB is enabled, any subsequent framebuffer operation will assume any input and output is in sRGB and will convert them before and after processing (and also converting framebuffers back and forth when blending). I'm not saying this is truth, but I read in various places something that seemed to mean that, and it looks like doing things that way makes it work (I also read things that meant totally different things, but that seemed wrong).

Maybe we also need to set sRGB on framebuffers, maybe that's required for blending. I don't know, everyone is saying something different on the Internet.

[illwieckz]

Also, something I've read (but I may be wrong) is that sRGB variants only exist for 8-bit formats, and some of our framebuffers are 16-bit… I don't know what to do with that information.

[slipher]

I found various people complaining of buggy handling of the framebuffer SRGB stuff. Like Nvidia applies it even when the framebuffer was not created as sRGB, or that Intel doesn't do it at all... another reason not to use it.

Some more random considerations:

• Vertex colors of models are another thing that theoretically probably needs to be converted. Not sure if we actually have any models that use those.
• Vertex colors of (3D) polygons too? OTOH we could just say that is the responsibility of the caller to use a linear space.
• I guess the 2D vs. 3D shader registration flag stuff will become important now (since you only want sRGB-to-linear conversion when reading the latter) and probably uncover some bugs.

[illwieckz]

Hmm, comparing a Xonotic map like afterslime on Dæmon and Darkplaces reveals there is still something wrong.

[illwieckz]

We may face vertex lighting bugs unrelated to that branch, to begin with.

Or the function converting the color doesn't modify the input.

This is what is happening, Color::Color is const.

[illwieckz]

With latest patch,

lightmap:

grid light:

vertex light:

station15:

vega:

Now the plants fit in their environment, and the computer does look dark because it is dark, not because of shadows.

[illwieckz]

So, it looks like everything is now ready.

[illwieckz]

So I believe all we had to care about is now taken care.

[illwieckz]

We need a way to disable rim lighting when the linear pipeline is used. But we don't need to implement that to merge this branch. What we need is to implement this swithc before releasing.

[illwieckz]

We need a way to disable rim lighting when the linear pipeline is used. But we don't need to implement that to merge this branch. What we need is to implement this swithc before releasing.

Well, it's only bad to mix linear pipeline + rim lighting + reflection mapping.

[slipher]

I made some comments a couple days ago but apparently they didn't go through.

[slipher]

I interpreted that preset disable bloom thing as you saying that it would ruin sRGB-aware maps, lol. Anyway if you think bloom looks fine in the linear space (I haven't tested), just get rid of this part. I like to use it as-is so the software should get out the way and let me choose my own settings.

[slipher]

I guess this should be called EXP_CLAMP since that's what it does. It clamps, not normalizes.

[illwieckz]

I made some comments a couple days ago but apparently they didn't go through.

Now taken care of.

[slipher]

LGTM

Some non-blocking comments:

• The atcshd fog is way too bright. But I'm not sure if that should be fixed engine-side or by changing parameters in the map.
• Some dynamic lights are too dim, but we probably need to redo everything with dynamic lights anyway (Realtime light attenuation and colorspace #1703).
• Grid lighting of models seems a bit too dim to me.

[slipher]

I believe this sentence in a commit message is outdated:

Video frame conversion is excluded from the scope of this commit,
it should be implemented later

[illwieckz]

I believe this sentence in a commit message is outdated:

Video frame conversion is excluded from the scope of this commit,
it should be implemented later

Ah yes, now fixed.

[illwieckz]

The atcshd fog is way too bright. But I'm not sure if that should be fixed engine-side or by changing parameters in the map.

It's probably something similar to blended stuff. Taking care of a migration path for existing assets to the new pipeline would have to be taken care in future efforts.

[illwieckz]

Many thanks to all who reviewed that in one way or another! ❤️