Lumen GI and Reflections feedback thread

I barely touch development editors beyond what it takes to build; what’s the distinction between building the project vs. the whole solution?

the solution contains other projects/programs. this may take a while longer to compile. i think it built for over 10 hours the last time i tried that. the dependencies for the editor only project are compiled anyway, but the time should be a lil shorter. i built 5.3.2 in 2:30 something hours on my lil 6 core.


and i just hit the button and try the main branch once more. [119/5995]. 3 hours to wait? wish me luck. i hope the 5.3 DLSS code compiles without issues. gonna need a lil help pushing my hardware to the limit.

edit: so much for dlss


just 11 errors is nice tho. i think/hope i’ll figure out how to fix that. i can barely read the codebase. challenge accepted. :slight_smile:

Checked mine and it’s 182GB total (you can delete tons of GB when already compiled and working). But I’m not an expert about compilation. The first time it was a brutal fight to make it work; I not sure if I could achieve it again after formating my PC :smiling_face_with_tear:

Most CLs in UE5-Main should work. This is what we use for all development across the company, so breakages aren’t common and if something is broken then it’s fixed ASAP. Maybe you have a wrong Visual Studio version or are missing some dependencies. At the moment recommended version is 17.7.x. You can check it in Engine\Source\Programs\UnrealBuildTool\Platform\Windows\MicrosoftPlatformSDK.Versions.cs.

5 Likes

no dlss, atm (i’m not pro enough to fix it, rn)… but we we building shaders. and use a humble amount of space. all good. :+1:

let’s see what you done the past months.

Thank you! I’m going to look into this. I’m not going to claim to really know what I’m doing, so all of the help and education is very much appreciated. Thank you!

Where do you enable it in 5.4 (github version)? Just made a new build and can’t find it.

I did notice in this 5.4 version though, when using Lumen and VR (openXR), in one eye the reflections are glitching / flickering all the time. Crossing fingers this gets fixed before the official 5.4.0 release. Can’t report this in the bugtracker until then (or…?)

Just search for a cvar called something like stochastic enable. If you can’t, I will find it later.

PD: Reflections in one eye (I don’t remeber well, but the right one?) are broken since UE5.0 :(. Already reported months ago (and some other bugs too), but nobody cares.

AFAIK, Stochastic shadows are meant as a supplementary shadowing method for non-hero lights, so it makes sense that you’re seeing speed be prioritized over quality. I’d imagine that hero lights would be employing VSMs or the similar, because the lack of quality is quite noticable.

1 Like

Have you tried 5.1? The reflections are stable in both eyes VR in 5.1 with Lumen enabled and openXR.

Yes I did! In fact, one week ago we have finished a project in 5.1 and another one in 5.2. You are rght in 5.1 there were less reflection glitches, but I think I remember there were too. And also other issues related with ray tracing and lumen.

done some testing. stochastic ray shadows that is. looks good on static geo.

lil noisy with moving objects. it’s stochastic. aka randomly sampled. i get it. i take the performance plus. more work for taa tho. (and it’s not doing too good on certain ray traced things. like mirrors. the motion doesn’t mirror correctly. the further the object thru the mirror the more it’s ghosting. that’s a whole 'nother problem tho.)

subject 2 exposes hard shadows on dithered hair. works with the normal ray shadows or shadow maps. dunno vsm. too much resources for my rig. also seems the light reflection on the hair got more unstable. hmm

and i know windy foliage doesn’t work with ray shadows. (there’s a workaround for that, being rigged trees, but that’s beyond topic. also visible are the earlier mentioned backlighting artefacts even with enabled fog sampling.)

bonus snap. i never checked if volumes are working with shadows. looks good tho. i wish there was a way to make the volumetric cloud to cast a shadow. that’s stochastic raymarching? :slight_smile:

1 Like

Just tested - for me its the left eye. Right eye looks good. Quest2+Link+openXR

This is very, very exciting! I’d have to imagine that stochastic shadows (or sampled direct lighting, or whatever other name they chose) will take a few engine versions to get to a strong enough point to be shippable, but the results you’re showing now are already very promising. I know that stochastic shadows ostensibly allow for using screen-space/distance field/hardware rays all in the same shadow paradigm, but I’d love to see what the perf numbers look like with that.
If most of your shadowing is being done on-screen, then shadows could be significantly cheaper than if they need to do a lot of offline ray-tracing. You could also probably tag which objects receive full RT shadows vs. just SS shadows, so stochastic shadows could have a number of great levers to manage performance.

Side note: Personally, I prefer the name stochastic shadows over some of the other ones I’ve seen mentioned. If it’s a matter of copyright or expanding what the technology does, I completely understand, but I feel like it’s catchy and easy to rememeber.

i got a limited budget and limited test assets rn. in my foliage spam torture…

8k csm

random rays (it’s not really random) cause it’s a single sun light.

not the most accurate perf measure, cause it’s instance bound struggle. but fidelity compares. much more details for less compute.

the real benefit of this are proper contact hardening shadows (i showed in the first test screenshot in the other post). dunno vsm. shadow maps don’t even do that. so there’s no reason to compare this screenshot and perf numbers. just gotta say 6 lamps with all those shadows runs and looks great. ez 60 fps. (seems the editor is locked on my rig/config) i should do a more lightspammed map? i can do that. :slight_smile:

edit: nvm… i can show you atleast those perf numbers. pure ray bound. only diffuse and full metal…

pure rayshadows (and 8 bounces of goodness:)

and stochastic ray shadows

the stochastics are a lil noisy when not fully stabilized, but… that’s where actual environment art and textures come in. you won’t see most of the noise on detailed textures.

1 Like

Virtual shadow maps actually do support a form of contact hardening with their Shadow Map Ray-tracing algorithm. It’s not nearly as robust as actual RT shadows (all of the documentation describes it as plausible contact hardening), but you need to increase the ray count of the VSM sampling beyond 1rpp, or it does default to perfectly hard shadows. You likely know this already, but others may find the context helpful.

That said, there is a lot about the VSM pipeline that I don’t understand. When I was trying out the wild west megascans map that Epic provided around 5.1 or so, VSM performance made the scene almost unmanageable by default, but enabling RT shadows significantly improved performance.

Arting around technical issues is the bread and butter of our trade. It still amuses me that lumen can easily handle the highly-specular surfaces that would have broken cubemaps, and yet the normal material roughness for objects built with cubemaps in mind, will break lumen.

that is raytracing in a nutshell. roughness adds complexity. when you hit a rough surface you have to decide which way the reflection ray goes. in the pathtracer multiple reflection rays are generated and collect the color of the surroundings to blend. that’s not gonna run in realtime anytime soon, tho. for the game performance rn only one random ray is cast per frame and those random rays are accumulated over time via the history and are temporaly stabilised.

the cheap method for adding roughness was using irradiance cubemaps. more rough more blurry. they are not updating tho. so you get a static cubemap at build time.

i think we surpassed that stage. rough reflections can update in realtime at moderate quality. artist discretion. you gotta know where it fizzles and avoid it. ez. :slight_smile:

The multi-light case you show is a really big deal imo because it addresses a case that has been mostly impossible to get acceptable performance on - realistic chandeliers and similar multi-light fixtures.
In my house I have chandeliers with 6 bulbs. This setup casts very distinct shadows, but replicating this look in engine by overlapping 6 light attenuation radii with shadow maps is a big no-no. You end up putting one light in the middle and lose the distinct multi-shadow look. Most people probably don’t notice… but I notice and I’m looking forward to trying it out. Not gonna build though, I’ve given up keeping up with main. Too much storage space, too little time lol.

@Miguel1900, @maxbrown Have you tried disabling instanced stereo? Generally when dealing with VR issues that are present in just one eye that’s the first thing we test as sometimes when a new rendering feature is implemented often the stereo optimisations come in a later engine version / update. Its not optimal as it costs a bit more performance but for some use cases it might not be an issue.