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.
What r_gamma value do you use?
-
killing time
- Programmer
- Posts: 150
- Joined: Wed Jul 04, 2012 7:55 am UTC
Re: What r_gamma value do you use?
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.
Re: What r_gamma value do you use?
killing time wrote: ↑Sun Apr 30, 2023 6:36 am UTCI 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.
Yes
So we would need to do the transformations every time stuff goes in or out of a framebuffer to preserve our precious precision.
But if we do OpenGL Blending framebuffers have to contain the linear values.
Edit:
It looks like we don't call glBlendFuncSeparate neither require ARB_draw_buffers_blend, in fact our engine supports hardware that are way older than that, so maybe we don't do OpenGL blending. If we do everything in GLSL I wonder if we can write the code in a way all GLSL fp is in sRGB in input and output…
This comment is licensed under cc by 4 and antecedent.
Re: What r_gamma value do you use?
FWIW I gave a try to the maps illwieckz recently updated, and with my monitor brightness set to minimal, I could play with gamma at 1.0. Monitor brightness being at minimal was to test in rather extreme conditions, so they should now be ok.
Sadly, it's still around 15 maps over 300+ so I'll keep my 1.2 settings which works with my usual overbright main screen.
Re: What r_gamma value do you use?
Yeah, that goodness comes from non-short light falloff and intense light bouncing. At least if the light blending is not physically correct, the light diffusion in space is more physically correct.
See Please compile your maps without -fast but with -fastbounce thread for details about this.
This comment is licensed under cc by 4 and antecedent.
