Thanks for the tip!
Turned off both, unfortunately neither solved this issue. Then I guess this feature is just not ready yet. Tried playing around with the console commands and it seems like if I change the “r.ManyLights.NumSamplesPerPixel” from 4 to 1, it improves it, although does not fixes it completely.
Oh yeah I’m just remembering that many lights is what they renamed the new, experimental stochastic shadow technique.
I haven’t experimented with it yet, but I’ll try later. I know others in this thread have though and might have more suggestions.
weird glitch. i can not reproduce it. sry… not helping.
it’s weird that it’s “tiled”. not sure if this is a compute shader issue.
Okay, I gave this a spin. I am able to replicate this. Like you said it appears to be based on the factors you described, but also the resolution. If I shrink my viewport, or decrease my render resolution the issue is reduced or eliminated.
tried both spot and point lights and was able to trigger the effect with both. At 3440x1440 I could have 3 overlapping point lights with no issue. At 50% screen scale I could have 13, which makes sense since there are 1/4 as many pixels so I would expect to be able to render 4x as many lights. Then I tested 75% and sure enough I could render 6 lights no issue.
So it seems to be exhausting something. I would’ve expected reducing samples per pixel to 1 to significantly increase the amount of lights, given there is clearly a resolution/sample constraint, but it barely does anything.
r.ManyLights.Sampling.MinWeight also seems to impact it. Increasing this cvar can reduce the effect, but larger weights causes banding/posterization.
that’s odd. i just duped 52 in this spot and have no glitches. all raytraced shadows btw, no vsm.
i reduced them to see if it’s a shadow issue, but… i don’t get anything like this. hmm…
is that an issue only above 1080p, perhaps? i can not test that.
Definitely weird. I’m in 5.4 on an RTX 3080 Founders. Maybe its a hardware or version thing?
i shot this in 5.4.2 too. stable 3060 craptop. even more budget then a 3080. it’s a weird one, for sure. no clue, tbh. my only guess is the resolution is bugging it.
I can confirm that the screen resolution affects it too. And it also seems to be dependent on the camera direction vector too.
Could you try adding more light sources and increase the exposure/light intensity/resolution to see if you can reproduce it too?
I also turned off VSM, but it does not make a difference.
Would be good to figure out why it works just fine at you, what setting may be the culprit.
okay i got it too, now. 60 lights overlapping. glitch appears at the outer region of the radius. autoexposure on. which i usually don’t do when i light.
it looks like some sort of surface or histogram memory is running out. i dunno how the memory is packed. but… the memory region is clearly fixed in height. and gets smaller the more lights are added to overlap.
so… overlapping lights still matter in ManyLights. i asked about that before. now i got an answer.
Weird because if I look upwards with the camera, even 60 overlapping lights wont cause an issue. It seems like it has something to do with the total pixel intensity on screen, seems like some kind of overflow.
If I look upwards and the sky is deleted, the rest of the pixels are black, no issue:
But if I place another floor on the top, the glitch becomes visible again:
can somebody help me with this?
I dont think it is Lumen related, but I can help you out in DMs so we do not flood this topic anymore.
@Krzysztof.N checks this thread regularly and would probably be interested in seeing this issue. I don’t think there is going to be an immediate way to resolve it within this version but it’s something they can work on for future improvements, as the feature is still experimental. It has not been formally announced, and I don’t think any documentation exists.
In the meantime, I would just be mindful of the overlaps if you want to use the feature.
I’m just puzzled as to why glitchered can have like 10x as many lights without issue on lower end hardware.
i’m not sure why i get more out of it. i will have to redo it from a template map for sure. i mean… my test map is already a bigger surface area and does pretty good. there are some things i need to check tho. and i’m not using a default config. i basicly have everything on. all experimental features. hmm
I have reproduced the ManyLight issue in 5.4 and I have good news: I have tested the same scene in 5.5 Main and the issue seems to be solved in it. We just need to wait.
There was a limit on shaded samples (number of pixels affected by lights). This was fixed recently:
https://github.com/EpicGames/UnrealEngine/commit/67b8b6175e0e0af515f20a3e83eb2e6fd1745dc0
Before that fix, you can bump r.ManyLights.MaxShadingTilesPerGridCell to the next power of two.
There’s a bunch of CVars which are can be set from PPV Lumen Scene Detail. In this case though I think that you would need to make a single mesh of this interior wall instead of trying to build it in the editor from a 100 thin pieces.
Tested the stochastic shadows in 5.4.3. I see a nice 20 to 25% fps improvement in one project. Really great. Some visual differences with shadows but nice option to have when in need of speed.
I did notice though, in VR there doesn’t seem to be any increase in fps AND in one eye, the shadows are different (missing). Hopefully this option gets added to VR at some point as well because 20/25% extra fps in VR is great for comfort.
