What r_gamma value do you use?

Talk about anything related to Unvanquished.
User avatar
illwieckz
Project Head
Posts: 718
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

What r_gamma value do you use?

Post by illwieckz »

By seeing some people screenshot I notice some people increases r_gamma.

So I have a question, what r_gamma value do use? Myself use the default one: 1, and you?

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
Tom
Dragoon
Posts: 253
Joined: Tue Jan 15, 2013 3:34 pm UTC
Location: France

Re: What r_gamma value do you use?

Post by Tom »

Default too for me.

User avatar
cu-kai
Web Crew
Posts: 63
Joined: Fri Jan 02, 2015 1:29 am UTC
Clan: CU

Re: What r_gamma value do you use?

Post by cu-kai »

Regularly using between 1.4 and 2 depending on the map / environment.

Web Raccoon

User avatar
killing time
Programmer
Posts: 162
Joined: Wed Jul 04, 2012 7:55 am UTC

Re: What r_gamma value do you use?

Post by killing time »

1 for Unvanquished official maps
1.8 for a lot of Trem maps

User avatar
illwieckz
Project Head
Posts: 718
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: What r_gamma value do you use?

Post by illwieckz »

Well, in fact in a perfect world r_gamma should always be 1.

But we don't live in a perfect world and all idtech3 engines and content since 20 years uses broken light computation. Well, almost all games had broken lighting computation since for 20 or 30 years.

Actually the motivation of my question was to know how much people were trying to workaround that broken light computation.

The exact r_gamma value to workaround that broken lighting computation the best way modifying gamma can do is 2.2. But this would only fixes the lighting, and breaks the textures, because a conversion very similar to gamma 2.2 are already applied on textures. Textures are already converted with gamma 2.2 when distributed so applying gamma 2.2 with do it twice and break them.

It means setting gamma 2.2 in game fixes the lighting but applies a second gamma 2.2 application on textures and then breaks the textures, that's why colors are washed out when increasing the gamma, because gamma is applied twice on texture Also the light computation can't be correct because one should not multiply an image that was modified with gamma 2.2 with another image (modified or not) and expect a correct result.

I'm investigating the implementation of giving the ability to produce new maps for the game that will use physically correct light computation, but if I apply the physically correct computation to existing maps, that will break them, because mappers actually designed and tested their maps by looking at them with a broken renderer and so they implemented workarounds to make them somewhat mimicking reality by trying to revert the renderer misconception. Yet again, doing proper computation with legacy maps is expected to apply a fix on a workaround, and then it's like applying two times the fix and then breaking things.

The fact people actually change gamma between maps is just the result of this: some maps received workarounds by the mappers, others didn't.

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
illwieckz
Project Head
Posts: 718
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: What r_gamma value do you use?

Post by illwieckz »

Note that what I say about broken computation is not specific to idtech3, even not specific to gaming. The web is broken too. Image editors may also be broken.

For example one can read this interesting article: blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma

We can read those words:

Almost everybody does this the wrong way: CSS gradients and transitions are wrong (see this thread for details), Photoshop is wrong (as of version CS6) and there’s not even an option to fix it.

Some random people claimed on the Adobe forums that by doing this Photoshop is really mimicking how mixing paints would work in real life. Well, no, it has nothing to do with that. It’s just the result of naive programming to work directly on the sRGB pixel data and now we’re stuck with that as the default legacy behaviour.

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
killing time
Programmer
Posts: 162
Joined: Wed Jul 04, 2012 7:55 am UTC

Re: What r_gamma value do you use?

Post by killing time »

illwieckz wrote: Sun Apr 30, 2023 12:49 am UTC

For example one can read this interesting article: blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma

Good article, thanks for sharing.

illwieckz wrote: Sun Apr 30, 2023 12:44 am UTC

The exact r_gamma value to workaround that broken lighting computation the best way modifying gamma can do is 2.2. But this would only fixes the lighting, and breaks the textures, because a conversion very similar to gamma 2.2 are already applied on textures. Textures are already converted with gamma 2.2 when distributed so applying gamma 2.2 with do it twice and break them.

I think you are right that r_gamma 2.2 is the correct way to ensure that the linear-space lightmap calculations are displayed correctly. (Well, almost: it's a simple pow function, not the full sRGB formula.) r_gamma is an inverse gamma, so the monitor's gamma curve will cancel it out, resulting in a linear display, as desired by lighting calculations. Whereas the problem with textures is that using r_gamma cancels out the sRGB curve which (maybe) was expected to be used. With r_gamma 2.2 texture color ends up being treated as a roughly linear space.

It's normal and good for textures to be stored with sRGB as this is what most image viewers expect, and it allows more dynamic range. What we can do is add a q3shader property to specify which gamma curve to use for the texture. Maybe also there should be a per-map option to specify the default for this. Then if we knew that a certain mapper used gamma 1.5 when developing, we could make it look as intended by setting the map-wide option. Anyway, the q3shader property would be passed as a glsl uniform when rendering the texture. The glsl shader would apply the inverse gamma curve to remap the texture data from logarithmic space to linear space so that it can be used in lighting calculations.

The prospects for achieving an sRGB-compliant but backward-compatible engine actually seem pretty good. The main thing that would need to be managed is getting textures labeled with the correct brightness curve to use. Also we should make the gamma shader implement the full sRGB function, with the linear section for the dark part.

q3map2 is another thing that could use improvement, to produce sRGB output instead of linear. But for the moment we can just keep a suitable default curve for the old outputs.

P.S. I'm doing an OpenGL online course right now and there is no mention of this topic :'(

User avatar
illwieckz
Project Head
Posts: 718
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: What r_gamma value do you use?

Post by illwieckz »

Yeah, basically we should linearize textures in input, do all computations, the delinearize in output.

Problem? It adds a lot of color banding because we convert 8bits images and 8bits is only good for displaying images, not really to transform them.

I have a branch that does that (with correct sRGB formulas) but it adds a lot of banding. I get less banding if I just do the linearization/delinearization in a single GLSL shader like lightMapping GLSL, but our engine supports stage blending so we should linearize in input and delinearize in output.

This comment is licensed under cc ​​by 4 and antecedent.

User avatar
killing time
Programmer
Posts: 162
Joined: Wed Jul 04, 2012 7:55 am UTC

Re: What r_gamma value do you use?

Post by killing time »

I guess there might be a problem with intermediate framebuffers. I assume all framebuffers have 8-bit position. The actual calculations in GLSL are floating-point so we should be fine, but stuff goes in and out of different framebuffers a number of times before going to the final output buffer. So we would need to do the transformations every time stuff goes in or out of a framebuffer to preserve our precious precision.

User avatar
illwieckz
Project Head
Posts: 718
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: What r_gamma value do you use?

Post by illwieckz »

My work-in-progress branch is there:

Right now I do sRGB (from and to) conversions in GLSL because it's easier to do prototyping this way. There exists some OpenGL sRGB framebuffer/image format but then the implementation requires to understand how image and framebuffer are done and interact in the engine, so for now I do it the GLSL way. Also doing it the GLSL way would be backward compatible with all drivers and GPUs, so I only want to consider native OpenGL features once the GLSL implementation works.

To test the feature, one can change tr.worldPhysicalLight = false; to true in tr_bsp.cpp. My idea is that the engine would automatically enable the correct computation if the mapper sets a key named like physicalLight in the worldspawn entity. So the mapper would set the key, and since the engine would always render things correctly, the mapper would do the lighting with a correct rendering as a feedback, and the player would get the same as the mapper.

The branch is a bit noisy because since I implemented sRGB conversions I also tried to implement the sRGB lightmaps used by Xonotic, sRGB lightmaps makes no sense in a perfect mathematical world, but I believe Xonotic does that to bias the storage of lightmaps to reserve some precisions to values they prefer (probably dark ones to avoid color banding in low lights), but it looks like converting lightmap back from sRGB to linear is not enough… That's another topic, this one is not about physical correctness but about a storage trick. The computations should be linear in all cases.

On map compiler side, there are already options (-sRGBtex) a mapper can use to delinearize textures when lightmapping.

This comment is licensed under cc ​​by 4 and antecedent.

Post Reply