WebGLRenderer: Add .renderShadowMap().

[Oletus]

This can be used to manually update shadow maps, which can be convenient in case the user wants to set up the scene differently for shadow map rendering. This can be useful for example when showing a cutout view.

Fixed #23461

This contribution is funded by Higharc.

[Mugen87]

The example needs to be added to files.json. Otherwise it does not appear in the side menu.

And please add the respective E2E screenshot via:

npm run make-screenshot webgl_shadowmap_manual_update

The PR checks should then be successful.

[Oletus]

@Mugen87 Added the file to the examples listing and added the screenshot, PR checks passed now!

[WestLangley]

I had to diff the example in this PR to find the 3 lines which differ from the original example upon which it is based.

I think this will be confusing to users.

This can be useful for example when showing a cutout view.

Why not create an example of that, instead?

[RenaudRohlinger]

clipping parameter does not exist in the ShadowMap render method

[RenaudRohlinger]

I did give a try to this feature. It works like a charm. I was able to bake a static shadow on the whole scene in 4k and then render a small dynamic shadow in 1k that calls renderShadowMap only on a few meshes:

(In this video the giant shadow camera helper is the shadow camera of the scene, and the small shadow camera helper is the dynamic that only renders the characters through renderShadowMap)

shadowbake.mov

Also, to make full usage of it I would recommend a 4th parameter forceUpdate

Like so:

this.renderShadowMap = function ( lightsWithShadows, scene, camera, forceUpdate )

That will allow being able to manually force to render an object even though autoUpdate and needsUpdate are set to false. We need to disable both these values if with use renderShadowMap otherwise it would clash with the natural state of how shadowmap.render works and call both methods per render.

In that case, the render method of WebGLShadowMap would have a third condition in order to prevent the render of the shadow:
if ( shadow.autoUpdate === false && shadow.needsUpdate === false && forceUpdate === undefined ) continue;

[mrdoob]

Why not create an example of that, instead?

Agreed. This needs a simple example.

[RenaudRohlinger]

With that new feature it would be very interesting to also introduce Array usage on top of Mesh.Group for the second parameter of WebGLShadowMap.render.

It will allow to prevent a complex filtering of the meshes that we want to apply shadow to. That way, instead of doing scene.traverse(), we can just renderShadowMap(lights, [meshA, meshB], camera, true)

It could look like this:

function WebGLShadowMap( _renderer, _objects, _capabilities ) {

	this.render = function ( lights, scene, camera, forceUpdate ) {
              
              // bypass if we want to manually update the shadowmap for specific elements
              if ( scope.autoUpdate === false && scope.needsUpdate === false && forceUpdate === undefined ) return;
              
              // allow arrays
              const elements = Array.isArray( scene ) ? scene : [ scene ];
             
              for ( let vp = 0; vp < viewportCount; vp ++ ) {
                    //viewport
                    _frustum = shadow.getFrustum();
              
                    for ( let j = 0; j < elements.length; j ++ ) {
                    
	                    const element = elements[ j ];
	                    renderObject( element, camera, shadow.camera, light, this.type );
                    
                    }
              
              }
              
              //....

[Oletus]

@mrdoob @Mugen87 Hey! Sorry that it took such a long time for me to get around to updating the example, but it should be much better now! The manually updated shadow map now includes an object that's not visible in normal rendering. DeepScan is complaining about an unrelated issue since this code was forked off of dev a while back - do I need to rebase this branch or merge dev into here?

[Oletus]

Rebased this to pass the tests and made sure that the patch still works, @mrdoob time to merge this? 😁 I'd be really happy if we got this change in, hope you're not too busy! 🙏

[Samsy]

+1 !

[Samsy]

Hey there, reviving this topic @RenaudRohlinger @sunag
Could this still be work-able in the current state of the WebGPU backend ?

I did hack my way on a custom threejs on the webGLRenderer to have both baked and real time lighting, this should definitely be useful to select which shadow you'd like to update, but also :

Determining if a light should contribute of the color lighting output, or cast shadow only

Example for a scene, let say you have two directional lights :

1 used for baking shadows globally and for lighting color contribution

1 used for real time shadowing, but this one should not contribute to the color lighting as it would add up a second contribution, but on top affecting perfs since one light is only needed for the lighting color contribution

EDIT :

Found out we can now set light.shadow.autoUpdate to false, and call light.shaow.needsUpdate only when required
Will publish a feature request instead

[RenaudRohlinger]

Didn't try but I'm pretty sure if you render a shadow once and then do light.shadow.autoUpdate = false and light.shadow.needsUpdate = false on it, it should work just fine.
Unlike the WebGLRenderer, in the WebGPURenderer each ShadowNode is isolated and has its own rendering pipeline. @Samsy

Also you probably need to use "three": "mrdoob/three.js#dev", in your dependency while waiting for a few fixes that will ship in r172:
#30081

[Samsy]

@RenaudRohlinger Yes, It work this way indeed, I did edit the comment, I opened a feature request for the no-lightingcolor contribution

[Samsy]

@RenaudRohlinger btw, about using "three": "mrdoob/three.js#dev", the builds are not updated