Lumen GI and Reflections feedback thread

So I was testing the new light function atlas feature (using 5.4) and noticed that RGB light functions only render the red channel into the surface cache. Just wondering if this is something that will be improved in the future?

EDIT
ANSWER: Sebastien Hillaire responded to my question in the tutorial thread confirming it was a bug that will be fixed :slight_smile:

quote from the tutorial

… it is possible to make the light function atlas account for colored light function materials. This can be enabled using r.LightFunctionAtlas.Format 1 (requires editor restart for shader recompilation). When set to 0 the R8 texture format is used, otherwise R8G8B8 is used.

How does this interact with the lumen hit lighting GI system? Will that facilitate clean GI in reflections, or does it just resolve the limitations of the surface cache in first-bounce GI?

5.3.2 doesn’t do the clean reflection thing, yet. disabling surface cache in the reflection removes the noise. the unshadowed skylight is a global ambient boost to push light into the irradiance probes. basicly a “fake” gi/boosted irradiance in the interior. actually a very performant “cheat”. needs artist attention tho. tweaks.

Quite interested about seen a comparison. Unfortunately I have no my test scene available and I will need to wait to test by myself or to see the example posted by a good samaritan :innocent:

I achieved no appreciable differences with this CVAR in my MRQ. The only viable solution at the moment for MRQ is Path Tracing but this takes a very long time! What tweaking are you talking about?


Hey does anyone know why I’m getting this weird reflection error in my level with hardware lumen.

This is unreal 5.4.2

The level is made up of a bunch of instance static meshes (not hierarchical). You can see one of the wall segments (which is still reflective) behind the reflection of the player character. Each one of these meshes has the same material which is a simple 0 roughness, 0 specular, 1 metalic.
I have set max reflection bounces to 3 in this case, but got the same effect on 8 (and it likely applies to everything inbetween). It didn’t happen when it was set to 1.

In case it is not clear what you are looking at, the should-be reflective walls have become grey with black specks in the reflection. Different segments will go in and out of this state depending on viewing angle, but not in any consistent way.

Does anyone have any experience with stuff like this?

That looks like a precision issue of some kind- are you far away from the world origin by chance?

Hi @Krzysztof.N ,

Giving some feedback:

  1. With Two Sided materials, GI won’t work anymore. I noticed this because some two sided geometry (thin faces) was giving me problems when rendering with path tracing:
    pathtracing

The problem goes out with 2 sided mats, but then, Lumen would be broken. It seems that this is happening for some years now: https://www.reddit.com/r/unrealengine/comments/vep5a3/how_do_i_fix_these_dark_bugs_on_the_bed_path/

  1. Another issue: in 5.3, you could set a value of 0.75 (for example) for Final Gather Quality in PPVs, gaining some FPS with almost the same quality. That same value in 5.4 will kill GI in many areas, making shadowed areas almost totally black. If you put a value of 1, instead, the difference will be huge.

Thanks!

Tested it to make sure, but sadly even at (0,0,200) the same thing happens.

With hit lighting surface cache is only used for the indirect term (shadowed skylight and N+1 bounces). r.Lumen.HardwareRayTracing.LightingMode 3 will force unshadowed skylight instead, basically removing any surface cache usage.

PPV takes precedence, so you need to clear hit lighting from the PPV and then try this CVar. You can do all this stuff in the viewport, so that you don’t need to go through this long iteration loop with MRQ.

This looks like mismatch between RT representation (Nanite fallback mesh) and rasterization. Ray starts on the screen pixel (rasterized geo), but then we trace against the low poly Nanite fallback mesh and ray may self-intersect if it’s too low poly.

Usually this isn’t an issue due to screen space traces, but I guess you disabled them. In that case the only thing left is biasing. For GI there are two, one for one sided and one for two sided geometry:

  • r.Lumen.HardwareRayTracing.SkipBackFaceHitDistance
  • r.Lumen.HardwareRayTracing.SkipTwoSidedHitDistance

In general it’s best to increase Nanite fallback mesh quality inside the static mesh settings. Especially if this is not targeting consoles. Alternatively you can play with biases (apart from GI, there are a few more for other parts of Lumen). You can also try r.RayTracing.Nanite.Mode which will ray trace against Nanite geometry, but it’s pretty slow and only streams in Nanite geometry based on the rasterizer so e.g. it may be still low res in reflections. So may not be a best choice for real-time, but certainly you should use it for the path tracer.

Follow up,

It does seem to depend on the distance between instance static meshes, rather than the location of the instance static meshes in world coordinates.
I.e. is the instance static component has meshes that are 12000 units apart from each other this happens.

Any ideas on how to solve this?

Standard Lumen Reflection:


Mode 3:

As you can see, right out of the box there are some problems. First, if you’re using sky atmosphere, the skylight will be tinted based on the sun position, which will cause the scene to absorb that color incorrectly. Second, there is no GI/AO of course.

With some hand tuning, you can adjust the skylight color to match the scene…

Here I’ve adjusted the skylight color and settings to match the scene reasonably well, and also added a fake distance field based AO in the material of the raytraced view only. The missing GI can still be noticed, like the top right wall which should be bouncing orange light in the reflection, but obviously cannot and so instead the DFAO is showing up.
And for comparison again, here is lumen. Noisy, but with proper GI.


I could definitely see it being useful in certain cases but it needs special consideration.

3 Likes

It’s definitely good to have this sort of trickery on-hand, but I personally feel like the setup costs would outweigh the benefits relatively quickly. Perhaps if you need specific behavior for real-time, but the main advantage lumen has over the PT is interation, which this would make much more difficult. I suppose it all depends on the content.

1 Like

are there other variables required to to get lighting mode 3 to work? cause it does not work on my end. whether if i have or do not have a skylight in the scene.

In UE5-Main it’s now controlled by r.Lumen.HardwareRayTracing.HitLighting.Skylight 1. In UE5-Main PPV takes precedence, so if you enable hit lighting through PPV then you need to uncheck it for this CVar to work.

1 Like

forgot to mention: this is in 5.4.2.

(i have multiple versions installed. i know the 5.5 flag.)

edit: it works if i disable the ppv. sky boost to color match. it’s not doing well for outdoors tho cause the skylight is a direct hit and interacts with fog. sky reflection results vary. hmm.

sample fog w/o skylight

sample fog w skylight

no sample fog w skylight

1 Like

Yeah it’s not ideal but it’s definitely doable for specific cases. Architectural visualization comes to mind as a case that always wants to put perfect mirrors in all white rooms, and can probably justify spending time baking and faking a thing or two of they really needed to eliminate the noise.
For most other applications, the situation can be entirely avoided with more careful art direction.

PPV takes precedence over this CVar, so you need to uncheck ray lighting mode in PPV for this CVar to do anything.

got it. ppv is applied every frame and resets it. logic.

1 Like