Thanks, wasn’t aware of that and just fixed. Though not sure how useful it will be for rough reflections due to noise.
For standalone Lumen reflections you can also enable r.Lumen.HardwareRayTracing.HitLighting.ReflectionCaptures 1 which will sample reflection captures at the last hit point, just like deprecated Ray Traced Reflections.
Like jblackwell wrote, this one is tricky as Lumen uses screen space traces for improving quality and screen space traces sample what you see on screen.
If you are fine with disabling screen space traces then you can use Ray Tracing Quality Switch Replace node to do custom material modifications for world space traces (Lumen Scene).
Alternative approach is to use r.Lumen.ScreenProbeGather.MaxRayIntensity and r.Lumen.Reflections.MaxRayIntensity to lower exposure relative energy limits. This will reduce noise, but will remove energy.
When reading your feedback it occurred to me that we could set max emissive limit by substracting emissive value from the final pixel color. Need to try it though to see if it can be useful for various use cases.
It was removed because instead of retracing ray on a translucent hit r.Lumen.HardwareRayTracing.MaxTranslucentSkipCount times we now skip all translucent meshes. I’m not aware of any issues with it.
Yes, our current approach doesn’t scale that well to offline rendering. Those are two big R&D topics for us and we are searching for an alternative approach for the high end PC use cases.
We already do this for skipping GI screen space ray hits on foliage (subsurface or thin two sided shading models). As you noticed it’s hard to generalize it though.
Likely current gen consoles are going to be the main visual target for games for next 5 years. Maybe even more - in the current generation only recently first games targeting PS5/XSX+ started to appear. So that’s a pretty important use case to solve well.
Yes, the idea was always to start from the consoles and then scale down and up. Likely it will be a mix of reusing existing Lumen parts and creating new ones as needed.
I thought reflection captures were disabled concurrently with lumen reflections, as they were considered baked lighting? If not, then I have not been able to get the two to work concurrently at a project level, but I’m happy to attempt again.
To clarify on that, is translucency just wholesale not supported with lumen? And correct me if I’m wrong, but it seems like niagara particle effects aren’t showing up in offscreen reflections at all with lumen (not counting mesh particles or fluid sims).
They only work with standalone Lumen reflections, which are designed to allow to use Lumen reflections with baked lighting.
Yes, Lumen world space rays aren’t able to hit anything translucent. It’s something on our todo list to fix, but likely not in a budget which is acceptable for most console games.
Cutting out realtime rendered reflections could help out some game situations for studios.
Take an open world instance with world partitioning.
The world partition streaming can mitigate the 351 limit and handle any major changes in the world such as hourly or weatherly changes that would show with Lumen(Both GI and reflections).
Imagine the HLOD system expanded with a “World state” arrays(I think the Night version of the City Sample did that? I may be wrong).
Streaming of capture information could be streamed just like HLODs.
A Matrix system comprising of “world state profiles” created by the studio/environment artist.
Workflow such as building the worlds captures under “5:00AM__Raining” or “12PM__ClearSky”.
(Weather and any other conditions are named by studio)
After the dev says go, each reflection capture in the world grabs the static labeled objects with GI for the scenarios for the entire world.
Heck, it can also capture cinematic multibounce reflections on reflective objects in the scene(may not be visible if memory needs to be keeped in check with low resolution captures).
Would be a nice fallback for SSR.
If I’m missing something obvious, or if I didn’t explain something very well let me know.
Thank you very much for a so detailed reply. I don’t know how to quote you partially:
I have tested multibounce, working great now, thanks!
It’s looking quite near to old RT reflections, so I’m quite happy. As weak points, as you said, it’s super noisy for mid-rough surfaces, as a polished concrete. It’s even better to not use temporal accumulation for reflections, as it creates very ‘fat’ noise. (I’m referring to the second bounce reflections, the ones in the mirror).
Also, I have noticed increasing the max roughness is a performance killer, while in RT reflections doesn’t have that big impact.
This persistence of light in the last one (the light propagation, so the noise too, dissapear when out of screen space) seems related to r.Lumen.ScreenProbeGather.ScreenTraces.HZBTraversal.HistoryDepthTestRelativeThickness and/or r.Lumen.ScreenProbeGather.ScreenTraces.HZBTraversal.RelativeDepthThickness, which I had with a value of 0.1 instead of default 0.01. The higher it’s, the most splotchy. But as it’s not 0 by default, it will be a little noisy with the default value too, without the possibility to remove it at 100%.
And thank you for the rest of the reply! I also understand the commercial point of view, but I was affraid of having thought about “bread for today, hungry for tomorrow” (The possibility of Lumen scalabiliy being limited due to a nowadays-technology thinking, instead of a future projection).
To my understanding, the lumen team is currently very well aware of the reflections issues, they just haven’t had the time to fix them. Daniel Wright’s previously mentioned tonemapping hack is good enough in most cases, but I’m hoping we’d be able to get something in before 5.4 releases.
And on your note of scalability for current vs. next-gen consoles, it does make an incredible amount of sense where the lumen team is coming from. Given just how long it took for the next-gen consoles to hit a meaningful market saturation, all bets are off in terms of what the next-gen can support. As it stands, lumen still can’t easily be shipped on XSX/PS5, nevermind XSS. I’d imagine optimizations to hit console performance would be the priority, and once a given threshold is more or less reached, then eyes could be better turned towards enhancing the PC experience.
I suppose it depends on what you want to consider a cubemap, but lumen actually does support something quite similar to what I believe you’re elaborating on, if I understand correctly.
To support lumen distant lighting, it has a series of world-space probes that cache distant dynamic lighting to keep the cost low where the scene doesn’t need to be too dynamic. If you switch your PPV’s reflection method to ‘screen space’, it does something rather clever: it enables SSR, but uses those world-space probes as an automatic fallback. Should an SSR ray miss, it will sample from the nearest probe; while the probes are significantly lower res than the average cubemap, they’re generally good enough for rougher diffuse lighting.
I haven’t played around with it too much, but I know there are ways to increase the resolution of the radiance cache probes, so you may be able to actually extract quite good reflections out of them.
Sure! But I was really speaking about the second bounce reflections. The first bounce ones can be tweaked with some cvars, as the one you mentioned, but the reflections reflected in the mirror (so, second bounce and forward), can’t.
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.
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:
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.
We do allow that. You can disable Lumen reflections and fallback to SSR+cubemaps:
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!
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.
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
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
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…
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.
