That is true, and I honestly have no idea how solvable that is at this point. Each bounce would theoretically make the reflections exponentially more incoherent, and I don’t know if even NVIDIA has figured out a good way of doing it (DLSS 3.5 being a mystery). I’m very much with you, I just don’t know what solutions are available.
1 Like
FYI to @Krzysztof.N as of 5.3 lumen reflections don’t appear to be accepting reflection captures at the end of their rays; not sure what’s up with that exactly.
There’s actually a very strange error when I try to use them, I set GI and reflections to none just to confirm that cubemaps were working, and this happened:
The black spheres are the cubemap radii, and moving the cubemaps moves the spheres.
Also, cycling the skylight mode at all caused scene textures to shift inexplicably. This is a bug that’s happened before, but I thought it got addressed. Moving (not just selecting) a mesh resets it to its’ correct texture. The areas with bad coverage register has black in the surface cache, and are fixed once the mesh is moved. The path-tracer nor lumen hit lighting register the bad textures.
The same meshes like pulling from the same bad textures, but with little rhyme or reason as to why. The meshes behave like the textures from another object were simply assigned to them like in the content browser. Substrate is enabled.
Just heard that the problem is unrelated to lumen and has been fixed in the next patch, my apologies.
We do allow that. You can disable Lumen reflections and fallback to SSR+cubemaps:
https://docs.unrealengine.com/5.3/en-US/lumen-performance-guide-for-unreal-engine/#replacinglumenreflectionswithscreenspacereflections
I think what you are missing here is screen space traces. So how Lumen works is that it first traces a screen space trace and if that trace hits then it samples color on screen. If such trace goes behind geometry or offscreen, then we continue tracing from last known point using a world space trace (Distance Field or BVH trace) and that trace will sample Lumen Scene on hit. With RayTracingQualitySwitchReplace you are able only to replace what is in the Lumen Scene, so there will be a view dependent lighting mismatch, possibly leading to more noise.
To make them work you need standalone Lumen reflections with hit lighting. Enable r.Lumen.HardwareRayTracing.HitLighting.ReflectionCaptures 1. Then you should see how metals in reflections sample reflection captures (also works in Lumen visualization overview view mode). They seem to work on my end, though I’m on UE5-Main latest.
Oh, I see, thank you. I thought your previous comment was a workaround for screen space traces too (but I missunderstood it). So, currently, no workaround to 100% avoid emissives illuminating, as screen traces will be still there (unless you make huge tradeoff like disabling lumen screen traces, or lowering the max ray intensities too much).
I hope you can test your idea (we could set max emissive limit by substracting emissive value from the final pixel color) and make it work succesfully!
1 Like
I did have that enabled when I tested, I alas didn’t see the reflections. But if it’s working in _main, it’s no worry then, thank you for letting me know.
With the 5.3.1 release I thought I’d take a look at Lumen reflections again and I’m getting strange results.
Scene: lit with HDRI backdrop only, a chrome ball and UE mannequin + Metahuman.
Settings:
Looking at an angle, unsurprisingly everything looks good as screen space tracing picks up all that is needed:
and metahuman
Getting in front of manny and looking head on at the reflection, it’s there but it’s too dark as if the reflective parts of its material are not picked up
Strangly, going to Reflection view mode shows it much better:
Switching to ray tracing for reflections produces correct result, unsurprisingly, but of course you loose GI in the reflection
In case of metahuman, in the same view - looking head on at chrome ball reflection - produces completely black reflection (and missing groom)
Either I’m doing something wrong, or my settings are incorrect. I would like to use only Lumen for everything - deprecated ray traced reflections are correct but do not account for indirect.
- How can I make Manny reflect correctly with Lumen? I was under impression that with Hit Tracing it would pick up the reflection similarly to ray tracing.
- Is there a way to make Metahuman reflect correctly with Lumen? It’s completely black and is missing hair (groom)
- I’m not entirely sure what “Max Reflection Bounces” in Lumen reflection settings really do as it seems to have no effect at all
Hmm, have just been playing around with some concrete, and noticed that “something is off” especially with light that should go upwards again:
I cant really point at what is going wrong, but lumen (5.2) still has issue with “lighting upwards”.
If you compare this image to how “brutalist architecture” actually lights on the inside, the difference is like day and night.
I mean, I know a workaround for this, but it would be really nice if we could get some improvements for that kind of bouncelight. 
Usually there needs to be direct light hitting the floor to get good bounce lighting under over hangs. Also check that the lumen scene represents the actual scene well…
You can also always compare versus the path tracer.
1 Like
We are going to remove deprecated ray traced reflections soon, so should be able to achieve exactly the same results by using standalone Lumen Reflections (GI=None, Reflections=Lumen).
Unfortunately you can’t at the moment. Hit-lighting calculates material and direct lighting at the hit point, but it requires surface cache to get indirect and surface cache doesn’t support skeletal meshes. Something what we need to solve.
The only workaround is r.Lumen.HardwareRayTracing.LightingMode 3 which will add indirect from an unshadowed skylight at every hit point, but that’s likely not what you are looking for here.
They trace extra reflection rays on ray hit. Imagine looking at something with a low roughness in reflections:
Is there a way to control the roughness threshold by which lumen decides to trace additional rays? In my observation only the most specular surfaces tend to benefit from said rays, and while I know there’s some sort of russian roulette algorithm in place to kill more diffuse rays, I’m not sure of which knob can be used to tune it.
Is there a timeline on when the standalone RT effects will be removed? Although I imagine there are still some use cases for RTAO (just wanting occlusion and no bounce for horror games, for example), RTGI is completely useless at this point and actively broken in a project of mine.
It’s based on the same threshold as dedicated reflection rays - r.Lumen.Reflection.MaxRoughnessToTrace. In UE-Main it’s now also exposed in PPV.
The idea is to only remove RTGI and RTR as those should be fully covered by Lumen now.
1 Like
Anyone have any good strategies for improving the result of distant lighting?
Also interesting to look at the pattern on the ground away from the light source:
Appears to be related to the radiance cache probe resolution/density, but I don’t know if increasing them is really a good idea.
1 Like
I see, I’m with you now.
Out of curiosity, do you know what we may expect in terms of features/upgrades for 5.4? I’d completely understand if it’s all too early to tell, simply curious.
1 Like
FWIW there’s a public long-term roadmap now; https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/1264-lumen-hardware-ray-tracing
Seems one of the priorities is getting HWRT down to 4ms on next gen consoles.
1 Like
I had no idea, thank you!
Unimportant
Wow, some of those features are absolutely killer. Nanite dynamic displacement looks awesome, and I’m really curious what features compute mats could enable.
Something I’m actually quite curious about @Krzysztof.N, do you and the rest of the lumen team feel that the SWRT/HWRT paradigm has delivered on your original architectural goals for lumen where performance is concerned?
While there are certainly scenes that SWRT has performed markedly better at than HWRT (valley of the ancients comes to mind), it seems that the performance delta between the two hasn’t been matched the quality differences. There are scenes I’ve come across where SWRT doesn’t run significantly better than HWRT while looking significantly worse, especially where foliage is concerned. Is this part of the impeteus for trying to decrease HWRT costs significantly to make it more viable on console; if so, will there be a defocus on SWRT for next-gen platforms?
This is assuming SWRT doesn’t evolve too much; given new techniques like Ray-aligned occupancy maps, perhaps there is more performance on the table than I understand there to be.
Just found an issue with Lumen reflection. I have two basic Substrate materials, one is blue emissive, the other is red basecolor, nothing else.
If I hide the red ball then unhide it,
This is my config, it’s happening with Hit Lighting for Reflection Mode.
DefaultEngine.ini (3.6 KB)
if the balls go off screen,
And btw, is it possible to get rid of these speckles? I guess it’s vice effect of path tracing, if it is, can I just make a trade-off to ray trace everything to make it accurate?
It’s innate to lumen’s architecture for now, unfortunately.
EDIT: I misunderstood potentially, you posted a photo of a wall with clear surface cache coverage and I inferred. The noise in the PT can be resolved with more samples, the denoiser isn’t great at the moment though.
1 Like
speckles
You mean flickering? Yes
Ignore the reply to the other person and read the “un-hided” part. Flickering is related to Lumen downscale factor Cvars and temporal accumulation
EDIT: Wait, my eyes unfortunately skipped over the “path traced” detail.
1 Like
Hi @Krzysztof.N and @Daniel_Wright ,
Maybe you have already thought about it, but what about making Lumen work in baked scenarios? Almost any game needs ALL the meshes to be movable, so this could give you (and us) the headroom to gain more performance too. A whole baked scenario qith just a few dinamic objects.
I think Lumen could work just with dynamic meshes + stationary/movable lights only (when static lighting is set to Allowed), instead of throwing tons of rays in all directions, against all actors.
It could be (in my immagination) something like only throwing rays along a radius of action from the light source (like the attenuation distances of every light), and only when a movable actor is detected inside the light frustrum. And, from that certain object, throw the bouncing (maybe just 1 bounce) rays to project GI and/or AO over the neighbour actors (also determined by a radius falloff, for example).