Got it, that makes a lot more sense to me, thank you. It is interesting how the different new/legacy systems are interplaying with eachother like this, and I eagerly await the lumen team’s front layer refraction system, or whatever it turns out to be. I was just having a conversation with a friend about how lumen has achieved parity with offline renders when it comes to a lot of opaque light transport, but refraction is still something it cannot handle well. It’ll be interesting to see how that may change.
There are several artifacts shown. Pixels that don’t hit anything just become invisible, so distant elements become totally transparent. If look closely and you’ll see streaking artifacts which flicker with the temporal jittering in motion. There is also a complete lack of ambient occlusion.
But you can see the overall brightness of the scene, and color are a reasonably close match to the Lumen scene. You still get some larger scale noise which can be reduced by messing with cvars and flickering.
Also, you may have noticed it says Emissive and GI… So here’s some eye candy showing off the RT refraction + emissive and indirect lit only scene. This is genuinely cool, even if its a bit leaky and imperfect.
10 years ago this would have taken an offline renderer and who knows how much time. Instead, it’s real-time running in what’s ostensibly a game engine. This is incredible!
Noticed a minor bug in 5.3.1: Specular highlights from light actors aren’t occluded in HQ translucent reflections, but works correctly on opaque surfaces.
This is kind of of a follow up after Lumen Direct Lighting. Lumen DL didn’t deliver good enough quality and it was questionable to have direct lighting depend on indirect (like how do you scale down?).
VSMs will be the superior solution for hero lights like directional (sun). Stochastic Shadows are aimed to provide a reasonably cheap replacement for baked shadows from local lights.
It doesn’t use ReSTIR due to extra performance overhead of ReSTIR for ~100 lights (which seem to be reasonable numbers for console games) and blurry direct lighting. ReSTIR stochastically evaluates not only shadows, but also BRDF itself. So you need to run denoising on top of BRDF causing blur and ghosting in unshadowed regions.
do i wanna know how this works? was just messing around and lasered a chrome ball. somehow at the million cd i blasted thru it and it created a second hit point.
this has no real usage, atm. cool to see it kinda working tho. not a disco ball yet. lol
btw… why are there no colored shadows in the engine? this shot is shadow mapped aka standard cascade. it could pickup the color and opacity of the glass for a blend. rgba4 is a thing. good enough for a proxy color without much resources.
If you’re desperate for colored translucent shadows, you can use a capture component aligned with the sun to grab the color and depth and re-project the color using a decal with emissive.
It works by basically creating a custom shadow and color map for a single object or collection. It’s not particularly cheap and should be used sparingly, but for scenes that absolutely must have dynamic colored translucency it is an option. Due to relying on decals, the light bounces is screen space only.
Edit: I’ve set up a full tutorial for those interested
pt. 1 https://youtu.be/Xe5TjsUtmZs
pt. 2 https://youtu.be/A6n2iF0nxZw
That’s a good idea! I solved this a sort of different way a while back, by using a ray-plane intersection. Still requires a capture component for depth though:
I see, so a reasonable use case would be a VSM sun light, perhaps VFX lights, and all else would be stochastic shadows? Is the ray count going to be something tunable via PPV, or is it more meant to be a project-wide setting? Is this (theoretically) something that could scale down to mobile?
So this is strictly shadows, no lighting integration.
For now it’s a CVar, but it’s also very early days of this feature. Not sure about mobile, I guess on some HW?
Shadows are stochastically sampled with a constant ray budget per pixel. Lighting is evaluated fully every frame. It’s also quite bit faster than current lighting loop, as it leverages similar work which has to be done to decide where to actually trace rays.
I guess at some point I need to start a dedicated thread :).
A good idea, I don’t want to make the lumen thread any messier than it already is. I’m very excited by this feature, as I’ve found the extant shadowing solutions to form a pretty strong gulf between high quality-high cost (RT shadows, VSMs especially) and low-quality low-cost (standard shadowmaps, SSShadows, DF shadows variably). A unified lighting method that could scale from DF shadows to HWRT shadows could also make development costs easier.
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.
