Ok. Some screenshots.
You can see in the lower part of the screen the r.Lumen.ScreenProbeGather.MaxRayIntensity with different values.
The screens with the values 0.1 and 0.002 - have drastic changes.
2 Likes
As far as I know, Max Intensity is something like a clamp. The super low values are almost off, but between 99 and 2 you may not notice difference because the emissives themselves were already weak, let’s say “below 2”.
Remember; it’s a Max value, not a multiplier.
That’s helpful . It seems I misinterpreted was what said above about that cvar.
1 Like
I know this is a old post, but how can i get these translucent shadows in Lumen (unreal 5.4/5.5)?
Is thre a cVar option to enable it?
This is a translucent material or a masked material? If translucent, lighting Mode is Surface ForwardShading or Surface Translucency Volume?
In PostProcessing, the translucency mode is raster or raytracing?
This light is megalight option enabled? Default (raytracing shadow)?
doesn’t matter which surface shader you use for the “post” translucent pass. it’s the late one. if it’s flagged as translucent and the cc is on, it will render a duplicate in the opaque base and shadow pass with the opacity mask anyway. that’s what matters in this case. and… ofc… megalights is on.
the expense…
1 Like
Tested here and didn’t work (UE 5.5)
Tested with some different opacity masks bitmaps, spot light and directional lights
(megalights enabled, default)
r.raytracing.shadows.translucency 1 - did not work until now
(project uses lumen hardware raytracing)
sorry about that. seems i checked the wrong lamp for the 1st screenshot. it only does shadows when the light is rendered without mega. so… it’s a traditional shadow map or raytraced if desired. still works if you need the effect. for special cases of gameplay or visuals.
also note: @Krzysztof.N this was around that time when masked materials were working correctly in megalights. a piece of shader code you could revisit and merge if needed.
Ray Traced Shadows and MegaLights are separate systems. At the moment only Ray Traced Shadows support translucent shadows.
Thanks
Works only with RT shadows (Megalight OFF) like Krzysztof.N said
Below, a quick test with 3 scenarios. I thought the impact on performance would be greater (Archviz projects).
That tenuous sun light through glasses becomes better with translucent rt shadows
Just wanted to follow up that the cvar does not appear to have made it into 5.5.1 or 5.5.2
let me also state that while vulkan is faster than dx12 … it is by a very small margin as DX12 performance drastically improved with avg RHI cost dropping by an entire 2ms
1 Like
I hope so because DX in general is crap.
cinematic glitch in raytraced reflections. the preintegrated skin subsurface term glows a lil bit in raytraced glass or mirror reflections.
we know cheats tho. : )
for that matter (it’s not lumen), but… i’ll try to find a cheat for the skin fuzz. the edge on the cheek doesn’t look right. it’s like a terminator artefact. raytraced directional lamp. can be cheesed with more source angle, but destroys the dirty glass shadow, that does not fully exist yet on that glass pane and the floor, tbf. : )
Lumen + HWRT + Landscape = tons of light leakage.
I’m not one to throw Epic under the bus but honestly, WTheck… It just doesn’t-work…
Using HW raytracing #2
Up close and personal; the sun is behind the ridge and should not be illuminating those parts. Notice that it also impacts the (nanite) grass:
This behavior is present in 5.5.2 and 5.4.4. Lumen doesn’t have to be using HW, just enabling ‘support hardware raytracing’ is enough to make the issue preset.
Enabling/disabling Path Tracing has no effect. I’ve also run the gamut of toggling ray-traced shadows on/off for the landscape itself, the landscape material, in the Project-settings. Two-sided settings on the landscape and/or material make no difference. Using Nanite on the landscape makes no difference either but I will say that at least the shadows on the nanite (vs landscape/heightmesh) are MUCH crisper, for whatever that is worth.
It’s not the material either as I can throw WorldGrid on it and get the same behavior.
I have to honestly ask: is this the expected behavior or am I troubleshooting your product? When I see things like this, and I take the time to figure out what I am not doing wrong, it makes me feel that I am wasting my time w/this engine. Especially when something so basic/fundamental as ‘blocking-light’ doesn’t function across multiple versions.
EDIT: even w/SW raytracing there is still leakage:
I’m not trying to sound pissy/insulting w/the above, I know tonality doesn’t come across well in text; I’m just frustrated because the use-case here is so simple.
If you need a testcase, take the heightmap provided in my tutorial as it’s the same one I am using here. Default project, default settings, enable HWRT. Make a landscape, throw a directional light (or UltraDynamicSky) and just-look.
ref - Implementing a landscape with a virtual heightfield mesh. | Community tutorial
When HWRT is enabled, there are some new distance thresholds you have to watch out for in the settings and that’s what you’re seeing. With HWRT on, slowly descend toward the level and you’ll likely see the lighting pop to the correct levels.
Also, landscapes are single sided and don’t do well when the light is close to the horizon. (probably distance field related and SDFs don’t really like thin geometry)
Inaccurate, hence why i provided the up-close pic.
If anything, there’s another bug there. In SOME cases, unsure why, seems come and go depending on me restarting my editor, but leaks MIGHT disappear when I go closer, but then they stay-gone when I go further away…???
Restart the editor and then the issue re-presents; there is no consistency in some cases.
That is not close up, you’re probably a kilometer in the air.
Also that behaviour you’re describing sounds like some VSM issue with caching.
