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

SSR Reflections fade out very early on non-metallic materials #75302

Closed
WickedInsignia opened this issue Mar 25, 2023 · 9 comments · Fixed by #75368
Closed

SSR Reflections fade out very early on non-metallic materials #75302

WickedInsignia opened this issue Mar 25, 2023 · 9 comments · Fixed by #75368

Comments

@WickedInsignia
Copy link

Godot version

4.0 Stable

System information

Windows 11, Nvidia RTX4070ti, AMD Ryzen7700x

Issue description

Godot's SSR reflections fade out far too early. There is commonly more than enough screen information for a reflection to persist before it fades out into nothing. This might be a conscious choice to reduce visual artifacts, but every SSR implementation I've seen fades out much later and there's no user-facing option to enforce this behavior in Godot.

In this scene the box reflects nicely onto the plane below:

Godot_SSRRangeBug01

However this is reduced entirely while there is still relevant scene information to retain a reflection:

Godot_SSRRangeBug02

In another more complex example:

Godot_SSRRangeBug03

The reflection is gone entirely once the objects casting them reach the top half of the screen:

Godot_SSRRangeBug04

Steps to reproduce

  • Initiate SSR with a large Max Steps count (256 used in the above examples)

Minimal reproduction project

SSRShortRange.zip

@Calinou Calinou changed the title SSR Reflections Fade Out Very Early SSR Reflections fade out very early on non-metallic materials Mar 25, 2023
@Calinou
Copy link
Member

Calinou commented Mar 25, 2023

I can confirm this on 4.0.stable (Linux, GeForce RTX 4090 with NVIDIA 525.89.02).

This appears to be related to how metallic the material is. Materials with high metallic don't exhibit this issue:

Mostly parallel angle

Metallic = 1.0

Screenshot_20230325_023305

Metallic = 0.24

Screenshot_20230325_023259

More perpendicular angle

Metallic = 1.0

Screenshot_20230325_023243

Metallic = 0.24

Screenshot_20230325_023236

@WickedInsignia
Copy link
Author

Ah yeah that's interesting! Didn't notice that.
The opposite seems to occur there: the fade is extremely abrupt with metallic objects, even with adjustments to Fade Out.

@Calinou
Copy link
Member

Calinou commented Mar 25, 2023

The opposite seems to occur there: the fade is extremely abrupt with metallic objects, even with adjustments to Fade Out.

The fade is expected to look more abrupt at the end with highly metallic materials, as the reflection can't be shown offscreen. I'm referring to the intermediate transition here (way before the reflected object reaches the edge of the viewport).

@WickedInsignia
Copy link
Author

Of course, but just something I noticed. The fade-out with non-metallic surfaces is less disruptive visually but also occurs far too early. A setting to adjust this fade when reflection information is reduced might help.

@armanpapikyan
Copy link

armanpapikyan commented Mar 26, 2023

Seems to be caused by the Schlick term, commenting out the 271 line ends up 'fixing' the issue (see screenshots, both non-metallic).

qdjKKK6NSP

I'm taking a look to see what's the proper fix that won't introduce other issues.

@armanpapikyan
Copy link

armanpapikyan commented Mar 27, 2023

After some investigation - the Fresnel equation itself (Schlick approx.) is fine, I double checked with reference, and also compared visually with a couple of other open source implementations (frostbite, substance).

So even tho the math checks out (the fresnel term is responsible for damping down the specular energy 90 degree angles between incident ray and surface normal, while on grazing angles (0 degree) the specular is at its maximum), the effect definitely does not look realistic.

Either way I have a hack that changes the curve a bit, it still keeps the general behavior of max at 0 and min at 90, but the curve itself is less aggressive.
image
(purple is before, red is after).

And here is how it looks in the scene (I added a debug view that splits the screen, left - after, right - before)

GySLQLgtB0.mp4

I tested in other test scenes (like godot-demo-projects\3d\material_testers) and it seems to be working fine and closer to the expected look as mentioned in the thread.

I can open a PR but I'm not sure if this is good enough as its not physically accurate (altho the full BRDF of receiving material isn't implemented for SSR either way).

@Calinou
Copy link
Member

Calinou commented Mar 27, 2023

I think your fix makes sense for now. SSR is eventually planned to get a full rework, so it's expected that we have to make band-aid fixes for the current implementation.

@armmah Remember that for GitHub video previews to work, you need to have a blank line before and after the video URL. I edited your post accordingly, but remember to do this in the future 🙂

@armanpapikyan
Copy link

@MightiestGoat found the proper physically accurate fix #75368 (comment), it also looks nicer on some scenarios, so I'll remove my PR.

@n0tank3sh
Copy link
Contributor

@armmah man you are one of the most humble person I ever met. Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment