Maybe you are still not correctly enabling (or testing) stochastic shadows.
I have created an empty project, from scratch, and with stochastic shadows enabled by default (in blueprint construct), so you and @Krzysztof.N can also check&test easily and quickly:
(At left, the default sun, projecting fine RT shadows, because they are not stochastic. At right, a Spot light, projecting stochastic shadows with their masked issues)
The masked issue it’s even more strange; it ‘works’ better when looking the masked sillhoutte ‘frontly’, allowing the light to passthrough:
first of all it’s still a beta thing. and… now more properly tested and figured out.
solid geometry has no issues at all. for translucent or masked (and dithered) materials the caster’s geometry and normal orientation matters. it’s a screenspace contact shadow. maybe not well suited for flat planes or giant transparent overlays. proper grass level geometry looks okay. i’ve seen a similar option in T1’s port. i’d also not put a text renderer in a game, anyway. also… in case of “glitches”/artefacts it’s a job for the lighting artist to hide the hard contact issues.
also… screenspace typical artefacts. this is why the transparent caster geometry matters. you will step into this pitfall if you don’t understand how it works. at this point real geometry or really tight alpha masking may be the supperior choice for foliage, with this shadow technique.
i got a question @Krzysztof.N or team tho: should i be worried about this? some lamps expose complexity, some don’t. changing angles doesn’t change that. edit: changing color does. red light is more expensive then blue light? gonna be a cold world? this doesn’t make alot of sense. or is the light complexity “broken” for manylights? the shaders are all green. so i take that.
I did just want to say, the screen traces toggle has been extremely useful from a testing perspective alone, it’s very helpful to have that immediate toggle rather than needing to enter CVars.
Also @Krzysztof.N, standalone SSR is currently broken in the most recent _main build:
I finally got around to trying out translucent RT reflections-they work essentially as advertised, we now have greyscale transmitive caustics in Unreal. They do come with a massive performance penalty (as the CVar said it would), but it’s still a very cool effect.
That said, if anyone wanted to have stained glass-style windows in Unreal, I’d definitely just go with the fake rect light technique shared somewhere above in the thread- you have better resolve, better shadows, far less noise, and improved responsiveness.
I wouldn’t call it a ripoff any more so than any other technique is ripped off in computer graphics; the industry’s progress is largely a result of share and share alike.
Without solid perf numbers (EG UE, same GPU, same scene, resolution, and quality level) everything is speculation, but it should be said that this system only targets diffuse GI-reflections are a separate problem to be solved. That said, the idea of using screen probes to query a world-space data structure, and using screen-space techniques to fill in for sparse sampling, is definitely and openly borrowed from lumen. Beyond that however, there is a lot of new research and differing implementation and choice of techniques. It’s similar to lumen, but it isn’t lumen.
I think many other real-time GI techniques are going to come to similar conclusions for basically the same reason Danial Wright laid out in the original lumen presentation: filtering real-time GI data is hard and a screen-space/world space hybrid system seems the way to go for now.
I should have said AMD ripoff(FS2/DLSS, frostbite SSSR/AMD SSSR etc). It’s not an insult or meant to be derogatory towards AMD, it just means if it’s their closely resembled iteration of somebody else’s effect which they do often. You could say that about any effect, the point is supposed to be an advancement. If it doesn’t advance in a area, then just call it the same technique, credit, etc.
From what it seems(I didn’t stick around for the whole thing) from your comment it is their modified and generic Lumen GI only solution.
Couple of interesting developments in the presentation. One in particular that caught my eye was around 22:30, which appears to solve the temporal instability of small emissive light sources by biasing away the unstable portion of the light. Maybe that could work for Lumen, since the slightly darker final image seemed like a worthwhile trade-off for temporal stability. Lumen’s spotty emissive resolve has been a hot topic for a long time now.
We don’t have a ManyLights (formerly Stochastic shadows/sampled direct lighting/etc) thread yet so I’ll just put it here:
I’m getting the feeling that between the need to evaluate hit lighting to solve alpha occlusion, and nanite’s behavior, it’s probably best to lean more on actual geometry vs. alphas in future art?
more to test? lemme sync (or reclone this conflict -_-) then… and rebuild.
and… the last test i did suggests using actual geo is better for certain alpha cases. simplifies the shader load. will see what this push looks like. just applying in a simple user case scenario. hmm
daily… running comfy 720p on my lil rig (i gotta cheat, always. i like the magician that is dlss. that will raise the quality later). translucent shadows look good.
test runs fine. seems the native performance was improved. (or i don’t remember what resolution i used for the older shots). nvm.
Oh, so great, they read us silently! Thank you @jblackwell
It’s working fine now! But I still wonder why the sun is not stochastic. Is it intended, maybe? (Notice its shadows are not blurry, but still ray traced):
Unfortunately, It seems it won’t be included in 5.4, at least right now, but well, it’s still experimental.
Additional feedback about Many lights (and a little about Lumen translucency) @Krzysztof.N :
At the beginning it’s about Lumen translucency volume flickering. Firstly with RT translucency enabled, and disabled secondly.
After that, it’s about enabling Manylights. Screen Traces causing some glitches. Many lights being very noisy in some situations (under the table, just 2 common lights over it, with 0 in their source radius):
In this less compressed video, the noise is more evident. But it’s much more noticeable “in person”:
you mean soft shadows? well… it’s a directional light. that usually means straight shadows. it has a source angle tho. as well as other lights have a radius to soften up the shadows.
laptop on fire, but i like what it can crank out. needs more lights tho. gotta bench it.
No, I don’t. I mean stochastic shadows, even without any source radius or angle, are always slightly blurry/lowres (because of their nature, of course). This can be taken as a proof to notice that Directional Lights are not rendering their shadows as stochastic. Rest of lights do.
To my understanding, that’s by design: stochastic shadows were intended to provide cheap shadowing for local light sources, whereas VSMs would be deployed for directional lights and hero lights. Blurry shadows could be more acceptable for background lighting, but you’d want that high-quality contact hardening and falloff in your most essential lights. VSMs are still too expensive to be a universal lighting solution.
Side note: I wonder if it’s anything that could be swapped at runtime- flipping lights to VSM when you get close, and back to stochastic shadows when you’re further away.
What are hero lights? Just a concept to refer to main lights? Anyway, you can use RT shadows instead of VSM for those non stochastic shadows. (RT performs even better than VSMs, I have noticed many times).
About the switch you mention, I think it wouldn’t be even needed: Manylights seems to be something like pixel-based, so the near you are, the more defined they are, if I’m not wrong.
ugh miguel. not sure if you know what stochastic means. you throw this word around with weird or out of context. it means it’s randomly sampling light sources or wherever the light and occluder data comes from. hence why it’s noisy. lights that have one center are probalby sampled once. this is why a direct light is without noise if it doesn’t have a source angle. light sources with a radius or an angle are sampled over time. means temporally and mosdef managed via taa motion history. i have yet to look at the code how it actually works.
i’m not sure how this huge sun light in my scene rendered, but it’s certainly a lil noisy when moving around. so it’s all the same rendering. direct lights are no different then the rest. the source parameters make the change.
in general, many lights have their place in static scenery or scenery with a managable amount of motion. at some point i gotta test how good they hold up in a cutscene type of scenario. tho… i basicly run quinn thru the light all the time and i see no glaring issues. hmmhmm
@glitchered , Can I use a word to refer to something that’s called that, even if I don’t know how it works internally? (I see that you yourself say, I suppose by mistake, that you don’t know either ).
I already said that all the lights in the super noisy area had a source radius of 0, so… then? Please, read my messages carefully, because otherwise this becames exhausting.
In addition, I think you are wrong (again) about the Sun issue, as you usually ignore my instructions to make the proper verifications (I still wonder why). I already indicated 2 ways to check that Direc. lights are not projecting stochastic shadows. Even this was theorically confirmed by @jblackwell . Maybe we are all wrong.
Please remember that earlier you already claimed that your Sun was casting stochastic shadows when you hadn’t even enabled such shadows using the new command.
PS: You just need to verify it experimentally, not based on beliefs.
i never claimed anything. i already tested it before it was renamed anyway. so… what?!? i used alot of versions and configs the 2 past months. juggling usabilty on my rig and testing full combustion. you can’t blame me for not remembering everything exactly.
also… i don’t need experiments. i build a semi use case and if it breaks i report it. that’s good enough for me. and i verified your masked material test. just my way. and i extended it. and found even more issues you didn’t even see.
either way, since we both apperently have no clue how it really works, there’s no point to argue. chill.
There’s one easy thing you can do to hugely improve Lumen on Foliage.
Currently, meshes get classified as “foliage” if they have more twosided/foliage shading triangles than normal triangles. Often, it works great.
In 5% of cases, this breaks apart and leads to over-occlusion. Imagine an asset with a highly detailed, dense trunk and lower triangle count or volume for the canopy. The canopy will look over occluded.
The solution is an over-ride in the Static Mesh Editor. Allow users to leave it at “auto” or to force it to be foliage or non-foliage.
Yes, directional lights aren’t supported at the moment. Like jblackwell wrote, the main selling point here are cheap local area lights, as VSM is pretty good with handling the directional light. Still, we will add directional light support at some point.
BTW there’s r.ManyLights.Debug 1 which will visualize which lights are sampled at a given pixel (use 2 to visualize shadow rays).
Noise and sharpness is high on the list, but it will take some time to get there.
You can force it to be two sided by selecting “Two-Sided Distance Field Generation” in the static mesh settings.
Thank you 
).