I’ve enabled auto shadow frustum size.
light.autoUpdateExtends = true
light.autoCalcShadowZBounds = true
Can we limit the size? I guess maybe I should just set the size manually to the max size, and get the worst case all the time.
The issue I had is things looking pretty good automatically until some objects shoots out far away (f.e. due to physics sending a ball far away), and the shadows then becoming super pixelated.
You can set autoUpdateExtends to false and provide the X/Y dimensions for the shadow frustum yourself through the orthoLeft, orthoRight, orthoTop and orthoBottom properties.
For dimension Z, set autoCalcShadowZBounds to false and provide values for shadowMinZ and shadowMaxZ.
I was wondering we we could still have auto size, but limit it to a certain max size.
No, this is not supported.
It would not be difficult to support it (though we would have to add 6 new properties to DirectionalLight), but I wonder if it’s not a bit too specific…
cc @sebavan for his opinion.
Yeah, I was thinking simplistically as an end user.
However if the size should be limited, then also the position of the box needs to be heuristically determined somehow.
It is easy to make it “enclose everything automatically” or to “enclose this specific space”, but perhaps what people really want is something like “enclose at most this amount of distance from the activeCamera such that the max size is limited AND the space moves along with the view point of the end user”.
Basically imagine this scenario:
You add a directional light, make it follow the active camera position (that could be an option, but also light.position = camera.position does the trick), and limit the shadow frustum size. The result is most of the time shadows look good (with a lower limit of quality depending on the max size), and if something shoots off into space it does not make the shadows get super pixelated all of a sudden.
The main idea is, if everything is kept tight in the world most of the time, the frustum size can shrink and offer better shadows than simply setting a bigger static size.
It sounds highly specific and In this case I wonder if it is not “similar - ish” to relying on CSM with 1 cascade.
I guess we can do it in the playground only at the moment by disabling auto compute and following the proposed process. If it works great and it gets traction lets integrate in the framework.
