I can clearly see the error in your screenshot, see the left wall.
It is not immediately obvious, which is why I specifically showed how to make it visible 
But since you managed to replicate it anyway, that shouldnt be of importance anymore.
Thanks for looking at this so quickly.
Currently the Lumen Surface Cache only captures instanced foliage that is using Nanite meshes into the Surface Cache. Check if they are black in the Lumen Scene viewmode to confirm. The reason we don’t capture non-nanite instanced foliage is that it’s just deadly slow. I think that’s why you’re seeing too-dark foliage when placed with the foliage tool, but not when those same trees are placed by hand.
Using Nanite for foliage works in 5.1 but has some gotchas, which should be documented in the upcoming 5.1 release notes.
@ Two Sided Foliage shading now looks good. Thank you.
There is something I don’t understand. All plants were placed with the “Foliage Tool”. These do not reflect back surface light. However, when I put an object on the scene manually, everything seems to be as it should be. Is this a bug or are plants painted with the “Foliage Tool” for performance not affected?
On the previous note of resolving noise from emissive lighting, is implementation of explicit emissive sampling planned for anytime in the near future, or has the feature freeze set in already?
As you know there are still some gotchas when using foliage and nanite.
Would it be feasible to introduce a parameter per foliageType or GrassVariety that would boost the indirect lighting of that instance?
That could be a workaround, although of course not ideal.
I have tried converting various tree species to Nanite and have had different results. In some cases the “core” is too light and gives the tree a “flat” look.
These are the Project Settings parameters used.
Another issue that I noticed when changing intensity on the SkyLight a green glow appears on the trees (in some species) which disappears with the movement of the camera (only with Lumen Hardware Ray Tracing).
It could be the right solution to bypass the problem. The indirect light boost could be regulated by a parameter that can be changed depending on the type of asset as I have seen that the various tree assets behave differently depending on who creates it.
I am also encountering black surface cache for foliage instances when using Nanite:
Answer here:
I redid the tests with the Rural Australia package tree model, in the previous test something must have gone wrong with the migration or conversion of the asset. The HD Ray Tracing lighting with Lumen and Nanite looks good on both the sun-struck and the shaded part but under the trees it is still very dark.
I’m not quite sure if feature requests are appropriate here, but is there any way to jury-rig the translucency radiance cache to operate as a sort of fallback for multi-bounce reflections? I know legacy RT supports using cubemaps as a fallback after n bounces, but Lumen’s lack of multi-bounce support is starting to chafe. I can’t use large metallic surfaces in scenes without screen-dependant GI due to screen-traces being multi-bounce.
We’ve found kludges and materialSwitch tricks to enable surface cache coverage in hit-lighting metallic objects, but some option for approximate multi-bounce would be much appreciated, even in an engine version after 5.1.
Hello everyone - is there a way to increase the tracing distance for the lumen reflections?
I haven’t found anything so far - from a certain distance to the camera, the reflections are hidden, which leads to almost black glass in the windows. I have increase “max trace distance” but the reflection distance decreases as a result - very strange - there is also Lumen Scene View Distance, but that doesn’t do anything for me.
That would partly depend-do you have HLOD set up?
Default lumen camera range is ~200 meters. For most scenes bigger than that, you can use epic’s far-field tracing paradigm that enables relatively cheap tracing against HLOD geometry. It only works with hardware RT to my knowledge though, so if you cannot use that in your project, you may be out of luck.
@jblackwell - hi, thanks for the tip - I enable WorldPartion, I set up the HLOD and put in the ConsoleVariable r.LumenScene.FarField=1 - unfortunately it didn’t change the visible reflection distance (and the workflow via WorldPartiton is for a relatively small scene is a bit exaggerated) - no idea how the developers thought it…
Thanks for raising this issue @Laurens_t_Jong
Extend Default Luminance Range is now enabled by default for new projects and I submitted a fix to add the toggle back in the editor for projects that have it disabled.
Hello! So our materials will go into zebramode if we try to render highres images. This is nothing you will see if you are not going for ultra-highres images.
It seems to be connected to:
r.Lumen.ScreenProbeGather.DownsampleFactor
in combination with resolution and a high Lumen Final Gather quality.
If you want to reproduce the error try rendering a 4k+ image with a very high Final Gather Quality and with a reduced screenprobegather downsample factor.
It seems to be visible on everything that isnt fully Rough. Clearcoat materials make it extremely visible.
Working with high resolutions and changing the downsample factor also fills up all the vram on my 24gb GPU.
Even after changing the settings back to a lower resolution and higher downsampling my vram stays full and the error is still visible.
After restarting the editor everything is back to normal.
This happens in 5.0.3 and 5.1.
I know this wont be an issue for most people but we want to do highres rendering using the movie render queue and we cant use TSR or DLSS.
We’d be very happy if anyone has an idea how to work around this issue. <3
Not sure if this is the appropriate thread for feature requests, but are there any plans for Lumen to support masked materials in the future?
I found the cause of this problem. As long as I turn off normals in my material. There won’t be these false bounces.
We didn’t get a chance to work on explicit sampling of emissive yet, although some of the work on r.Lumen.ScreenProbeGather.DirectLighting (experimental direct lighting through Lumen’s Final Gather) does overlap.
This is not really the Nanite thread, but try the new ‘Preserve Area’ option in the Nanite mesh settings. You’ll note that the tree leaves essentially disappear in the Lumen Scene viewmode when using Hardware Ray Tracing, without area preserving simplification.
Another issue that I noticed when changing intensity on the SkyLight a green glow appears on the trees (in some species) which disappears with the movement of the camera (only with Lumen Hardware Ray Tracing).
Thanks, we’ll try to get that fixed.
Thanks for pointing that one out. I thought we had fixed it. It happens when the Screen Trace goes slightly too far, and the next tracing method then misses the wall.
