WebGPURenderer: Shadows Performances Issues

[RenaudRohlinger]

Description

Regarding the recent work on customCacheKey, lights, and shadows, is there a way to prevent renderShadow from calling renderObject.needsUpdate on every frame for every object?

In a moderately sized application, this check significantly impacts performance, causing a solid 30% drop (roughly 30–40 FPS). The check seems redundant, as we override the materials for the entire scene anyway.

If needed, this issue can likely be reproduced by enabling shadows in the webgpu_performance example.

Here’s a before/after comparison showing the impact of bypassing the cacheKey check for shadows:

With this hardcoded condition as a POC:

The scene renders correctly as I believe the cacheKey check isn't needed anyway for shadows.

/cc @sunag @Mugen87.

[sunag]

Regarding the recent work on customCacheKey, lights, and shadows, is there a way to prevent renderShadow from evaluating renderObject.initialCacheKey !== renderObject.getCacheKey() on every frame for every object?

I'm curious why it's testing cacheKey every frame and every object, this shouldn't happen. I just opened webgpu_backdrop_water and this process wasn't executed once.

[RenaudRohlinger]

Example in webgpu_shadowmap_csm:

[sunag]

Same thing, I even put a console.log() to test, not shown once.

[RenaudRohlinger]

Ah indeed my bad the similar name between renderObject.getCacheKey and nodes.getCacheKey was missleading me! It's because the performance issue comes from renderObject.needsUpdate in the if condition just before your log, so never reaches renderObject.initialCacheKey !== renderObject.getCacheKey().

Could be this condition forcing the cacheKey to be update every frame?

if ( this.object.receiveShadow ) {

	cacheKey += 1;

}

[Samsy]

Having same huge perfs issues when rendering shadow, a lot of cachekeys fetch

[Samsy]

Is there any news on this one ?

There are blocking performances issues :

[Mugen87]

@Samsy We are aware of these issues but would appreciate more patience, especially at the turn of the year which is a typical holiday period. Besides, there are a lot of other ongoing tasks so we can't solve everything at the same time.

[sunag]

@Samsy Your issue is similar but not the same, there is something different in that the material is being generated again, perhaps you can share a fiddle that reproduces this stack?

[Samsy]

hey @sunag I'll build a fiddle to reproduce this stack

But it is basically :

1 ) Rendering a mirror / with shadow enabled
2 ) Rendering a diffuse with shadow enabled
3 ) swapping material for a selective pass for bloom ( just swapping, no re-creation of a material )
3 ) Rendering a selective pass for bloom with shadow enabled
4 ) Then rendering the compositing of bloom using the post pro lib