Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for linear space rendering in R4 renderer #1576

Open
wants to merge 10 commits into
base: dev
Choose a base branch
from

Conversation

kosumosu
Copy link
Contributor

The game is rendered in gamma space, which is not correct - the lighting is affected by non-linear mapping.
So I added optional linear space rendering. To achieve this:

  • albedo (and maybe some other) textures ar now loaded as *_SRGB format. Technical textures (such as bump, masks, etc) are still loaded as is.
  • main color related back buffers and render targets were also made _SRGB.

@kosumosu
Copy link
Contributor Author

Images For comparison:
Original gamma space rendering:
xrEngine_2023_12_28_21_59_02_272
New linear space rendering:
xrEngine_2023_12_28_22_00_11_799

@kosumosu kosumosu marked this pull request as draft December 28, 2023 21:27
@kosumosu
Copy link
Contributor Author

Forgot that videos in UI also require proper loading as _SRGB.

@kosumosu kosumosu force-pushed the dx11-linear-space-rendering branch from 5b2f3e4 to 20bcaf3 Compare December 28, 2023 21:37
@kosumosu
Copy link
Contributor Author

Forgot that videos in UI also require proper loading as _SRGB.

Fixed this. This required modifying yuv2rgb.ps shader, because texture is loaded as yuv and only converted back to RGB in this shader. The solution is not the most performant, but simple.

@kosumosu kosumosu marked this pull request as ready for review December 29, 2023 20:09
@vTurbine
Copy link
Contributor

vTurbine commented Jan 1, 2024

Thank you for rising this. The fix addresses an important issue, however I don't think it will be enough to solve it.
Assuming that the textures are indeed in non-linear space (are they?), it would be nice to clarify:

  • Original shaders have traces of USE_GAMMA_22 which also affects material lookup. My assumption, that the material LUT was tweaked for non-linear art pipeline and seems need to be changed for linear rendering
  • The same for lights colors
  • The same for layered materials: there is at least one used for terrain chunks. The layers are blended as weighted sum so outcome will produce different look for landscape in cases of linear and gamma-corrected inputs
  • The same for post process effects (CPostProcessColor and CEffectorPP for reference)
  • Haven't check it myself, but the game has CGammaControl which affects dxgi gamma ramp. Does it interfere with implicit gamma correction for srgb back buffer?

Personally, I believe that over almost 20 years players got used to the vanilla game appearance, and it is questionable what benefits the fix can give them. Can be good for some realistic graphic mods though.

@kosumosu
Copy link
Contributor Author

kosumosu commented Jan 3, 2024

Assuming that the textures are indeed in non-linear space (are they?)

Well, diffuse textures are non-linear, because they are displayed uncorrected on sRGB display in the original version. And that is pretty much expected.

  • Original shaders have traces of USE_GAMMA_22 which also affects material lookup. My assumption, that the material LUT was tweaked for non-linear art pipeline and seems need to be changed for linear rendering

I tried enabling USE_GAMMA_22 some time ago. As I remember, it was not behaving as I expected, but I don't remember details.

  • The same for lights colors

I didn't apply correction to light colors, to retain closer to original look. Converting light color to linear space would make lighting brighter in general.
The light falloff appears brighter, though, I didn't adjust curves.

  • The same for layered materials: there is at least one used for terrain chunks. The layers are blended as weighted sum so outcome will produce different look for landscape in cases of linear and gamma-corrected inputs

Blending in linear space should make result little brighter than in gamma space, that's expected. Must be careful to not correct weights though.

  • The same for post process effects (CPostProcessColor and CEffectorPP for reference)

Not familiar with them, but some change in appearance is expected.

  • Haven't check it myself, but the game has CGammaControl which affects dxgi gamma ramp. Does it interfere with implicit gamma correction for srgb back buffer?

I tried it, and it seems works correctly. Adds additional correction.

Personally, I believe that over almost 20 years players got used to the vanilla game appearance, and it is questionable what benefits the fix can give them. Can be good for some realistic graphic mods though.

I wouldn't call this PR a fix, but a new feature. Yes, it's intended for mods, because it will require some additional artistic tweaking. That's why I made it disabled by default. It can be enabled manually from console.

@LVutner
Copy link
Contributor

LVutner commented Jan 4, 2024

Why did you used _SRGB format for rt_Generic* rendertargets?
You (should) do shading in linear space, so what's the point of storing post-combine1 image in SRGB buffer?

@kosumosu
Copy link
Contributor Author

kosumosu commented Jan 4, 2024

Why did you used _SRGB format for rt_Generic* rendertargets? You (should) do shading in linear space, so what's the point of storing post-combine1 image in SRGB buffer?

Making this buffer _SRGB doesn't affect linearity of reads/writes to it through shaders. Because both such reads/writes include mapping srgb->linear and back linear->srgb. What it affects is quantization errors. Without making it _SRGB, I see color banding especially in dark areas.

Couple of examples (with non-vanilla shaders) below. Look closely at dark areas. It's usually more noticeable when you move.

  • no-srgb rt_Generic*:
    xrEngine_2024_01_04_13_10_02_841
    xrEngine_2024_01_04_14_05_07_208

  • srgb rt_Generic*:
    xrEngine_2024_01_04_13_08_41_656
    xrEngine_2024_01_04_14_05_51_324

OneMorePseudoCoder added a commit to OneMorePseudoCoder/OXR_CoC_New that referenced this pull request Feb 21, 2024
-Support usage of multiple spawn_loadout sections in character descriptions (OpenXRay#1590)
-Support for linear space rendering in R4 renderer (OpenXRay#1576)
-Fixed "Naruto run"
-Fog affects npc vision
-Smopth peak
-Landscape render phase (IXRAY)
-Volumetric light optimization (fixed light flickering by Graff46)
-Fixed visual memory manager formula
-Optimazed light renderer (https://github.com/OpenXRay/xray-16/pull/1600/files)
-Fixed HOM cache (dsh2dsh)
-Fixed CKinematics::LL_SetBoneVisible (Anomaly)
OneMorePseudoCoder added a commit to OneMorePseudoCoder/OXR_CoC_New that referenced this pull request Feb 22, 2024
-Support usage of multiple spawn_loadout sections in character descriptions (OpenXRay#1590)
-Support for linear space rendering in R4 renderer (OpenXRay#1576)
-Fixed "Naruto run"
-Fog affects npc vision
-Smopth peak
-Landscape render phase (IXRAY)
-Volumetric light optimization (fixed light flickering by Graff46)
-Fixed visual memory manager formula
-Optimazed light renderer (https://github.com/OpenXRay/xray-16/pull/1600/files)
-Fixed HOM cache (dsh2dsh)
-Fixed CKinematics::LL_SetBoneVisible (Anomaly)
@Xottab-DUTY Xottab-DUTY force-pushed the dev branch 2 times, most recently from 5b2ec76 to 6fffce9 Compare May 4, 2024 03:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: To do
Development

Successfully merging this pull request may close these issues.

4 participants