Yes, and your leaves may be moving because of your shader, but you may have “Evaluate WPO” checkbox unchecked, anyway.
Summary: If you enable WPO and disable Nanite, RT shadows work fine with non-Nanite meshes, but it doesn’t with Nanite ones.
Let’s make it easy:
dude… this’ about foliage, not static meshes.
setup: raytraced everything. manylights off (see wip note)
left: static mesh > shadow moves. right: foliage instance > shadow doesn’t move. nanite on > no wpo shadow moves.
wip: manylights currently has partial masked material support. the engine logo kinda works but those wpo tress do polygon shadows. but it’s WIP to integrate with raytraced direct light. same for volumetrics. i get it. 
anyway… enough derailment. back to work.
This is somewhat of a tangent from the discussion, but has anyone had the time to do more in-depth testing of the new reflections denoiser? This is something that I personally have been looking for ever since 5.0 launched, so I am incredibly excited that we could get higher quality and greater content flexibility.
Why is UE5.4 generell a peace of crap?
Hi guys,
Is there any way to get perfect mirror reflections with Lumen so far? Some hidden console commands? Hit lighting reflections still giving this messy look, no matter what settings I tweak for best quality:
what engine version are you on? 5.4 doesn’t have the latest graphics features, yet. it’ll improve soon™
I am on 5.3.2 currently.
5.5 will have a solution for it?
it’s work in progress, but… yes.
Unfortunately, but GI in reflections can be quite low quality. You can try to disable it and instead use unshadowed skylight with r.Lumen.HardwareRayTracing.LightingMode 3 (I assume that you have hit lighting enabled). This will require some tweaking to get it right, but you won’t have noise in reflections.
So I was testing the new light function atlas feature (using 5.4) and noticed that RGB light functions only render the red channel into the surface cache. Just wondering if this is something that will be improved in the future?
EDIT
ANSWER: Sebastien Hillaire responded to my question in the tutorial thread confirming it was a bug that will be fixed
quote from the tutorial
… it is possible to make the light function atlas account for colored light function materials. This can be enabled using r.LightFunctionAtlas.Format 1 (requires editor restart for shader recompilation). When set to 0 the R8 texture format is used, otherwise R8G8B8 is used.
How does this interact with the lumen hit lighting GI system? Will that facilitate clean GI in reflections, or does it just resolve the limitations of the surface cache in first-bounce GI?
5.3.2 doesn’t do the clean reflection thing, yet. disabling surface cache in the reflection removes the noise. the unshadowed skylight is a global ambient boost to push light into the irradiance probes. basicly a “fake” gi/boosted irradiance in the interior. actually a very performant “cheat”. needs artist attention tho. tweaks.
Quite interested about seen a comparison. Unfortunately I have no my test scene available and I will need to wait to test by myself or to see the example posted by a good samaritan 
I achieved no appreciable differences with this CVAR in my MRQ. The only viable solution at the moment for MRQ is Path Tracing but this takes a very long time! What tweaking are you talking about?
This is unreal 5.4.2
The level is made up of a bunch of instance static meshes (not hierarchical). You can see one of the wall segments (which is still reflective) behind the reflection of the player character. Each one of these meshes has the same material which is a simple 0 roughness, 0 specular, 1 metalic.
I have set max reflection bounces to 3 in this case, but got the same effect on 8 (and it likely applies to everything inbetween). It didn’t happen when it was set to 1.
In case it is not clear what you are looking at, the should-be reflective walls have become grey with black specks in the reflection. Different segments will go in and out of this state depending on viewing angle, but not in any consistent way.
Does anyone have any experience with stuff like this?
That looks like a precision issue of some kind- are you far away from the world origin by chance?
Hi @Krzysztof.N ,
Giving some feedback:
The problem goes out with 2 sided mats, but then, Lumen would be broken. It seems that this is happening for some years now: https://www.reddit.com/r/unrealengine/comments/vep5a3/how_do_i_fix_these_dark_bugs_on_the_bed_path/
Thanks!
Tested it to make sure, but sadly even at (0,0,200) the same thing happens.
With hit lighting surface cache is only used for the indirect term (shadowed skylight and N+1 bounces). r.Lumen.HardwareRayTracing.LightingMode 3 will force unshadowed skylight instead, basically removing any surface cache usage.
PPV takes precedence, so you need to clear hit lighting from the PPV and then try this CVar. You can do all this stuff in the viewport, so that you don’t need to go through this long iteration loop with MRQ.
This looks like mismatch between RT representation (Nanite fallback mesh) and rasterization. Ray starts on the screen pixel (rasterized geo), but then we trace against the low poly Nanite fallback mesh and ray may self-intersect if it’s too low poly.
Usually this isn’t an issue due to screen space traces, but I guess you disabled them. In that case the only thing left is biasing. For GI there are two, one for one sided and one for two sided geometry:
r.Lumen.HardwareRayTracing.SkipBackFaceHitDistancer.Lumen.HardwareRayTracing.SkipTwoSidedHitDistanceIn general it’s best to increase Nanite fallback mesh quality inside the static mesh settings. Especially if this is not targeting consoles. Alternatively you can play with biases (apart from GI, there are a few more for other parts of Lumen). You can also try r.RayTracing.Nanite.Mode which will ray trace against Nanite geometry, but it’s pretty slow and only streams in Nanite geometry based on the rasterizer so e.g. it may be still low res in reflections. So may not be a best choice for real-time, but certainly you should use it for the path tracer.