In Unreal Engine 5, in my project I included the AirSim/Colosseum plugin to capture images. In the preview window Lumen works properly but every extracted image from spawned cameras is rendered like Lumen was disabled and I am trying to wrap my head around if I could fix this somehow but in the search of where in the rendering pipeline lumen is happening, I got stuck.
Maybe one of you has an idea or maybe Lumen is just not working with cameras outside the viewport currently?
Out of curiosity, is there a reason you’re using UE 5.0 documentation instead of the newest version? I believe I heard lumen visible in capture received some fixes in 5.2?
I realize this is off topic, but does anyone know if there’s a dedicated VSM feedback thread? If so, I haven’t been able to find it, and I’ve been having
strange shadowing interactions with lumen and can’t make sense of it.
Really glad for this, it made such a difference in our project:
Lumen Reflections can now be used without Lumen GI, for games and applications which use static lighting but wish to scale up in reflection quality beyond Reflection Captures. Standalone Lumen Reflections only work when Hardware Ray Tracing is enabled, and it will force Hit Lighting to be enabled automatically, as Lumen’s Surface Cache optimization is not available when Lumen GI is disabled.
However reflections dont seem to work so far on translucent materials. I did try to find a “magic” combination of settings in material and project settings, even console commands but cant seem to find anything that would make this work.
Testing:
Blank project, simple bockout scene with basic shapes
one sphere with metalic, Opaque material
second sphere with metalic, translucent material, opacity 0.7, lightning mode: STV / SFS
Enabled HW raytracing in Project settings, disabled Lumen GI
you can cheat. masked with dithered opacity mask. you only get a 50/50 transparency in cheap mode, but it’s something, not nothing. lowest possible shader complexity for glass. and it’s rather stable, depending how much bloom and stuff you shoehorn into it. i mean the bloom flicker is upto how small your sun is and…
… how lowres the raytrace is rendered? i got a lil close up there. i can see the coarse pixels and “reconstruction”. it’s fine tho. it’s performant.
With something like a cvar to control the number of samples, or to enable a denoiser:
With some zoom:
And improved “contact” AO? The areas near to objects are lighter, instead of darker, creating a weird effect and a “floating” feeling on that object (this is a sofa very close to the floor):
A photoshoped example, just darkening that “white line” area:
Would be so great to have the ability to control the intensity too (darker or lighter)
AO it’s the missing key for Lumen realism, keeping objects “attached” to others giving consistency, so it’s a very important feature to be attended (IMO) .
Screen percentage/resolution is the main lever with SRAO. It does not offer a consistent look across resolution. But it can reduce noise by a lot.
You will find that SRAO rather over-occludes compared to the path tracer. Although from an artistic perspective SRAO does make objects look more grounded and adds depth, so I often like it, regardless of the wall of text below.
For what it’s worth… If we consider what AO really is meant to imitate, it is a lack of bounced light rays hitting hard to reach areas. This is kind of like roughness vs smoothness. They are both terms that describe the same thing, but from the opposite perspective.
However - unlike roughness vs smoothness where perspective is irrelevant to physicality - Light is additive, not subtractive. For physical accuracy, you would determine the amount of direct lighting, and the surface should not get darker than this. Light bounces are then added, hitting mostly areas that are easier to reach. The hard to reach areas will naturally appear darker than the areas which light hits easily, but this is because less bounced light has been added, not because of any need to artificially subtract light.
excuse me. what the heck is SRAO? don’t make stuff up. even google can’t find that.
SSAO surely depends on the resolution if it’s got a fixed kernel size. obviously. in edge cases there’s simple not enough depth and normal difference inside the kernel radius to determine a sharp edge, resulting in white lines.
alright. just checked the shaders. i can’t really picture how it really does that ao pass. it’s screen space aligned but it raytraces it. small corners are small corners. half of the hemisphere is inside the geo. half the contribution missing. most likely the reason for the white haze.
Sure, it will improve that resolution and all the rest of details, killing the performance. Lumen is a little bit inconceivable without TSR or DLSS, so it doesn’t look like a solution nor a workaround, IMO.
@glitchered , could you explain a little more that theory about the hemisphere inside the geo?
i dunno how exactly the hemisphere is oriented, but at narrow angles this looks like this, graphicly explained. excuse my poor painting skills. just whipped it up real quick.
It was fixed in CL 26448246 and will be included in UE 5.4.
Yes, it’s something on the todo list to make it a higher quality short range GI. Though if you want straight AO on top then likely those aren’t the changes which you will like, as it will rather reduce occlusion to be more correct and match the path tracer better.
There’s also a much more expensive HWRT version of it under r.Lumen.ScreenProbeGather.ShortRangeAO.HardwareRayTracing 1
Being closer to Path Tracing is my beloved feature, in fact! If achieved, it’s a much more desired behaviour.
It may reduce occlusion, sure, but in some zone like white walls edges (for mentioning an example), but it should increase occlusion in other areas, like under a (close to ground) sofa. The problem is when “whitenning” white painting edges is poor (far from Path tracing) and without depth, when it’s needed to add this king of faked AO. But in fact I already reduce AO intensity in my projects and my corners. So if it becomes closer to PT, that would be so great!
About those 2 cvars, I already use them for testing, but they don’t give great results:
I call Max albedo multibounce as “extra AO” (instead of “AO booster”, for example), as I feel like it adds an extra albedo layer in previous zones without AO, but it doesn’t change already existing AO zones, so no intensity change.
RT short AO looks almost the very same as “normal”. Noise micropoints are still visible. “White line” gaps are still there too:
This leaking can be reduced by replacing screen space tracing with ray tracing r.Lumen.ScreenProbeGather.ShortRangeAO.HardwareRayTracing 1 or by tweaking screen space bias under r.Lumen.ScreenProbeGather.ShortRangeAO.ScreenSpace.SlopeCompareToleranceScale.
That quoted phrase was referred to the second image I posted in the post above (“RT AO with max multibounce increased”), using the r.Lumen.ScreenProbeGather.ShortRangeAO.HardwareRayTracing 1 cvar but, as you can see, it’s very very similar to the default non-RT short AO (and yes, it’s is surely enabled as it changed a very little around the sofa leg).
I also tried using the r.Lumen.ScreenProbeGather.ShortRangeAO.ScreenSpace.SlopeCompareToleranceScale before, which needs a value of ~2.0 to fully cover the gaps (and it’s a tradeoff), but this has two main issues: the AO is too much dark, but also quite noisy (so, an intensity multiplier and a denoiser or number of samples would be so great to mitigate them):
No changes at the moment, but it’s something on the todo list. Can’t promise anything, as any time something of higher priority may come up or simply our ideas may not work out in practice. Can only say that we are monitoring this forum and from time to time acting on it, like in case of translucency in reflections mentioned above :).
