bug

Light intensity coefficient Bug fix before Bug fix after
0.01
0.02
0.03
0.04
0.05
0.1

Before seeing the above figure, it was found that the modified parameters were not linear, so it was necessary to check whether the enhancement was made in Gama space or linear space.

Code before and after bug fixes

Fix before

color = srgb_to_linear(al.color * lightFactor)) if lightGamma else al.color * lightFactor) //lightFactor is the 0.01 parameter
Copy the code

Fix after

color = (srgb_to_linear(al.color) if lightGamma else al.color) * lightFactor)//lightFactor is the 0.01 parameter
Copy the code

Description of linear space Gama space

The reason for these three Spaces is that the CRT monitor corrected the image to gamma 2.2 (power 2.2) and later LCD monitors did the same for compatibility (power 2.2), 2.2 is the inverse of 0.45, which cancels out to the original image (color ^ 0.45 ^ 2.2 = color ^ 1), so most images are corrected to the power of 0.45 and will be displayed to the power of 2.2.

(color * 0.01) ^ 2.2 = 0.01 ^ 2.2 * color ^ 2.2 = 0.01 * color ^ 2.2

Therefore, 0.01 ^ 2.2 is far less than 0.01, so it is very dark before seeing Fix, and it brightens nonlinearly.

Impact on game development

PBR calculation is all in linear space, so if the art drawing is in 0.45gama space, it should be converted to linear space by power 2.2 first, and then returned to sRGB (0.45 Gama space) after calculation, and then the display will do power 2.2 calculation to display the color of linear space. So pay special attention to the fact that basically the computation is in the linear space. When you are working out the workflow, look at what space is the art drawing in sRGB or linear space

Personal Profile: Senior Development Engineer, interests and fields (Unity, Unreal, Cocos Creator, Android Terminal development, ios Terminal development, audio and video development, graphics), welcome to add W: WLxKlyh to discuss questions. (Welcome star: github.com/wlxklyh/Sof…