I most certainly am not
But as you know, URP covers a pretty big array of things and while shadows is my area. unfortunately (or thankfully depending on the stakeholder) some things get prioritized higher than others. Improving build times happened to be one of those. Thatās why I mentioned it in previous replies here.
I donāt control the prioritizations of tasks but I have a pretty strong voice inside the team and Iāve used it to express the urgency of what weāve discussed here. The team is aware and we will prioritize again soon but I canāt promise anything. All I can ask for is patience.
Also, I want to do this right. Even though in this thread weāre specifically discussing Cached Shadows, there are plenty of improvements/feature requests/issues for shadows that I want to tackle. Iāve been working on gathering those and doing a separate prioritization step specifically for Shadows so when I start I have a plan to give you the best wins as soon as possible.
Finally, like Iāve mentioned before here, I placed cached shadow maps pretty high on that list. And thatās thanks to all of you here in this thread. So again, thank you all! I really appreciate it.
Thanks for your continued work on all this, we appreciate it. Much as someone else mentioned in this thread above, Iām interested in why URP wouldnāt use Variance Shadow Mapping, or even EVSM, it really can work wonders for really soft shadows. (They arenāt physically accurate, but thatās perfect for URP) Itās even pretty performant, see the slides Iāve linked below which show how itās used in roblox of all things. (Clearly that makes it fast enough for most hardware URP targets)
Itās difficult for me to explain why VSM/EVSM hasnāt been implemented before as I wasnāt part of that.
But it is one of the items in my document (I have a pretty big list ).
But to be realistic, I donāt foresee myself working on that anytime soon.
I would much prefer setting up a good modular framework so that anyone can, if they want, replace/modify almost anything happening when rendering shadows. That would open the door for anyone to make their own custom shadow solution, asset store developers to create even more awesome assets, etc. Then in URP I would continue to build shadow features on top of that framework so the system would be used by both the internals of URP as well as users of Unity.
VSM / EVSM / ESM is worthless for your main directional light, although it can be much more useful for special use cases (point shadows, and even then, still some drawbacks). If it really were the great solution like it seems on paper you would see it in way more games. Iāve implemented quite a few variations and it has way too much light bleeding to be usable on medium and bigger light sources.
COD Warzone does use ESMs (iirc) for point shadows though, so definitely some good use cases there.
I see your point, but Iād like to argue the oppsite specifically for the case of EVSM on a directional light. All VSMs have light bleeding issues, itās true, but a good EVSM implementation with a bit of over darkening to hide any remaining leaks can work wonders. Donāt take my word for it though, take a look at the slides I linked earlier for implementation details, and for an example of it working very well for pretty general use cases, just mess around with roblox studio. Itās not perfect, but itās surprisingly performant, and has very soft, good looking results. Just not having to deal with the performance, quality, and bias issues of PCF and standard shadows makes it a win for me honestly.
(As a bonus it even works with anisotropic filtering, which is pretty neat)
So performance is going to take a big hit from memory reads alone. I think in some ways memory performance would be improved a bit because you could use mipmaps, but then again you also have to generate the mips and do the blurring. A lot of options with shadow maps open up of course when you arenāt so performance limited.
Not really, a four channel read in one, single texture sample is way less expensive then something like a 9 (or more) sample PCF. While VSMās are more expensive at low filter widths, they quickly eclipse PCFās performance at any reasonably soft kernel size. (See the chart towards the end of this article, figure 8-13)
You absolutely arenāt wrong about increased VRAM usage though.
I just hope it doesnāt take another year or so to get some decent improvements. Iād much prefer to have something useful right now, rather than ācompleteā but at undefined point in a looong future. (It wouldnāt hurt much to make improved shadows first, and then move them to a newly developed framework, right? Could be a nice test of portability for such system)
I have now bought Corgi Cached Shadows (for URP) | Particles/Effects | Unity Asset Store.
I needed it for getting fast ārealtimeā shadows on Quest 2/3. Works out of the box and the implementation seems pretty straightforward. For sure it would be nice to distinguish between (cached) static and dynamic meshes. But for the moment I can life with this.
The author stated that the cached system is meant to be used for games where the dynamic objects use fake shadows. I still think it would be great instead to have the option to differentiate, one day I will need to dig into it.
Maybe I should have been more preciseā¦ Iām totally fine with Corgiās solution for the moment. But if Unity would implement their own cached shadow system it with a distinction between cached static geometry and per-frame dynamic one, that would be perfect!
As stated previously the MeshRenderer component has already a (unused in URP) flag called āStatic Shadow Casterā that is meant for such a system.