On that note, does that mean SWRT will be deprecated in a future release, or merely that it’ll be a fallback path in certain extraordinary cases?
1 Like
About the character halo, try disabling the cvar of shadows denoiser.
I think it’s a bug I reported many months ago, if you can confirm.
yep. is a denoiser artefact. that sampling kernel needs a lil tweak, perhaps.
Thank you for confirming.
Reported a year ago in this same thread. 7 months ago (Unreal Engine 5.4 Preview - #8 by Miguel1900) they added to the bug tracker (Unreal Engine Issues and Bug Tracker (UE-200307)) and was set to be fixed in 5.5.
It’s still pending, then @Matthew.Ivey
I think this is a very must have issue to be fixed. I can’t understand why people usually don’t notice it and why it’s a so low priority issue to be fixed.
with aa or tsr it’s barely noticable. can be pushed back. i just noticed the extreme right there, helping this low res game thread. targeting low end hardware reytracing should maybe not even be enabled. rather use established methods for the directional light or bake it. retro rt looks cool tho. lil surreal. megalights is a lil temporal, but it holds up pretty nicely in low res.
Yeah, this is what I’m referring to. You’re right it looks like it does work on 5.5 if screen traces are off, and if lighting mode is set to surface cache or hit lighting for reflections. Screen tracing GI and full hit lighting will both eat all of the light.
edit: collapsed photos to conserve space
Setup: Point a spotlight at a fully metallic surface
Path Traced result: Light bounces off the mirror into the scene
Default Lumen Behavior (Surface Cache + screen tracing, in this case): A tiny smudge of light slips through
Surface Cache w/ screen traced GI off: Not bad
Hit Lighting w/ screen traced GI off: all lighting has been eaten
Hit Lighting w/ metallic overridden in RT and screen traces off: Light is restored
So I guess it’s mostly a screen tracing issue, but also a bug or limitation in the new hit lighting. Obviously this case is a bit artificial, but it could be a problem for certain types of environments with lots of metallic surfaces such as sci-fi style interiors.
Perhaps, but the lighting disappearing completely is worse than letting it be treated as rough - but it seems this behavior is probably unintentional as it seems is treated as rough on surface cache.
I don’t think so, because all of the relevant mesh settings or material properties I’m aware of impact both reflections and GI together.
1 Like
they don’t eat the light. it’s just limited irradiance probe resolution. i did the same thing on one of the blue cubes in 5.4 i think. just retesting. it needs some amounts of cds or lumens. but it does bounce even on smaller objects. albeit it will be culled eventually cause the irradiance probe grid will shrink in size. it’s a resolution thing and how much can be gathered and scattered. gotta be close.
dunno if you ever used the “r.LumenScene.Radiosity.VisualizeProbes 1” command. this is the lit stuff.
1 Like
Hit lighting and screen tracing absolutely do eat the light.
Significantly scaled up the mirror, massively increased the brightness of the light, and with hit lighting GI enabled, no light is bounced into the environment. It only works as you describe when GI is set to surface cache. Screen traced GI is off here, or else even more light is removed.
What is odd is that the light is bouncing in the reflected view, but not in the main view.
Yeah, I used to radiosity viz extensively when coming up with the noise-free indirect lit reflections post a bit ago.
Here is the result when using RT switch to turn off metallic.
Screen traces on:
okay. i dunno what screentraces you referring to, then. there are lots of them in the engine cvars. it’s not a reflection. that’s for sure. it’s an irradiance bounce. and it works on my config. default with everything. hmm…
Default screen traces eat them. But specifically yes its irradiance, as disabling irradiance traces brings it back as long as GI is evaluating surface cache and not the hit lighting. If metallic is even slightly less than 1, it’ll start bouncing at least some light into the scene with hit lighting. But at 1, it is fully absorbed.
Hey, SPEC:
5.4.4 - i7-8700K+RTX 4070 Ti Super
Issue can’t be recognized in Editor Pie, (need to be Game) - also same problem with DoF
Hardware RayTracing Lumen setting:
Foliage Issues that comes with some sort of “shadow movement” also there are similiar issues with Depth of field on 50% screen (DLSS ultra performance makes things even worse).
As you see Cinematic scalability fix a bit those issues and more screen %
Would be cool to use this feature with 50% for DLSS ultra performance on Epic setting. I can provide DefaultEnigine and PostProcess if needed. If there need to be switching something in material in foliage please let me know.
All the best!
Pozdrawiam!
yeh. looks like a side effect of raytracing dense foliage and being rng. sometimes the rays get out and sample a lit probe. sometimes it just hits the underside of another “leaf” polygon. and being in “shadow”. in software lumen most of the leaves are non existent in the sdf and rays get out to shine. hmm…
1 Like
There is an issue with Lumen, not sure if its still in 5.5+, but in 5.4 its definitely.
- if you have small moving objects (I had a bunch of 10x10cm cubes following splines as decoration)
- Lumen will after some time “break down” and start to “flicker”. (can take a few minutes to appear, but then Lumen goes completely crazy as if it is regenerating its scene slower/constantly, making this visible.)
- This also happens when the objects that move dont have a Mesh Distance Field and are effectively removed from the Lumen Scene due to this.
PS: Nice to see this thread still going, and Krzysztof still being here with us 
1 Like
I have seen this a few times with using poly-per-blade type grass where large patches start strobing.
A video always helps. An isolated-issue project, even more.
But with Lumen hardware raytracing - distance fields are not used.
but I am running software lumen.
I dont have one right now, and no time to make one at the moment, just this Screenshot of what they looked like (with lumen still working as intended):
Its literally just cubes moving along a spline, with an underlying “factorio logic” for efficiency reasons. (easy to replicate if performance doesnt matter.)
Tried with MDF, without, ISM, normal meshes, etc… but never could resolve this, and then scrapped it. (That was like 6 months ago, and I was really fighting with 5.4.X in general… its one of those “just skip it”-versions.)
That said: I could isolate it to those cubes moving around → no cubes, no problems.
I assume: they cause a lot of updates and that somehow overwhelms lumen over time, because they “accumulate” somehow? (maybe some cache not being cleared fast enough? idk.)
I also remember it happening faster the more cubes there are, but dont quote me on this.
those seem to be small objects that may hit the bottom of the probe resolution and how often they are “captured”. also… that’s a repeating pattern. i’d guess at some point the repetition makes it’s way into the temporal data and it ends up fluctuating. it’s like an interfence pattern. at some point it hits equilibrium and overlaps and creates high peaks in the waveform. something like that.
what happens if you change the distance inbetween the cubes? or vary the size and distance. or vary the lumen update rate to counteract the repetition. hmm…
I noticed in this picture you increased the probe density a lot compared to default. Does it help with the quality ?
I found two cvars dealing with probe density and their “blurriness” or something but no matter how much I changed those, the quality did not changed to a great percent, More like plus minus 10%.
sry to say, but… this is default. it’s just a small distance. literally just 3.5 meters of travel for the light. maybe 5 meter and something from the camera that manages the grid size lod.
the only thing that is maybe relevant and non-default is the exposure. it’s not autoexposed and i eyeball the light levels. this is maybe not accurate of photorealistic, but works in most cases and my render style.