I’m properly set to “scene color” with an emissive but translucent material, using an opacity of 1. Unfortunately, it’s still being picked up by the screen trace. The issue is that I can’t disable the screen trace, as it resolves various mismatches and other problems that occur without it.
Seems like there’s some bugs here tbh… I had screen traces picking up translucency when set to antialiased scene color, now they don’t pick it up at all regardless of the screen tracing source setting…
1 Like
This is problematic 
it would be great to have an option (or a console command) to disable emissive lighting calculations in Lumen.
First thing which I would try is to set r.Lumen.ScreenProbeGather.MaxRayIntensity 10. Lower values reduce GI energy, but are more stable. I find 10 to be a very good tradeoff for most games. It was even a default for some time, but lots of people complained about missing energy…
Then in order to reduce emissive from Lumen Scene you can just use the Ray Tracing Quality Replace Node.
Screen space emissive is harder. I would first try to set screen space source to Antialiased, as it results in more stable emissive.
In practice I find usually some combination of those 3 steps to be enough to solve emissive issues without much downsides, but if you’re really want to kill all emissive from screen traces:
- Use post dof translucency for emissive and set screen space trace source to scene color
- Modify the engine source code. Simplest would be to kill all screen space trace data based on some bit, like we do for thin two-sided foliage and subsurface shading models
3 Likes
Thank you for the advice 
r.Lumen.ScreenProbeGather.MaxRayIntensity 10 seems reasonable indeed, it’s definitely a good console command to know.
When I was helping to develop Corona renderer, we settled at 10 to be reasonable default when we first introduced indirect ray clamping (Max ray intensity), and our userbase at the time was mostly high photorealism ArchViz.
When V-Ray implemented its version of the feature shortly after, the default value was also 10 if I remember correctly.
Now Cycles in Blender also defaults to 10 since it got the feature implemented.
So I find it kind of funny that Lumen, which does quite a lot of light transport accuracy sacrifices to achieve high framerate and stability at the expense of it defaults to as high value as 40, when people doing high end VFX and archviz for the past decade were fine with 10 being the default in their offline path tracers 
IMO it’d be worth it to reduce it to 10 by default for lumen too
1 Like
unreal has autoexposure. which is not used in the film industry. makes sense to increase the value to get the range.
Lumen’s one is exposure relative, so basically we clamp rays to 40 * current exposure. Is it the same in Corona/Blender? I couldn’t find any details online.
I don’t remember to be honest but at the time there wasn’t any concept of automatic exposure. I will ask the developer about the main developer about exposure scaling and let you know.
This pulsing has nothing to do with Lumen. TSR/TAA does a subpixel jitter, which is causes pixels to shift very small amounts. Often this jitter is imperceptible, but in extreme edge cases these sorts of things can happen. This subpixel jitter is essential to how TAA works so I don’t think there’s really a fix.
You can give the tree a bit of animation, so it is impossible for the camera to sit in the perfect spot that triggers it. While a bit obnoxious, the artifact is actually a lot like what it really looks like to see the sun from behind a tree as leaves and branches cover and uncover more or less of it.
1 Like
(post deleted by author)
Is r.Lumen.ScreenProbeGather.TwoSidedFoliageBackfaceDiffuse broken?
I do not see any difference with this enabled or disabled.
Epic Games’ official developers use cloth material shaders configured to resemble opaque as a workaround. That is their solution atm.
After building from this repo, r.Lumen.Supported.SM5 is still disabled and read only.
Any ideas?
Typically, when a cvar is read only it means you need to set it from your ini file, you can’t do it via console.
2 Likes
There is a way to setup cvars for packaged builds - as example ini file that allow to generate distance fields/ hw rt at launch to not have 2 exe files? Ive tried to copy but seems game doesnt read when its moved to config folders.
What you have in your ini file, is what you get packaged as config for the game.
1 Like
I checked and it was indeed the same. The exposure multiplier of the max ray intensity was established once at the start of rendering of each frame. So yeah, looks like people were completely fine with value around 10. The visual quality difference is negligible but the stability and noise reduction is definitely noticeable.
3 Likes
Is everyone sure that r.Lumen.ScreenProbeGather.MaxRayIntensity works with the values mentioned above ?
I tried with UE 5.2.1 and 5.5.1 and same results.
There seem to be no difference between 40 and 10 and 1.
But the differences mentioned take place between 0.01 and 1
Actually even between 0.001 and 0.01 there’s a significant difference.
1 Like
Maybe you are talking about different things.
Screenshots could help.