5.2 Lumen still creates way too much Ambient Occlusion? with bushes that have a somewhat complex geometry.
Even in overly bright scenario (unfinished arhictecture) the bushes are way too dark.
Do we have a fix for this, especially since the bushes share the base-material with the trees.
Just spitballing here - but could you alter the opacity mask in the lumen scene only, as to make the leaves thinner and more stochastic samples will pass through?
Edit: I tried it myself by altering the material in lumen card captures as well as with the raytracing quality switch but didn’t really see any change in overall brightness level - however I don’t seem to be getting over-occlusion in the first place. Probably still worth a try.
I figured out by now, that it has to do with the distance to another surface (and since they are low on the ground… yeah, bad luck):
Looks to me, like its really the ambient occlusion going nuts, since the floor is white, it shouldnt cause any issues in terms of “light disappearing”.
Need to think about ways to work around this issue, since it is mesh based and not a material issue.
EDIT: I found a fix.
What is needed:
This box is then put into the “Distance Field replacement Mesh” within the Settings of the problematic Bushes. (Unlike what one may expect, it doesnt replace the Mesh, but just works like a “cutout”. (Epic should rename this…))
Since the Box is offset from the ground, we do not have a MDF there anymore, and Lumen doesnt do weird things with the AO anymore.
Clearly visible, that the right bush is darker and has more AO than the left one, with the Box in the background:
How this looks in the Mesh Distance Field view then:
Is this a stupid fix?
Yes.
Does it Work?
Yes.
PS: completely disabling MDF for a mesh like this doesnt work, it looks weird since Lumen doesnt “see” it anymore, you lose all AO etc.
Guessing that’s because Lumen skips screen traces for two-sided foliage now, and if it has no mesh distance field then it won’t get hit in the Lumen scene either.
For the glass, the first thing I would try is making it a seperate mesh and seeing if that makes a difference.
Secondly, what blend mode is your foliage on? Is it masked geo, or genuinely translucent? Or two-sided?
Hi! Thanks for your reply! They are all translucent, thin translucent, surface forward shading, non refractive materials. For example this cone
Thanks!
Ah, I see. Lumen plays with translucency in very non-traditional ways, and I’m not even sure to what extent translucent objects are visible in the lumen scene. EIther way, I would recommend changing your blend mode to masked, and your shading model to two-side foliage, and seeing if that improves things for the trees.
Off the top of my head, I don’t think that translucent objects are in the lumen scene at all.
That said, I 100% agree. Use masked two sided foliage. Translucent materials make far too many compromises in quality and performance to be used for anything where it isn’t absolutely needed.
In the 5.2 P2 the Sub Surface materials are reflected not black (nice!). The Refraction parameter in the shader is disabled (why?).
You are right. I was testing out the NVRTX branch a while ago and confused their handling of translucency with the stock version. The decision to not include translucent objects in the lumen scene makes sense for many reasons, but I am dissapointed by lumen’s (apparent) lack of support of Niagara particles in reflections, at least from what I’ve seen. Let me know if that’s anyone else’s experience, please.
Can you use lumen to capture reatime reflections onto a NPR shader or Post proccesing shader with toon shadows and outline being subtracted?
We did try VCT, but with VCT any wall below 3 voxel footprint will leak due to bilinear filtering if not placed exactly axis aligned and snapped to voxel grid. In the 4rd clipmap we are talking here about 3*(40k/64)=3744 UU thickness, which is quite impractical for walls, not even mentioning things like doors.
Noise is indeed an issue and we need to solve it. In the meantime you can add more direct lighting or try sky leaking to make life easier for Lumen.
If you have your DF set to two sided - checkbox in static mesh editor or two sided material placed in slot, then it will go though a special code which dithers DF traces and provides partial transparency.
Screen space hits will be also skipped on pixels set to Two Sided Foliage or Subsurface shading model.
Noticed a weird dilation of hard edges on meshes in reflections in 5.2 P2.
I’m probably missing something but I can’t see any difference besides light transmission. That said I’m currently quite pleased with the state of lighting on foliage. Reflections on the other hand can be problematic.
Here’s a static mesh with TSF (left) shading model showing the aforementioned screen trace dilation issue compared to a default lit material also showing trace dilation (right).
TSF w/ screen traces off (left), no dilation.
TSF w/ screen traces on (right), dilation from screen tracing on
Is it possible to have a per mesh or better yet material option to skip screen tracing lighting and/or reflections (preferably independently)? I’m often quite happy with them, but there’s usually a few problem meshes and materials and it feels like the only solution is to disable traces entirely which is a bummer.
I see, thank you for explaining that to me, much appreciated. As your team does its’ good work, I’m also starting a thread where I’ll be writing down any good hacks/CVars I come across that could also facilitate better reflection behavior under certain circumstances. Just to provide a potential resource to devs who are looking for stopgap solutions.
Even with this, Lumen still treats the bushes significantly different from the trees, while both use the same material.
I am very sure, that it is the distance to another surface causing this, not the plants themselves. (which is why my “box fix” kinda works.)
Yes, please! keep us updated 
Hi @Krzysztof.N ,
Is there any way to control (in any way, like intensity, radius, contrast, for example) the ‘AO’ generated by Lumen? Previously there was a cvar which was useful to slightly tweak the AO (something like containing ‘bent normals’, but not sure), however it doesn’t work anymore. Anyway, even if still working, any additional cvar related would be useful too.
Thank you very much!
Just a quick FYI to the lumen team: the surface cache is still absolutely destroyed by the enabling of r.RayTracing.Nanite.Mode 1. I’m not going to claim to know what’s causing it, but it is interesting that a change in geometry is causing issues, given that the surface cache is projection-based and can facilitate variable surface representations.
Normal lighting
