when vs is done simmering i’ll maybe try something. that’s gonna take a while, tho. gotta clean up this build. it’s bloated af. harddrive full. that’s a wtf.
tracing the water in the reflection is technically not hard. hit it, do a reflection bounce, passthru bounce and measure the distance to the underlying surface. you don’t have scene depth in the raytrace, which is present in the normal scene. then you evaluate the lower surface and fog blend and the reflection blend on top. shaders.
it’s a very niche case tho. who’s got a mirror by the pool or a deep fog puddle where you need to see the ground of it? you know?!?
That’s honestly a lot of what I was looking for, thank you! I was curious what the path was, as I noticed a lot of similarity between the ray-traced cards+DFAO solution that the original Samaritan demo used, and I was wondering if there was a more direct continuity from that to lumen, or a more meandering route. Thank you for sharing!
Is it possible to get hard shadows and proper sunlight from a HDRI backdrop using Lumen?
Please see these two images. The first one is with lumen hardware raytracing, no sunlight or proper shadows from the sun of the HDRI, second one is pathtracer. Is there any way to achieve some kind of parity without using a directional light? (Which would of course make the pathtraced scene look incorrect, since it would have duplicated lighting from the sun)
lumen is GI (and reflection) but not direct lighting. the sun shadow is a semi direct light cast. the pathtracer has this light information as it reverses all the way back to the sky and produces precise ray collision with the frame of the window to produce the sharp edge per pixel. lumen does not have that. it has a limited probevolume and surface hits and does not trace far enough to hit the sky sphere and grab the sun sample from the hdri texture. even if it would do that, the resolution of the surface cache texels will not produce a sharp shadow. it’s meant for GI. and has those limitations to get it to run in realtime. deal with it. put the sun in there. this is the way.
My confusion come from the assumption that both the pathtracer and lumen uses some kind of raytracing, so it wasn’t clear for me why pathtracer is able to cast these shadows and lights, while the raytraced skylight or lumen can’t.
A reasonable misunderstanding. The difference between path tracing and raytracing is that pathtracing handles everything in a comprehensive way - direct light and shadow, reflection, refraction, transmission and bounced light are all determined by following the path of the light.
Raytracing generally refers to a suite of individual technologies that may do some of these things. For example, you can independently enable raytraced shadows, because shadow mapping is a separate tech from Lumen.
path tracing and raytracing are technically similar. both shoot rays from the camera and at every hit point in the path. the hits are different tho. raytracing natively reflects into a singular direction. while path tracing shoots multiple rays from hit points. the thing they don’t have is… a clue of where the sun is at if it’s not a lamp. raytracing needs a sun lamp to evaluate the proper lighting at hit point. path tracing can shoot mulitple rays and eventually gather samples of it in the sky. importance sampling helps with that.
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.
