r_forceBlendRegime to load legacy lightmaps in linear space or vice versa

[slipher]

Allow loading maps with sRGB lightmaps with naive blending, or maps with non-sRGB lightmaps with linear blending. Use r_forceBlendRegime 1 for naive blending or r_forceBlendRegime 2 for linear blending.

TODO: models and vertex lighting. Out of precomputed lighting, just lightmaps work so far.

From some examples you can see that non-blended surfaces look similar between blend modes. Use of multi-texturing features like normal and specular increases the difference. But even non-blended, non-lit surfaces like the skybox can still have visible differences because texture filtering produces different results when the image is flagged as sRGB.

All screenshots are made with tonemapping disabled.

Non-sRGB lightmaps, naive blending:

Non-sRGB lightmaps, linear blending (new!):

sRGB lightmaps, linear blending:

sRGB lightmaps, naive blending (new!):

[illwieckz]

It would be good to have this merged, I think we can use r_forceBlendRegime 1 as acceptable approximation for low presets.

One funny thing is that I discovered that what Darkplaces/Xonotic does with sRGB stuff is in fact r_forceBlendRegime 1. Darkplaces has a fully linear mode but it's not used yet and not finished (the UI is wrongly affected).

From some examples you can see that non-blended surfaces look similar between blend modes.

That's the reason that has been given to me for why Darkplaces/Xonotic hasn't jumped yet into the fully linear thing.

Use of multi-texturing features like normal and specular increases the difference.

Meaning in low presets the difference is lower.

So using r_forceBlendRegime 1 in low presets would actually avoid conversions with differences being less ugly than things we already do in low presets, like r_highPrecisionRendering off.

[slipher]

I was trying to finish this up a few weeks ago but got stuck being unable to figure out why vertex lighting is wrong.

I think we can use r_forceBlendRegime 1 as acceptable approximation for low presets.

Interesting, I hadn't though of that. That would avoid some precision losses from srgb -> linear -> srgb round trips with the 8-bit buffer.

One funny thing is that I discovered that what Darkplaces/Xonotic does with sRGB stuff is in fact r_forceBlendRegime 1.

I had suspected/wondered about that! Mostly just because it's an old game / engine. I wanted to test but after looking through several maps I failed to find any translucent surfaces, except some skybox-facing windows which were too close to being fully transparent to make a good test.

[illwieckz]

I think we can use r_forceBlendRegime 1 as acceptable approximation for low presets.

Interesting, I hadn't though of that. That would avoid some precision losses from srgb -> linear -> srgb round trips with the 8-bit buffer.

Yes, it would even be better to do r_forceBlendRegime 1 when we already do r_highPrecisionRendering off.

Anyway, isn't forcing the linear mode (r_forceBlendRegime 1) just forcing worldLinearizeTexture = false and worldLinearizeLightmap = false?

[slipher]

Anyway, isn't forcing the linear mode (r_forceBlendRegime 1) just forcing worldLinearizeTexture = false and worldLinearizeLightmap = false?

Well, if the map was made with the expectation of applying a light factor of 4 in linear space, then to get a close results working with sRGB you should multiply by 4^(1/2.2) ~= 1.88 in naive mode. And vice versa with 4^2.2. That's the other part of my changes so far.