Hey there, thanks for your feedback, yes we surely know this is not the most physically correct. However when using Lumen for arcvhiz its still all about workarounds to make it look better as it´s reflection quality is still to poor when comparing it to offline renderers where none of this hassle is needed.
Hopefully in the future lumen visual quality keeps going up as it has been doing in the last updates so these type of tricks are not needed , hope we can have real time rendering and nice and accurate reflections both together, but for now it´s a great help to remove this noise that we and many others needed to ignore everyday when working with satin materials.
Our paid training will be focused on understanding the software but also on how to tweak it enough (which currently is the hard work when working with lumen) to make it get great results to sell your interior/furniture design on your clients presentations, which is the main goal of these type of renderings.
I normally do not join in on these conversations, especially where it is not particularly the best place. But @Rawalanche is absolutely right. If you mean it as a display model it’s one thing, but for archviz where it’s more important to be able to change things quickly and reiterate. It’s more misleading than anything. I do not recommend publishing your own paid courses without proper experience. Hence why I do not run paid courses, I’m inexperienced.
But for why I came here, how can you get rid of noise on foliage with Lumen?
Small foliage like grass behaves almost like a random noise generator, as Lumen doesn’t simulate transmission through it.
In order to fix it, remove small foliage like grass from Lumen scene (disable visible in ray tracing or affects distance field lighting). If you use screen space traces then set shading model to thin foliage or subsurface, so that screen space traces skip it. When it’s set correctly it should be affected by r.Lumen.ScreenProbeGather.ScreenTraces.HZBTraversal.SkipFoliageHits and r.Lumen.ScreenProbeGather.ShortRangeAO.ScreenSpace.FoliageOcclusionStrength.
Would it be possible for Skeletal Meshes to sample the translucent lighting volume for indirect lighting in reflections? Seems like that could work better than just having them be black. At least for exteriors anyway… I imagine lack of resolution could be a problem in interiors.
Yes, it would be possible through a bit more involved as reflections may hit something off-screen, which then would need to generate additional probes.
The plan is to try to exploit the fact that we need translucency probes only in frustum to improve their quality, and then change how surface cache works so that it can work on anything without a static mesh build step. We’ll see how it turns out in practice.
UE5.4.1 Under the influence of Lumen, the dark parts of vegetation leaves are almost pure black.The performance of Lumen affecting vegetation seems to be regressed.
Initial Lumen stochastic scene lighting.
This version adds initial support for stochatic Lumen scene lighting. This can be enabled with r.LumenScene.DirectLighting.Stochastic 1. By default temporal filtering is enabled. This can be disabled with r.LumenScene.DirectLighting.Stochastic.Temporal 0.
This version has a few issues which will be addressed as follow up:
* Multiple sample per texel result in RT occlusion test being incorrect some
* Temporal history is mark as valid even for cards being just added. This causes a flicker on their first refresh frame.
#rb Krzysztof.Narkowicz
nice. the code reads like soft shadows in my city test reflections. it’s hot outside but i’ll let the code simmer. (after i redownloaded the whole repo again - github corruption and ms build conflicts are not poggers) yep
nope. it’s not building today. fresh meat. but i dunno howto debug build syntax. all good. i’ll be back.
What takes the longest for Lumen GI to compute? Is it tracing SDFs, materials color, generating the global SDF, radiance probes?
What Lumen(and UE) lacks in comparison with other engine GI methods is the ability to take advantage of static objects. Lightmaps in UE are broken with leaking and memory and have alot of limitations regarding destructible objects.
Several Engines have used forms of baking reliable(static) world information, many games are static with dynamic lights and/or have anti-lightmap memory situations. But the only design Lumen makes sense for is FN where everything is destructible. I’ve already suggested interpolatible volumes, but more and more games are showing how wasteful Lumen GI is for their static worlds with basic interactions. The Robocop game and hellblade 2 are perfect examples.
This is why I’m wondering: What takes the longest and what’s most important to Lumens image(and what makes it difference from other GI methods like SVOGI?) I know ref is path traced.
this doesn’t even look that great. tbh. got some obvious errors cause it’s screenspace and basicly only can use the depthbuffer in reshade, afaik. just another fancy buzzword ao implementation.
using the normal vector you’d get more accurate obstruction. i mean… it’s still doing the math using the depth buffer to test for depth based obstruction. so… whatever.
the form of noise doesn’t even matter. it’s changing directions of vectors. those random samples always are accumulated or will need to be smoothed.
well now… pretested the stochastic direct light. it adds another layer of noise to safe computation per frame. result is decent at normal playing view distance from screen. the dev gotta use detailed textures. i also found shadow mode 2 for the reflections. at this point filmgrain is automatic. it looks good, but it’s kinda heavy in motion. i mean… mirrors are not perfectly stable motion and softshadows add the xtra noise. if the seed per pixel would match, maybe it would be lower. could converge all of it into… well… automatic filmgrain. no clue if this would work, tbh. i’ll for sure rethink doing overcast scenarios and lots of area lamps. there are limits. yo
volumetrics are currently nonfunctional. i did not check that light integration.
Other quality improvements came by surprise. Lumen GI downsamples heavily in order to fit into a four millisecond budget. This makes noise more noticeable, distracting from the game experience. We were able to reduce noise greatly by integrating NVIDIA’s Spatiotemporal Blue Noise, a technique that pre-optimizes noise patterns to cancel out quickly when accumulated over multiple frames. This gave much cleaner indirect lighting without requiring any more rays to be traced.
This accumulation is reliant on garbage TAA and/or expensive TSR. This is a major issue in the industry that Lumen current perpetuates. Lumen does not resolve this noise on it’s own. That is a major issue and it’s been solved in better ways.
nice screenshots. i’m not nose deep into the engine yet, but not all of it just noise that is easy to solve.
ofc lumen gi is downsampled. lumen is like realtime gpu lightmass and indirect probes on screen for dynamic meshes. compromises have to be made for performance. motion vectors are a thing too. i’m very aware of that. you can’t render every pixel raytraced every frame at interactive framerates. temporal accumulation is the way. gotta work with it.
if blue noise is the way the denoiser is trained you gotta follow the algorithm. quick math.
I can think as far back to MGSV where light is computed at half resolution and then upscaled per-frame. And very lite accumulation can work(3 frames, over 4 and you’re pushing it, Lumen uses 10).
Temporal accumulation is never been the main problem, the problem is needing TAA/TSR still for bad noise even though Lumen has its own accumulation.
Effects should not be tied to such broken AA designs. And TAA can be good if it’s adheres to certain rules(spoiler, good taa can’t hind broken effects)
it looks good, but it’s kinda heavy in motion. i mean… mirrors are not perfectly stable motion and softshadows add the xtra noise. if the seed per pixel would match, maybe it would be lower. could converge all of it into… well… automatic filmgrain. no clue if this would work, tbh. i’ll for sure rethink doing overcast scenarios and lots of area lamps. there are limits. yo