Hmm, out of curiosity, what does the path-tracer show you? That will at least let you diagnose if it’s a lumen/lighting issue, or something else at play.
If the PT is what captured those photos then, your lighting issues wouldn’t be a lumen problem at all, possibly geometry?
don’t quote me on that but i lean myself out of the window and question if lumen can generate mesh cards or distance fields for runtime meshes. would make sense why there is no surface cache for the terrain.
Do you mean for this instance or in general? I have lumen GI working with terrain in my levels, hasn’t caused any problems so far.
is it procedural tho? or a landscape?
landscape is static data. runtime virtual texture sounds like it rendered “live”. has no pregenerated data. like colission. that is obviously missing too.
Same results. In fact for the heightmesh, it doesn’t to respond to any ticks in the shadow/lighting details panel…
It does respect two-sides in the material itself. I can move under the 'mesh and see the material being rendered…
I really don’t know much around the expectations with regards to the 'mesh since it’s experimental and there is little documentation. Whatever is broken, it’s still broken in Lumen tho. As far as Lumen, I really just turned it on, so insofar as idiot-proofing, I am that idiot… 
Is your landscape not casting a shadow? I haven’t touched virtual heightfields so idk the usual workflow well, but I assume you could still have the underlying landscape cast it’s shadow of the VHM isn’t.
Hi all! I’m doing some cinematic rendering in the matrix city sample scene. Currently I’m still in 5.0.3, which is what I was using around this time last year to render a similar scene, but I was getting a ton of this artifacting with Lumen GI. Is this fixed in Unreal 5.2 or even 5.1? Don’t want to download 5.3 for bug reasons and don’t want to download any new version until it’s for sure fixed.
Emissive only lighting, like in that scene, is still prone to visual deficiencies.
2 Likes
‘Fixed’ is pretty relative. @BananableOffense can explain it really well too, but to elaborate on what they said, emissive lighting is really hard for lumen to solve, and it gets harder the smaller and brighter the GI is. You can reduce the problem by cranking up the final gather settings in the PPV, but that OC comes with a perf cost. UE 5.1 and 5.2 both massively improve noise and I’d even argue that 5.3.2 is pretty stable for all I’ve done with it. That said, noise isn’t a problem that can ever be ‘solved’ in this kind of lighting, just managed better.
2 Likes
Heh, so this is where I surely ‘shine’…
I turned the Landscape off in the main pass, set to never-draw, hence no lighting.
Why? B/c the landscape peeks through the heightfield-mesh if it’s drawn in the main pass…
I going to go out on a limb and claim it sure might not be the way it’s supposed to be implemented, but practically, it doesn’t seem to work otherwise (hiding the landscape).
Since the landscape is not drawn, no shadow. If you draw it in the main-pass but set it to be hidden, then you lose grass… Catch-22, you seemingly cannot have the landscape visible w/o visual artifacts, yet the lighting in incorrect w/o it… Fixing the lighting breaks the grass…
I don’t want to hijack the thread, but that’s what it is. I thought it might be a Lumen issue, but likely not. (le shrug)
1 Like
Hi @jblackwell an anyone interested,
Did you mention something about Restir GI? I have seen they are integrating it into v5.4. There are a few cvars regarding it, but still low quality:
Whether to use the prototype ReSTIR Final Gather. Disabled by default, as quality is currently much lower than LumenScreenProbeGather, and fewer features supported.
I have also noticed they have improved some very little, but very black noise there was in the short range AO, even if it still is, for me, one of the weakest Lumen features (the AO).
Additionally, and not related to 5.4, I have noticed we can already ‘enable’ DLSS ray reconstruction with the next cvars, and it will detect that RR is enabled, but I think it’s not actually working or they haven’t implemented a denoiser already. Well, anyway it’s supposed to still not be activable:
EDIT: but still the artifacts I already reported before (and using the default Directional Light’s source angle) O.o:
2 Likes
I did mention that, yes. From what I read, it was essentially an experiment to see if a reSTIR style integrator could improve quality in lumen GI. That said, I’ve seen relatively little development resources put into it since, as stochastic shadows (which is another sort of reSTIR style integrator for direct lighting) has been receiving a lot more dev time from the looks of it.
Unfortunately, I can’t really speak much to any major quality or technical improvements; I haven’t had the time to pull down a new version since 5.3. I’m very eager to do so, but I’m honestly tremendously excited by stochastic shadows. That said, a neural (or simply improved) denoising solution for lumen would be extremely appreciated.
2 Likes
Also, no idea if the lumen devs are monitoring the thread atm, but still-relevant bug:
Lumen scene objects are still exhibiting strange patterns and striations that aren’t found in the source texture or mesh whatsoever. This isn’t consistent, and it dissapeasrs and reappears once every second or so, for about three seconds after the camera moves, and it stays like that. The map is Safe House, released for free on the marketplace last month I believe.
Also, enabling raytracing.nanite.mode 1 makes the entire floor disappear?
not sure what causes the lines. rng thing, i reckon.
disappearing floor makes kinda sense. how large is the floor? hbv likes small submeshes in the cluster. a huge floor mesh is one level up in the hbv hierarchy. i’d not advise to use that.
RNG, how do you mean?
You are correct, but that floor is made of many small tiles that are more than simple quads, and yet it culled all of them and part of the wall; they’re not all one component. Furthermore, there should be a minimum representation in the BVH, as they’re certainly too big to cull.
After the strangeness with the safehouse kit, I decided to look at the surface cache behavior in a few different scenes. The city sample obviously shouldn’t have any major lumen issues, and yet as of 5.3.2, there are many phantom shadows being casted. This is true regardless of if r.RayTracing.Nanite.Mode is enabled or disabled, although they do change shape. They morph as the camera moves around the scene, but they don’t dissapear as one gets close. I’ve already determined that there is nothing in the scene that should be casting those shadows, they have surface cache coverage, and there is no normal variation in those scenes.
1 Like
@Krzysztof.N I saw this submission for sampled direct lighting to github, and it appears to replace the stochastic shadows files. Is this a continuation/renaming of the system? Per the direct lighting monicker, is it actually integrating N.L?
3 Likes
@jblackwell you just quoting gthub? neat
i’d not mind a stable out of the box git build i can compile myself and play with. not had any luck, lately. faith is always there, tho.
what’s the current most stable environment? vs 2k19? vs 2k22? what libs? kinda hungry…