As far as optimizations go, this is very interesting to me. In the distance, occlusion matters far more than correct color bleed, especially due to the dominance of the skylight in setting tone. The sheer performance speedup is very impressive.
3 Likes
As far as optimizations go, this is very interesting to me. In the distance, occlusion matters far more than correct color bleed,
That’s actually something I suggested a while ago when I brought up the UE3 demo and shared a link showing Lumen with the “mincardsize” maxed out(no colors in lumen scene).
If it’s performant and not dependent on TAA/TSR, it will be a major improvement.
It would actually be extremely helpful with close/local scenes with wet scenes where everything is low roughness and the cost of DF/mesh ray tracing gets high due to the per-pixel cost.
okay. i don’t have a lot of usage for the far field rn tho. it may help “downtown” long shots tho. i get it. : )
To the devs or whoever knows, what’s the difference between indirect occlusion and ambient occlusion in this case? I know how AO is calculated in a nonphysical sense, but I don’t know what it would mean in a physically-based lumen sense.
i’d guess indirect is occlusion of light probes and ambient occlusion is generated from geometric obstacle traces.
AO here is an extra nonphysical AO term which can be added on top of existing Lumen results. Kind of like if you would add SSAO on top, but this SSAO is calculated using already traced Lumen GI rays.
Indirect occlusion here just means physically based “AO” which you automatically get when you calculate GI. Basically Daniel wanted to convey here that GI should be enough and it doesn’t need any extra AO term, unless you have some artistic reasons.
3 Likes
Thank you for your replies @Krzysztof.N !
Regarding AO (maybe Lumen AO could be named like that, or like PBAO?), I would revive an old but persistent ‘issue’ I still live with:
Image taken from the internet, showing a kind of noise I encounter many times, but less flagrant:
It seems Short AO; there is a general smooth AO gradient but, arrived to a point, it suddenly start showing totally black spots in the darker areas, instead of still respecting the gradient at least, being not able to represent grey scale values, but just black or nothing. Could this be improved?
I think this screenshot is with TSR disabled, while ShortRangeAO assumes that there’s TSR (or something similar like DLSS) at the end to cleanup the noise.
Now in UE5-Main by default ShortRangeAO is traced at half-res using a dedicated denoiser. So that should be reasonably clean even without TSR. And if there was some noise with TSR, then that should be better too.
If you don’t mean that noise then not sure why it would be too dark. Unless you mean on foliage? But if foliage has correct shading model then we decrease ShortRangeAO occlusion strength in those spots (controlled by CVars).
4 Likes
Thank you @Krzysztof.N ,
I usually prefer to use TAA instead of TSR because of many issues I have been facing during this years, like less performance, ghosting or “squary pixelations” (variating between versions and being less stable than TAA in general).
Never thought TSR could also serve to clean this kind of noise when @100% resolution but I have tested and it does! I still prefer native resolution without this kind of “reconstructions”, if possible, but I suppose this is an additional reason to start moving onto it (just waiting to be better than TAA in every aspect!).
This makes me wonder something: is there any other lighting ‘fields’ where TSR is expected to be used, over TAA?
I will need to check in Main branch soon, then!
Thank you again
Will there be a console command or an option in the future to completely prevent Lumen from calculating emissives in screen traces?
Currently, I’m using a workaround by applying a fully translucent material with an emissive layer on top to make Lumen ignore it, but this workflow is far from ideal. It requires isolating the emissive parts of a mesh and detaching them from the rest, which becomes especially problematic since Nanite doesn’t support this type of material. This adds unnecessary complexity and turns the workflow into a tedious process.
It would be great if a dedicated option or console command were introduced to exclude emissive materials from all Lumen calculations, as their current handling is very poor. Such a feature would be highly beneficial ! 
1 Like
@Krzysztof.N
Found out why some of our scenes are crashing since 5.5 (GPU Removed)
When:
Lumen = 1
Lumen Raytracing shadows = 1 (HW / Software raytracing seems to both crash the same)
Nanite = 0 (It can be also just disabled on the specific static mesh using Disallow Nanite = TRUE)
Evaluate World Position Offset in Ray Tracing = 1 (on the specific static mesh)
Sometimes its not a immediate crash but rather it seems to be triggered when a model with WPO gets closer to the camera.
But adding any megascans trees to a blank project with the above settings, all I have to do is set the Evaluate World Position Offset in Ray Tracing to true on all the trees in the provided asset zoo level and the crash occurs.
Is this something that you are aware of?
Also is there a way to get Raytracing shadows + WPO + Nanite working together nicely? Enabling Evaluate World Position Offset in Ray Tracing on mesh while Nanite is enabled doesnt seem to do anything to raytraced shadows unfortunately. I believe this is a known limitation so far if im not mistaken.
hmmhmm. too computationaly expensive. the bvh has to be rebuild for every deforming instance, so you can raytrace the volume accurately. you cannot trace randomly deformed geometry against the static bvh.
not sure how skinned characters are handled, right now. probably output bvh data in the skin compute shader. the bounding box could move. you need a static world position for the raytracing triangles.
Updating ray tracing acceleration structure in realtime is very difficult and usually quite slow. But given how many miracles Epic has managed to do in a row (Lumen, Nanite (even with foliage), Megalights, etc…) I am pretty sure they will crack this one too eventually.
Right now, ray tracing, even path tracing with realtime rebuilding of geometry works, it’s just not very fast. That’s why r.Nanite.Mode is set to 0 by default.
I am talking about this because when it comes to HW ray tracing, it’s not just about deforming instances. As long as you are using nanite, pretty much all geometry is “deforming” in a sense as long as you are moving the camera because nanite is constantly replacing mesh patches depending on the distance and culling. So entire scene is essentially constantly dynamic and requires updating ray tracing acceleration structure constantly.
But despite that, even quite heavy scenes still run relatively ok with HW ray tracing or path tracing and r.Nanite.Mode set to 1. Relatively ok in a sense that there are FPS drops and stutters, but the editor doesn’t slow down to single digit FPS numbers or crash, which alone is quite an achievement. Especially considering that UE can rebuild acceleration structure of entirely path traced geometrically complex scene at higher framerates than FAB plugin can rasterize a few 2D product thumbnails while scrolling 
nanite is in theory easier to raytrace. screenspace bounding box visibility check limits the amount of updates. optimized mesh density limits the amount of vertices to process, and the resulting cluster numbers limit the amount of hierarchy (i’d call it) “injections” you’d have to do. simple compute balancing. every triangle cluster that is generated is essentially a bvh leaf node. you just compute the bounding box of the cluster and replace it in the bounding box list above in the hierarchy. not sure about the overlap tho.
technically more correct, triangles should be clipped to a clean worldspace partitioned box volume to not have the overlap of the “irregular” shaped cluster’s bounding boxes. i’d guess those overlaps would require more traversal, and box and triangle intersection tests to get the triangle hit. that’s the thing, to crack, i guess.
but being screenspace bound, limits raytracing accuracy of offscreen objects. could do those with proxy meshes to keep the rebuild cost down, but would likely introduce screenspace transition/pop-in artefacts. unless you would couple alpha masked mats for the offscreen traces to keep the details the same. that is for foliage tracing mostly. and this is a semi nightmare for the asset author. unless you model low poly alpha to high poly. nanite cutouts. yo
i can conceptualize and visualize this (in my minds eye) pretty easily. would be crazy cool as a debug visualizer, but that’s beyond usability or necessity. hmm… : )
Workarounds are generally the name of the game unfortunately. Even in official Epic samples, the one I’ve seen is setting any emissive objects you want to actually use the cloth shader and be excluded from lumen.
1 Like
Indeed, it would be welcome if Epic introduced a dedicated option to entirely exclude emissives from Lumen’s GI calculations without having to use such workarounds, especially since Lumen does a really poor job handling emissives.
cloth shader? that’s a new one to me. is it cheaper than the forward translucency volume hack? i’ll look into that. for sure would like a cheaper alternative to exclude emissives from lumen too. i mean… mega can replace all of that if you position lights properly. not using gi or maybe baked. lots of flavors.
Hmm … looks like Vulkan SM5 had a 5.5.4 hotfix for SM5 Lumen but DX11 SM5???
UE-235102 Android Vulkan SM5 Lumen ray tracing does not function as expected
Still no Cvar supported for DX11. Vulkan SM5 is still functional while DX11 is still broken for SWRT as of UE5.5.4 hotfix.
Vulkan SM5
DX11 SM5
Restore DX11 SM5 SWRT Lumen by uno1982 · Pull Request #12992 · EpicGames/UnrealEngine
PR Opened against release to see if we can actually get movement here. Dev-5.5 had 15 likes and an approval and was simply closed by the bot.
2 Likes
It’s what they used in the Cassini sample to stop their displays from propagating emissive lighting. Granted, that was a project very specifically designed to be as small as possible (with many corners cut along the way), so it’s not nessesarily a general best practices guide.
hmm… cloth doesn’t even remove it from lumen. so… i dunno. it’s still in the opaque pass.
the cheapest i know i can do to reject emissive panels and stuff is translucent unlit mode. comes in at 416 instructions. 360 without fog. but… generates ofc overdraw if the meshes overlap directly, means not being z-culled by opaque meshes. you can cheese that fragment overdraw, tho, if you put a duplicate opaque geometry inside of glowing things. you could even use invisible meshes (masked unlit) that just block in some depth values. yep
