Lumen (at the moment) doesn’t have a good sampling strategy for skylight and traces a small number of rays per pixel, so it will miss bright spots representing sun causing overall loss of energy. It has also relatively low spatial resolution, so it can’t achieve sharp shadows like UE path tracer.
Your images have larger differences. It may be because of the HDRI backdrop which isn’t supported by Lumen. You can check in Lumen Overview visualization what Lumen sees and if it sees proper skylight or something broken. Best would be to place that cubemap directly into skylight instead of using HDRI backdrop. Then for even better results you could extract bright light sources like sun from the cubemap and replace them with analytical lights.
Yes, SLW has a separate depth pass and we use last frame’s depth buffer without it. Fundamentally there are two layers in the scene now and we would need to denoise and reproject both of them, which is too expensive, so we did something in the middle what works in most of use cases.
Also SLW isn’t a good substitute for transparency, as it’s limited to very specific usage. Just like its name suggests - Single Layer Water :).
If you want the path tracer to match lumen you’ll want to paint out the sun from an HDRI and it should be pretty close. It was the same way with lightmass.
yep. in cycles (for example) i’ve been using a sky gradient/colorramp world shader ever since. indoors it’s pretty gnarly. even light portals don’t do it justice if you go for the good stuff. gotta fake the windows. and i’m still putting a sun lamp in the shots if i require hard shadows. it’s good and fast.
Thanks for the tips guys! Our aim is to provide a kind of automatic solution for the users where lighting “just works” without much fiddling required by casual users. We will probably go with an additional directional light for Lumen and then when rendering with pathtracer, we will just turn it off to avoid the duplicated sun light.
Please correct me if I’m wrong, but the skylight is still handled exclusively via the surface cache due to the expense of integrating a hemisphere in real-time?
Is there any good rule of thumb for how ‘big’ or ‘broad’ detail in the skylight can be while still resolving well? I remember having a conversation a while ago about whether or not lumen could pull off the same trick as Half-Life 2 (IE having very large structures exist in the skybox exclusively to cut down on GI distance problems).
It’s quite noticeable at a certain distance and very distracting in movement. Anyone know something about it?
EDIT: an additional question about HDRI not supported by Lumen… but it’s like it’s working for me, isn’t it? (With its sampling limitations, of course):
Surface cache only handles 2+ bounce (assuming that recursive reflections are disabled). So first we trace a bunch of rays from pixels. Ray which don’t hit any geometry will sample the skylight directly. Rays which hit something will lookup surface cache where we cache the rest of the ray path after the 1st bounce. Similar surface cache is what you see in reflections.
Certainly placing light sources like sunlight isn’t recommended, as Lumen won’t be able to discover reliably that single very bright pixel. As for the distant stuff - as long as it doesn’t need correct parallax it should work fine, and likely better than not having it all in GI or reflections.
I never saw anything like that before. Is this Lumen reflection issue or something with translucent sorting? Like does it happen when you disable Lumen reflections? Do you have some repro?
HDRI places a big mesh with HDRI as a texture on it. Sometimes that mesh has correct surface cache coverage, sometimes not. You can check it in Lumen Overview whether Lumen sees the same skybox as you expect. On the other hand placing that cubemap inside the skylight will always work, as it’s just a cubemap which will be sampled on any ray miss.
I have also noticed something strange with the global lighting, but wasn’t able to repro it again (it happened me twice, with that scene, just after fixing the exposure values, so maybe it’s related to exposure): sometimes, after reopening the project and/or (not sure) the map, or duplicating the scene, the global illumination was quite more darker, if you can try some random reopening or duplicating.
that’s a depth sorting artefact. one of the pitfalls of translucency. it traditionally has no depth, aka does not write the depth, but reads it to decide if it covered up or not. the further the planes are apart the further away the artefact appears. shows you the buffer precision for z-culling. the artefact/effect is clearly visible on a sphere. i’m kinda puzzled how exactly it determines it’s covering up the backface. hmm that’s a dig into the shaders.
I see. It’s due to a too loose depth test when deciding which translucent should get front layer reflections. At the moment it’s controlled by r.Lumen.TranslucencyReflections.FrontLayer.RelativeDepthThreshold and you can make it lower to reduce those artifacts, but we need to make a better test here based on the variable depth buffer precision instead of a constant distance.
Yap, the constant distance is a little unconfortable.
I have find a value of r.Lumen.TranslucencyReflections.FrontLayer.RelativeDepthThreshold 0.00001 works fine to void this, but it makes dissapear some glaze from the glass ar a certain distance too, but very little noticeable. It has also a weak reflection of the environment.
I have tried too a value of 1 (less of this, will generate the “clip plane” when near the glass) and it has a higher “mirror” effect, reflecting the environment too much, maybe. It will also eliminate “background” reflections; for example, a pool behind a window.
found a lil thing in my “torture” map when i re-enabled the rgb cubes. attempted a beauty shot with screentraces. i dunno how exactly they work, but… in both cases the to be reflected ceiling surface is visible, although at very steep angles, but it does not manage the screentrace reflection (shot01). or has a visual limit where it can pick it up (shot02). the walls however are fully screentraced (or they’d look very pixelated. it’s a “torture” map. ).
note: it looks beautiful nonetheless. it improved quite a bit (how far you can stand away from them and they still light up the wall nicely,) since i started this map in 5.1 (i skipped 5.2, jsyk nvm).
Not sure if I should report it here or elsewhere but on the Github 5.4.0 version, using Lumen and VR crashes the editor immediately once you start VR. From 5.1 until 5.3.2 using VR & Lumen works nicely and that combination is really great for Archviz-dev. Crossing fingers this gets picked up and fixed by the team before the official 5.4.0 is realeased.
Edit - link to a crash report
LoginId:c0b4334942f3e950c749a09abbc76528
Edit 16-nov: seems like this crash is not related to (only) Lumen. In the latest Guthub version of yesterday (15 nov) Lumen & VR works fine, I do get some crashes when Nanite is enabled AND VR as well on meshes from 5.1 projects that are converted to 5.4.0. Without VR, it works fine. Have to investigate more…
Assertion failed: (Index >= 0) & (Index < ArrayNum) [File:C:\Github\Engine\Source\Runtime\Core\Public\Containers\Array.h] [Line: 743] Array index out of bounds: 1 from an array of size 1
I’m honestly surprised it works, I was under the impression that the lumen team largely didn’t think lumen+ VR would be viable, on account of the pixel-scaled costs of lumen and the massive pixel throughput of VR. Are you using upscaling of some sort?
@jblackwell I was really surprised as well when it became possible in 5.1 - For the work of an architect like me, this option is really really really wonderful.
I tested with DLSS half a year back but nowadays I don’t anymore. I think it broke at some point and I never bothered again to re-enable it. Will have to try again…
I use it on my desktop which I upgraded with a 4090 just to be able to get some decent fps.
During design, I now never bake lights. Only when having to do a presentation at a client (using a laptop with a 2070) or when making videos (using a stabilized dampened VRspectator) I bake lights.
).
