Yes, it’s a known bug and is still awaiting a fix. Nanite ray tracing generates wrong geometry normals, which then break surface cache sampling.
1 Like
I assume you mean short range AO which is added on top of GI, and not bent normal from the material output? In that case take a look at r.Lumen.ScreenProbeGather.ShortRangeAO.* CVars, specifically:
- r.Lumen.ScreenProbeGather.ShortRangeAO.MaxMultibounceAlbedo
- r.Lumen.ScreenProbeGather.ShortRangeAO.ScreenSpace.FoliageOcclusionStrength
Where foliage means pixels with a Two Sided Foliage or Subsurface shading models.
2 Likes
Maybe something with r.Lumen.Reflections.SampleSceneColorNormalTreshold, which is designed to prevent to sample wrong side of the mesh.
This hit skip is only active for GI and can be toggled with r.Lumen.ScreenProbeGather.ScreenTraces.HZBTraversal.SkipFoliageHits. If a hit is skipped then it will be continued using world space traces. The idea here is that two sided DF are dithered to they should leak light and make foliage occlude less.
Anything set per mesh or material would require to add a bit to GBuffer and GBuffer space is at premium, so unlikely to happen unless it’s undoubtedly a critical and must have feature to ship.
We could do some kind of skips based on data which is already there, like shading model. For this we need just need to figure out a common need, so that we add something that is useful for most people.
2 Likes
Maybe a stupid question but is there any chance this will become more flexible with Strata? Since it replaces the existing fixed shading models with more modular bits.
Hopefully not a stupid question because I immediately had the same though.
But at the very least it sounds like it could be done with a custom shading model if needed.
That makes good sense.
Its kind of hard for me to generalize the cases, but I’d say it’s typically at its worst when the screen tracing causes significant visual discontinuities between the ray trace and the screen trace. This is usually due to a difference in how the surface and/or hit lighting is drawing an object vs it’s lit view (and thus its resulting screen traces).
You can see an example of this with the foliage on my last post, where the hit lighting presumably doesn’t evaluate the light transmission and the raytraced leaves are much darker than the screen-traced leaves.
In that example, the screen trace is more believable to my eye, but the discontinuities as you transition between them are the real issue.
Similar problems happen with other materials, for example when using distance fields in the shader. Some of these I hope and expect will be solved as other parts of Lumen are improved.
Materials whose Lumen reflection view representation are a close match to the lit view look great and the transition to screen traces are near invisible.
And all said and done, these discontinuities are still better than the old way of doing things like with SSR and probes.
I’ll test out the threshold setting and post results later tonight.
1 Like
RT nanite enabled
RT nanite disabled.
I see what you mean, this is a mess. It’ll be good to have this fixed, but I very well understand the problem is non-trivial. Dynamically constructing and managing BLAS/TLASes while maintaining a memory budget and constant streaming seems like an incredible undertaking, I am very impressed.
It does seem that each mesh rasterizes a bit differently as the setting is enabled/disabled, and meshes aren’t universally correct or incorrect. It’s very, very strange.
Gave it a spin and it doesn’t appear to be effected by this setting. Here it is at 200, which has an obvious effect on the trace, but the dilated pixels are still visible. It’s still visible at 0 as well. Default was 85.
Interestingly, unlike the normal threshold setting, it actually extends outside the mesh itself.
It also seemingly fades out the closer the camera vector is to the surface tangent, and gets stronger the closer you are to the normal.
Coming back to this, I noticed something interesting today: Lumen appears to ignore emissive translucency for screen traces, except when TSR is set as the antialiasing method.
I’m not sure if this is a bug (and if so… which is bugged? Lumen? TSR? TAA/FXAA? No clue what the intended behavior is), but might be helpful in your case. Recorded here in 5.2 preview, but I also tested in 5.1.1 and confirmed the same behavior.
1 Like
Not sure if you have a better solution in the works but would you guys consider adding a Lumen Screen Traces toggle (for GI traces specifically) to the Post Process Volume settings?
I saw in 5.1 that you added the ability for hidden meshes to affect indirect lighting, but this really doesn’t work unless you disable screen traces. It would be nice to be able to regionally disable screen traces through the post process volume so that you could disable them only in areas that are relying on light from hidden emissives.
I imagine hard booleans in the post process volume aren’t particularly desirable since they can’t smoothly transition, but I find the switch often isn’t that noticeable (or at least isn’t any worse than an LOD pop)
1 Like
Hi, I’m using Lumen for reflection method,
is it possible to correctly reflect any reflected outcome like HDRI or sky or clouds from other materials?
thanks in advance
1 Like
Not exactly the same, but this thread talks about altering the appearance of reflected objects within reflections. It should also be applicable to windows. The basic idea is to use a raytracing quality switch or custom node to alter the appearance of materials when they are drawn in reflections.
1 Like
Hi, thanks for the reply,
Ray Tracing Performance Guide in Unreal Engine | Unreal Engine 5.0 Documentation
I’ve searched and tried to learn about the method on the documents,
but all the results were only applied on the surface instead of the reflections…
though the result was not what I am looking for,
the link in your post is really helpful,
I think I’ll just wait and see how it will look like in 5.3 :]
1 Like
+1…
I want to know how to achieve glass to reflect other glass materials normally, instead of being black or invisible. This is necessary in architectural visualization
1 Like
Hey guys, anyone here knows a console command or a set of commands to execute to force update over all of existing lumen cache in scene?
I’m experimenting with lumen in VR but shutting down lights will leave all kinds of residual lightin unless the player moves around a bit. It would be nice to be able to force some restart after lights are shut off.
1 Like
Maybe disabling the cache and enabling it again? I don’t remember the cvar, but something like searchin for Lumen + cache.
There was some cvars related to lumen + reset or force, or update, which may fit your needs. Let’s me know!
2 Likes
Unfortunately, I tried 5.3, which is only effective for non semi transparent objects that are reflected, and semi transparent objects still cannot appear in the reflections of other semi transparent objects
1 Like
What is your hardware?
I am very disappointed by the latest build of Lumen reflections 5.2. I don’t think I have seen Lumen reflections this broken and screenspace dependent. I have set everything on Ultra. Please see my attached video and let me know if I do something wrong on my end.
1 Like
Lumen will only reflect what’s visible in the lumen scene debug views under lit. Make sure all your meshes have distance fields enabled and there’s enough lumen cards and it matches the scene well. Might need to break up meshes.
Thanks, I tried couple of cvars and just figured out that the problem only exist while in VR at runtime. In editor lumen updates perfectly, I tried matching scalability for runtime to editor but the issue still exist so far…