Hi,
I’m encountering an issue that is making lumen reflections really hard to use with normal maps. It appears that the if the normals don’t match the scene depth the reflections start sampling bad data leading to a lot of artifacts.
See the video attached.
Hello,
Thank you for reaching out.
I’ve been assigned this issue, and we will be looking into these reflection artifacts for you.
Can you please send us a minimal test project that demonstrates these reflection artifacts?
The guide for test projects:
[Content removed]
Hi Stephen,
Unfortunately I won’t have time to create an test project.
You can replicate the issue pretty easily though.
Just create this material and assign it to the floor in a new level in any project.
[Image Removed]
Then just scrub the G value.
[Image Removed]
it will generate these artifacts
[Image Removed]
Hello,
By default, Lumen has a threshold for the delta between the HZB trace hit and the previous scene depth to consider a hit for screen traces. This bias can be controlled by the CVar “r.Lumen.Reflections.HierarchicalScreenTraces.HistoryDepthTestRelativeThickness”.
You can try setting this CVar to 0 to remove the artifacts.
Please let us know if this helps.
[mention removed] I tried this cvar and saw no change. Are you able to confirm whether or not this cvar has any affect on the artifacts on your end?
I still get an unusable result with any normal manipulation.
Look at this awful ghosting
[Image Removed]
Do lumen reflections just not support normal maps?
It feels like there is a missing piece to lumen reflections. It needs some sort of fallback cube map to render when it doesn’t have what it needs to render usable reflections
[Image Removed]
Manipulating the depth information before calculating the reflections will also dramatically reduce the instances where bad information is returned.
[Image Removed] Also, translucent materials don’t have this issue, most likely because they have to be forward shaded to render reflections
[Image Removed]
Hello,
Lumen does fall back to tracing the skylight when it does not hit a surface during screen or world traces.
In our tests, the black areas were successful traces, hitting areas nearer to the camera than the origin of the trace. This results in no valid reflection data, as the skylight is blocked. The trace is behaving as expected, following the direction supplied by the Material’s normals.
[Image Removed]
You can visualize Lumen’s reflection traces with the CVar “r.Lumen.Reflections.VisualizeTraces 1”
Lumen does fully support per-pixel normal maps. Please refer to the many example and showcase projects that show how to use Lumen, including with normal maps. For example: City Sample, Electric Dreams, Hillside Sample, and the others.
What effect are you trying to achieve? We might be able to provide a different approach that does not lead to reflection issues.
Hi Stephen,
Are you able to provide a specific example of an Opaque surface that uses Raytraced Reflections has Zero Roughness and uses a Strong Normal Map to manipulate it’s normal data?
Imagine a normal map like you might use on a river to make it look like flowing water.
I have not been able to find anything like that in any of the example content provided.
I’ve only found the following examples.
A lot of normal maps can appear to be working fine at a glance but break down as soon as you look closely.
Here is an example material that meets the criteria above that I have created in the Electric Dreams demo.
[Image Removed]
[Image Removed]
See also the video attached
I feel pretty strongly that this is a bug that needs to be fixed. There is no content solution for this issue as far as I can see.
Even when you can’t see this artifact clearly, it makes reflective surfaces with normal maps look noisy and creates poor image quality.
Hello,
I put together a simple test with a rough normal map and was able to get it to reflect a bright object as reference on the normals from a plane.
[Image Removed]
Based on your test-case in Electric Dreams, can you try reproducing this in a Substrate disabled project as well?
I was also not seeing the noisy issue in the reflective surface I have even if I attach a flat normal which in your case is the plane surrounding the engraving parts.
[Image Removed]Can you try a similar setup in your case to try to compare visuals?
I used the T_Base_Tile_Normal texture that is included in Engine content.
Also for debugging, you can visualize the buffer that stores the direction for the reflection rays with the command “vis Lumen.Reflections.ReflectionRayBuffer”.
[mention removed] The artifact I’m describing is clearly visible in the image you sent.
[Image Removed]
Nothing in your scene would explain why you are getting these reflections that look like holes in the surface. This is clearly an error in the reflection result.
If you zoom in on this area, from this angle you will see ugly ghosting artifacts as shown in my examples above.
Even in the image you sent, if you zoom in on your image you can see the onion skinning smear, typical of temporal ghosting from bad frame data.
[Image Removed]
My original tests are not using substrate. My later test is showing it is still an issue with substrate and the most recent builds of unreal. Also, that it shows up in standard workflows as shown in your example image.
Is there someone with a rendering background this issue can be escalated to?
I feel I’ve pretty thoroughly proven the issue at this point and we appear to be going round in circles here.
The sorts of ghosting issues we are seeing here are not acceptable and if epic has no plans to fix it we will have to look at our own solutions for this issue.
[Image Removed]
[mention removed] Sorry, that last message came across a bit harsh. Thanks for taking the time to look at this and it seems like this is a bit more of a tricky thing to communicate that it appeared at first.
Just feeling a bit of frustration at failing to communicate what appears to be a fairly straight forward issue to reproduce on my end.
I guess I’m not sure why these ugly black artifacts and ghosting issues are not jumping out as a major problem for other people or why there doesn’t appear to be a desire to get them fixed.
The fix seems pretty straight forward to me. I’d just like to be able to make water surfaces that are opaque. Due to the issues described above, I have not been able to get an acceptable result with raytraced reflections without some ugly hacks. Basically I have to mask out the bad reflections using math to change the normal direction when it would lead to a bad reflection result.
I’m really just looking for acknowledgement of the issue and a timeline for a fix. I don’t really understand how raytraced reflections can be said to fully support normal maps when they produce such ugly artifacts when you use normal maps with them.
Hello,
Thank you for your patience as we work through this with you.
We have a better understanding of the issue now, and will create a bug report.
When we have a public tracker, we will post it here for you to track the issue.
All good, thanks [mention removed] !
Hello,
Thank you for reporting this. We have opened a bug report:
The tracker will be visible after it is approved internally at Epic Games and is publicly accessible.
If you have any further questions, please let us know.