Screenshots do not reflect the screen

Support for running, installing or compiling OpenMW

Before you submit a bug report for the first time, please read: Bug reporting guidelines
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Screenshots do not reflect the screen

Post by AnyOldName3 »

It's more than just tweaking the lighting values as I'm sure there are going to be places where textures include workarounds for the bad lighting system. If it was just a case of tweaking some numbers, I'm sure someone would have a branch/fork where textures are loaded with the GL_SRGB8 or GL_SRGB8_ALPHA8 (or DXT equivalent) flag and GL_FRAMEBUFFER_SRGB is enabled.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Screenshots do not reflect the screen

Post by Chris »

AnyOldName3 wrote: 18 May 2018, 00:25 It's more than just tweaking the lighting values as I'm sure there are going to be places where textures include workarounds for the bad lighting system. If it was just a case of tweaking some numbers, I'm sure someone would have a branch/fork where textures are loaded with the GL_SRGB8 or GL_SRGB8_ALPHA8 (or DXT equivalent) flag and GL_FRAMEBUFFER_SRGB is enabled.
Using GL_SRGB8 or GL_SRGB8_ALPHA8 (or DXT equivalent) for textures, and GL_FRAMEBUFFER_SRGB for the render target, creates a pass-through effect on the textures. The SRGB texture format tells OpenGL to treat the texture as SRGB-encoded (i.e. decodes them from SRGB for fragment processing), and the GL_FRAMEBUFFER_SRGB framebuffer flag tells OpenGL the framebuffer needs to be encoded for SRGB output. These two operations are the inverse of each other; they cancel each other out in the same way that not correcting for the SRGB texture image and not encoding for the SRGB output cancel out.

The difference comes from the dynamic lighting applied in between those two stages. This is where the light value tweaks need to come in and you can get more correct light ramps. It's unlikely that textures will include workarounds for the original dynamic lighting since it's dynamic; it won't always be there the same way on every instance of the texture. Any prebaked lighting the textures do have will come through as-is, but there's never a guarantee for what exactly it will look like with dynamic light applied on top of it, because it's dynamic.

I can agree that, ultimately, the texturing would need to be redone for best results. Proper PBR materials that remove all prebaked lighting, AO, specular, and reflections from diffuse textures, so they can be applied in real-time by the engine, would further improve the graphical fidelity. However, simply getting gamma-correct lighting ramps would also be an improvement.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Screenshots do not reflect the screen

Post by AnyOldName3 »

they cancel each other out in the same way that not correcting for the SRGB texture image and not encoding for the SRGB output cancel out.
That's not entirely true. Any maths that happens in between (i.e. literally all the maths) has an effect. If you don't linearise the texture, when we sum the contributions of multiple light sources, that's not a valid thing to do. It's analogous to adding the squares of two numbers and taking the square root giving a different result to just adding the numbers.
User avatar
ladyonthemoon
Posts: 34
Joined: 13 May 2018, 13:24

Re: Screenshots do not reflect the screen

Post by ladyonthemoon »

Wow, you people seem very knowledgeable about that stuff. So, basically, I have no reason to worry about what my screen shots look like? :)
Post Reply