I found a small “issue” regarding Lumen GI and Stationary SkyLight, it seems both aren’t compatible. All my SkyLights were Stationary, and when I disable Lumen GI through Scalability, my Skylight stops working and becomes black, but it works if I set to Movable.
That’s a great find, and is now fixed for 5.0 release. When Lumen is disabled by scalability it shouldn’t be affecting the rendering at all, but it was in the case of Stationary Skylight.
why launcher is ugly and source code is good ?
Hi , it looks to me that they are using different Engine Scalability levels. The one that’s too dark is using High settings, which doesn’t support multi-bounce GI, while the one that looks better is using Epic.
Check your Engine Scalability level under the Settings gearbox in the top right of the editor
Also can you tell me where you got that scene from? I’ve seen it a few times and would like to test it out
Thanks for your encouragement. We’ve been working hard on this (myself, Krzysztof, Patrick). It’s really a passion for us, to bring realtime GI to the industry at a quality level that’s competitive with baked lighting while being performant enough for many use cases. It feels almost impossible at times, but then we make a breakthrough and it becomes possible again.
For top Archvis quality make sure you set Lumen Final Gather Quality 4.
Hit lighting improvements are coming. We need to fix the Surface Cache to handle small objects.
Mirror reflections on translucency will be 5.1 hopefully. We couldn’t do it in time for 5.0.
Hi
Thanks for reply
I found that it is because using [use hardware ray tracing when available]
both gi and reflection are lumen
scene lit by the only skylight
raytraced skylight are disabled!
why [use hardware ray tracing when available] has this huge impact on lumen GI?
I will send you the project to investigate
also [Affect Distance Field Lighting] is not working on preview
EDIT: Scrap the “tree rambling” I just read that it didnt make it into PV1, this then only leaves subsurface stuff “broken?” again.
First of all, I am glad that we got an updated version for “testing for everyone”, so that not all the Feedback relies on people using Github and their narrow field of view regarding their own projects.
I am also thankful that we got lumen, it really helps a lot.
Regarding Lumen in “Preview 1”, its fine, except for… you know what im going to say now: Trees, Foliage etc.
Given that we are now in “Preview”, this needs attention. (Yes, I am aware that I have been poking you with this issue for a while now, but time is really running out now.)
Current state of PV1 regarding Trees:
These are all PV1 images and some effects etc. arent adjusted to the changes I made to exposure (to counter-act the tree-darkening), but “fixing trees” is out of my capabilities, given that I cant endlessly crank up exposure without it becoming an issue.
As long as trees are “in the sun”, it isnt too obvious, but as soon as they are somewhere “shady” or even partially under shadows, its trouble.
=========
So far, it looks good, no “big issues”, just some minor things that I need to double check before reporting back.
EDIT: Could it be, that subsurface GI is broken again, especially noticable in the bottom right image of my 4, given that it previously looked like this:
It should look more like this (from, i think, a january? github build.), given that the sun would create a lot of green light from the panels on under the roof?
EDIT2:
Yes, subsurface is actually broken again:
Only the sscreen traces from the actual material appear, but no lighting, unlike previous builds where it worked just fine.
Its the same project, everything on “Epic”.
Regarding Lumen in “Preview 1”, its fine, except for… you know what im going to say now: Trees, Foliage etc.
Will upload your project somewhere and send it to me? The trees are way darker than I’d expect with Lumen. We have over shadowing problems, but nothing that should make the outer leaves dark too.
GKan just sent me his foliage scene and now we are working on reducing the over-shadowing.
Lumen supporting Subsurface Shading Model was in Preview1, but not Two Sided Foliage. However, that generally only brightens up the trees a little bit, it doesn’t fix the dark core problem.
Yes, subsurface is actually broken again:
Is the sun hitting the other side of the Subsurface material (the skylight) and scattering through to the bottom side, and that’s what you expect to bounce lighting through Lumen GI? I don’t think we have ever intentionally supported that, so it’s a surprise that it worked before. It’s probably something we can add though.
I will create a “sample project” with a few of the trees for you, so that you dont have to deal with my 27gb game project 
give me a bit of time, please.
=======
To be honest, I dont know if this is an issue in the material, but given that all trees I have show this behaviour, some more, some less, and that my game isnt even the worst case due to a lot of white walls that should create plenty oy bounce-light… I have ran out of ideas.
The “dark core problem” I already investigated in the other thread: Lumen GI and Reflections feedback thread - #227 by Yaeko
Lumen “creates” blackness at certain distances, causing (especially my trees) to show these problems, since they mostly have the necessary distance between leaf-panels for this issue to appear.
This issue also appears against a white background when the leaf-material is put onto a plane, as can be seen in the linked post.
Yeah,
Technically, the subsurface panels should behave like a “light”, and they did so in an earlier github build, and I was happy about it in the other thread
Its not the end of the world if this was uninentional and wont be in 5.0, but by accident it seems, you already got it working in the past, so it would be really nice if you could bring it back in the future.
skylight in 5.0 lumen early access (Good Result) near to path tracing
skylight 5.0 pathtracing
skylight in 5.0 preview lumen without hardware raytracing
skylight in 5.0 preview lumen with hardware raytracing (bad result ceiling and floor are black !)
eatly access is much more better than preview in quality
but preview has better performance and fps
Subsurface scattering works fine with direct light and local lightsources but I also dont get any sss from lumen. I’m still using my workaround from EA2. Cube capture the scene on lighting change, using the result in emissive on my foliage shader. Of course this is not very accurate and works best in exterior scenes.
Does anyone know how to stabilize lumen in these areas using some settings?
Basically heavily overlapped geometry is sort of flickering with samples when not exposed to direct light.
maybe closeup shows it better? Some close areas work better than others… not sure what can i do about it. Accuracy there clearly isn’t important but that flickering is distracting
Hi!
I’m struggling with grainy noise in AO/light-shadow transition areas. I’ve fiddled with settings, but seems none of them are helping. I’ve seen someone with similar effect and @ suggested these parameters
r.Shadow.Virtual.SMRT.RayCountDirectional=8
r.Shadow.Virtual.SMRT.SamplesPerRayDirectional=4
Bumping those unfortunately don’t seem to affect grain - mostly affects how ‘soft’ shadow edge is.
How far did you push those values? For me, settings of 32-64 seemed to make a positive difference, but depending on shadow complexity, can also introduce other artefacts.
edit: try combining this with r.Shadow.Virtual.SMRT.AdaptiveRayCount 0. It helped achieve a more stable and cleaner image in my case, obviously at the cost of performance.
Is there any plan for lumen to implement multibounce reflections? I remember that being listed in the original lumen live stream as one of the features that would be incorporated, but that was quite old and I understand it’s most likely low on the list of development priorities.
Is this something that will be improved or is it going to be a lasting limitation of Lumen?
The issue seems to occur very reliably when lights are placed within ~20cm of surfaces. Making it difficult to get good results out of volumetric scattering from lightsources as the light needs to be placed too far from the emission source to make visual sense:
Using the r.LumenScene.DirectLighting.ForceShadowMaps 1 resolves the issue, but I have to assume there is a tradeoff being made there, or it would have just been enabled by default.
Try this: r.Lumen.ScreenProbeGather.Temporal.DistanceThreshold “value here”
I believe 30 was default. In a testscene i did in ea2 i just pushed it out to a 1000 and it helped greatly with shadowed foliage.
This is a temporary sollution until final 5.0 but hey whatever gets the job done
Hello there, thank you!
About the weirdness when not looking at the Spotlight Source making all GI disappear, I couldn’t manage a way to reproduce it consistently.
Actually I just noticed that it is totally inconsistent, I spawned and despawned it several times (in a packaged build) and some times it worked, and other it didn’t. Even after tweaking all light parameters, I didn’t find any which could be causing that. On Editor it doesn’t seem to have this problem, it always work.
Sorry I haven’t found a consistent way to reproduce this, for now that’s all I’ve come up with Anyway, an important point to mention is that my Spotlight is dynamically spawned at runtime.
Yes set:
r.Lumen.ScreenProbeGather.ScreenTraces.HZBTraversal to 0
and then if it doesn’t help completely, keep increasing the value of:
r.Lumen.ScreenProbeGather.Temporal.DistanceThreshold
This cvar defaults to very low value, but you can keep increasing it until around 100, before it starts to cause severe artifacts.
However keep in mind that both of these, especially the latter one will be a bit of a tradeoff. You may lose some accuracy in some simpler areas which don’t have the dense foliage geometric detail, where lack of GI accuracy isn’t as visible.
You may want to start by disabling “affect distance field lighting” on that grass though, and only resort to testing the cvars afterwards.
Man…
it WORKS! Looked around scene in both exterior and interior and haven’t noticed any problems with it around small objects etc…
Thank you.
