Even if I make the viewport smaller, if I start increasing the the exposure/light intensity, it is being triggered. You can see that after adjusting the light source intensities, the exposure slowly adjusts and the glitch becomes visible after a certain treshhold.
Even if I make the viewport smaller, if I start increasing the the exposure/light intensity, it is being triggered. You can see that after adjusting the light source intensities, the exposure slowly adjusts and the glitch becomes visible after a certain treshhold.
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.
1 Like
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.
6 Likes
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.
3 Likes
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.
2 Likes
How well do stochastic shadows do with rect lights? I haven’t tested it in several months but the last time I tried ManyLights with multiple overlapping rect lights the shading basically broke down into temporally-unstable soup. If things are better now I will be very happy.
1 Like
depends how much you use and abuse them. good detail texture work will always cover up the scatter noise.
simple dev shot. all maxed out with cvars on begin play.
I think stochasitc + area lights seem ok in 5.4.3. See pic, no artifacts or unstable things going on although maybe this scene / setting might not be the best to investigate your earlier observation. What kind of scene / settings did you test?
sry… but a screenshot doesn’t show the temporal noise.
and… yes… on white or monotone unicolor surfaces like archviz does it is present. it cannot be avoided. this is just how the scattering works. for archviz you should bake the stuff for a stable result. in games you can deal with it and add details.
Unfortunately, the video compression seems poor enough that I’m not sure I can read shadow characteristics from it, but in general it does seem like ManyLights is significantly better quality. Besides, it’s designed for cheap local lighting, not hero lights, so if it’s good enough for that purpose I have no qualms.
I assume stochastic shadows requires hardware raytracing?
nope. without hardware raytracing it’ll use a combination of screen traces and distance field shadows. the typical screen space occlusion artefacts and distance field resolution limits apply.
1 Like
Not sure about the naming, but it requires Ray Tracing. I mean: if you disable All ray effects cvar, you won’t have stochastic shadows. If you disable Lumen Hard RT cvar, they will still work (because it seems to rely in RT shadows, not Lumen). But if you disable Support hard rt in project settings, they don’t work too.
1 Like