@Daniel_Wright
software lumen is completely broken in 5.5 DX11
While trying to replicate this, I found a bug as well - possibly related.
Hit lighting GI does not respect the indirect lighting intensity slider for lights. It works as expected only when set to surface cache or hit reflections.
I did not notice any unexpected energy loss or gains in my tests as long as indirect lighting intensity was set to 1.
Also one bit of feedback that has bothered me for a long time. Fully metallic objects eat all light that hits them and don’t contribute anything to indirect lighting, despite the fact that they should be bouncing light into the scene.
If you shine a spotlight onto a mirror, all of the light just disappears into the void.
You can kind of circumvent this by using the raytracing switch to make the object nonmetallic for raytracing, but this has a side-effect that it would also appear nonmetallic in reflections.
Default Lumen:
PT:
RT Quality Switch Manually Reduced Metallic:
Is it possible to use Substrate to build a two layer materials ? One for the metallic look and properties and the second layer non-metallic for light bouncing ?
Or maybe two different objects in the same position ? With different checked properties - something like - one invisible but used for light bouncing.
Just out of curiosity, can you remind me which level this is? I feel like I saw it on one of the lumen Livestreams a long time ago.
Is it worth using card capture switch in expensive materials? So that Lumen can evaluate a less complex version of the material when capturing the surface cache?
I don’t see why not. The little performance gains might add up. But I’d probably save it for an optimization pass later on if needed.
My main use would be for disabling features that Lumen card capture doesn’t properly work with.
I’m not a light expert, but my assumption was that any reflected light off metal would be caustic reflections only, and since lumen doesn’t do that, it’s ignored, BUT shouldn’t even semi rough metal caustic reflections be treated as normal diffuse GI light bouncing?
We disabled Lumen in DX11 alongside the push towards HWRT by default. Now DX12 is required for all UE5 features like Nanite, VSM etc. What’s your use case for using DX11? At this point DX12 should be in a pretty good spot.
Thanks, will fix.
They shouldn’t. Yes, Lumen Surface Cache treats all objects as fully diffuse, but all metals should be approximated using EnvBRDFApproxFullyRough()
. It’s just an approximation so sometimes it’s too dark and sometimes too bright.
Here’s an example of a fully metallic sphere:
i think @BananableOffense means this bounce back.
and… (this is 5.5) it does work. mostly on plane geometry. it’s just scattered alot, when shot at curved surfaces. i done the laser on the copper ball before, too.
also… lil glitch i just found. (it’s not lumen but lighting related) maybe you could pass it along.
raytraced directional is misaligned in a retro game setting. not that it’s usable with all the temporal shadow noise but even on full resolution (without any aa) a slight ghosting edge is noticable on the character.
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?
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.
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.
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.