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.
Ohh, I see, thank you!
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. 
Hi @Krzysztof.N ,
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.
Thanks for considering
-Jan from RealBiomes.com
I checked and it does work, but it needs to be enabled in a different way, as this combination is mostly intended for automatically scaling down to lower-end platforms:
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.
not supported? how is a soft directional light rendered then? in my test scene i cranked it way up and it seems to work pretty well. it’s all raytraced. no vsm. no shadow maps. no real downgrade in performance either. hmm
Likely they are rendered using ray traced shadows, which look similar, but go through a different path which doesn’t scale as well as it does all the work (tracing, denoising etc.) per each light. You can check exactly what’s running in ProfileGPU with r.RDG.Events 3 to see all the event markers.
okay. so… it is a “normal” “brute force” pass. i take that. it works. hmm
Would love if anyone who’s doing regular builds to test this out-I currently lack the storage space
noise is my friend. i could build it. i would require a scene with borderline artefacts tho.
miguel has this one. pretty sure they’ll build it and test their interior.
(i’m building anyway tho. stresstest. rendering cycles and compiling in the slow cooker. ^_^)
It’s not a magical fix for everything, but does manage to hide some of the noise:
Before:
After:
Oh, wow! Any possibility to see it in 5.4 too @Krzysztof.N ? This also helps with Translucency volume noise?
Can’t wait to try it in some days!
a slow cooked daily. it looks good. and runs fine (3rds).
i’d need/want a test for the interior noise tho. i got my outdoor noise, but that’s not much of an issue. hmm
Hi all and @Krzysztof.N ,
Any idea how could we solve this “memory” effect? It’s after a day/night cycle (just an example), when it’s already night, with almost no light, it seems to “remember” any kind of “cache” or something. I have tried even disabling radiance cache and related things, but I don’t know how to get rid of this weird effect; you need to see it in camera until it completely desappears, or it will remain there (tested on UE5 main, compiled some days ago):
Thank you in advance!
i was messing with history things the other week. maybe you could try to shoot a…
r.Lumen.ScreenProbeGather.Temporal.ClearHistoryEveryFrame 1
…console command for a single frame. that should clear the history immediately, but it would very likely do a “pop” and you get a dark to lit transition when it rebuilds it.
Will try, @glitchered , and report back. Thanks!
