Add a way to trigger shadow map updates separately from rendering the scene
See original GitHub issueIs your feature request related to a problem? Please describe.
It’s sometimes desirable to setup the renderer state slightly differently for shadow map rendering vs. normal rendering - for example to use different clipping planes for shadow map computations if presenting a cutout view. Currently this is not very convenient, and one might have to resort to hacks like rendering an extra frame to trigger a shadow map update before rendering the actual frame.
Describe the solution you’d like
It would be nice if a shadow map update could be triggered separately from WebGLRenderer.render()
- for example with a new function WebGLRenderer.updateShadowMaps(scene, camera)
, or WebGLRenderer.updateShadowMap(scene, camera, light)
which would update the shadow map only for a single light. Setting the already existing shadowMap.autoUpdate
to false could then be used to disable updating the shadow map during regular rendering.
Describe alternatives you’ve considered
Some kind of a callback before/after shadow map updates would be another alternative. This could potentially offer more flexibility if the callbacks were called separately for each light. However, this doesn’t seem to be as easy to fit into how three.js currently updates shadows without restructuring the code to repeat more operations between updating different lights.
Additional context
Implementing some of the alternatives might complicate adding alternative shadow mapping techniques, at least cascaded shadow maps. This is part of the reason why I’ve included the regular camera as a parameter to the suggested updateShadowMaps()
since it may affect shadow map generation. In general exposing too many internals can cause problems, so care should be taken to keep the API abstract enough.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:10 (9 by maintainers)
Top GitHub Comments
I wish the ShadowMap API was more modular…
Something like this:
I ran into this same issue in the past, after weeks of prototyping and research - I ended up writing an external shadowmap renderer. It’s 80% identical to three.js implementation, but exposes bits I need and doesn’t make a number number of assumptions that three.js makes such as that
clipping.beginShadows()
thing that @Oletus mentioned.I might be really dense, but that was my conclusion in the end - that I can’t use three.js for this directly and that shadow rendering is entirely impossible to extend without basically writing your own. Hope that helps someone save quite a bit of time 😃