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…
Not everyone has/wants one but people like to be in the loop. Besides their productboard hasn’t been updated in months; systems like stochastic shadows haven’t been promoted anywhere I’ve seen, despite them being a potential game changer. Just making people aware of things.
And on a second lookthrough SampledDirectLighting looks like a rename of most of the stochastic shadows files with a few additions I’ll look at at some point. I’d assume by the name that it’s tackling direct lighting fully but obviously seeing a lot of active development.
8 Likes
yeh. i have one. i had to deliver a lil jab tho. i’d like some hands on with the tech, for testing. but i couldn’t get the editor to build, last time i tried. i’m aware it’s in development, but a stable marker should be somewhere. where is it tho? hmm 
A bit late on this but this is an interesting technique, I wonder if there’d be some way to segregate the lighting process for emissives so they’d be able to use something like this? Or perhaps, reminding me of this paper I saw from a year ago, Clustered Voxel Global Illumination, It’s a very interesting paper and I was wondering if Lumen were doing anything similar, and if it weren’t, I wonder if it could be feasible as emissives replacement? I know a lot of the emissive properties I’ve been seeing are actually kinda similar to that old Nvidia VXGI thing from years ago, same with the area light functionality, so I’m sure there could be some overlap. If anything, I’m sure someone could make a plug-in for either of these techniques and we could see how they’d be able to compare!
1 Like
Honestly I would ignore this dude when he says junk like that, he may not be as annoying as that other guy but he’s hostile for no real reason, don’t give him the time of day lol, you posting github snippets has been a big help as I don’t think everyone can really access it and I’m sure not really able to commit to downloading the whole main branch just to check the new stuff out.
5 Likes
don’t backseat. try the front seat. and yes… ~300 GB is a commitment. and when it doesn’t compile at the time, you’re kinda done. i’m still working in stable 5.3.2 and doing fine and trying to help others figure things out and not derail. you can eat your hostile read. /2cents
Thought some ppl here may want to check this out.
Personally, I feel like the results could be better without impacting performance but still interesting.
1 Like
This is definitely an interesting one; I had no idea Enlighten was still around as a technology.
I feel like the presentation is a little hard to agree with if it’s making an argument that enlighten represents a better comprehensive GI solution over lumen; a cheaper dynamic GI solution would still definitely have its’ place alongside lumen, but that said:
- The core reason lumen is so GPU-oriented is that CPU processing power is at a premium in the current software and hardware architecture paradigm- the more you can do on the GPU is usually better for performance, especially given how few thread-limited UE can be.
- They don’t seem to mention at all that, in addition to dynamic lights and materials, lumen supports dynamic geometry. None of the test scenes I saw in the video seemed to show off dynamic geometry, or emissive objects. Enlighten only supporting scenes with static geometry is a big limitation in many ways, and it doesn’t solve the fundamental problem of trying to make worlds feel more alive. Perhaps I misunderstand how the probe system works, this is just to my understanding.
- Particle effects don’t look correctly lit with the scene in enlighten- could be a bug or a settings issue, but supporting correct volumetrics and lit particles in lumen is a massive advantage.
There could be a use case for enlighten in games that want to support dynamic lights but can’t pay the cost of lumen, but as engine versions roll by and lumen just gets leaner and meaner, I feel like a much bigger advantage would have to be offered by a third-party lighting solution to really offset lumen’s utility.
1 Like
Yeah, it’s not perfect. I personally think it’s not doing enough to prove useful in common scenarios.
lumen supports dynamic geometry. None of the test scenes I saw in the video seemed to show off dynamic geometry, or emissive objects.
I had similar idea but it’s basically volumetric lightmaps but time interpolable for directional and skylighting with multi lighting layers (including emissive) for mobility based destructibility. I was thinking interpolation between probes containing Path Traced diffuse and reflections but using Lumen instead would probably speed up the baking process.
The demo scene doesn’t look great and makes me wonder how well setup lumen is, and of course, no substitute for lumen reflections.
2 Likes