WebGPURenderer: Memory Leaks

[querielo]

Description

Right now it’s too hard to clean memory of meshes, even if the user explicitly disposes geometry, materials and textures and remove all references.

The reason is:

• A mesh “does not know” with which materials it was rendered (scene.overrideMaterial)
• Each PassNode / override material can create one or more RenderObjects behind the scenes.
• Those RenderObjects can only be destroyed when the corresponding material is disposed.
• As a result, it’s not enough to dispose just the resources (geometry, materials, textures).
  You must also dispose all nodes that use overrideMaterial (including LightNode and PP nodes), or RenderObjects will stay alive and keep meshes strongly referenced.

It would be great to have a way to notify Renderer that a mesh is no longer needed, so it can remove all RenderObject instances associated with that mesh (mesh.dispose?)

Here is a video explanation from this PR: #32395 (comment)

output2.mp4

[querielo]

@cmhhelgeson From my point of view, the issue here is that WebGPURenderer creates RenderObjects based on a (material, geometry) pair. However, users work with meshes, which have their own material and geometry. A user can destroy a mesh’s material and geometry, but this does not destroy all of the RenderObjects that were created based on this mesh.

Some RenderObjects are created using the mesh’s geometry together with internally generated materials such as ShadowMaterial, NormalMaterial, DepthMaterial, and others NodeMaterials. From the user’s perspective, they only need to dispose of the mesh’s material and geometry. But in reality they would also need to manually dispose of all those internal materials (ShadowMaterial, NormalMaterial, DepthMaterial, etc.) in order for GC to properly release the mesh’s memory.

This means the mesh will stay in RAM until you remove or disable the lights that cast shadows and destroy any post-processing pipelines that use those internal materials (and recreate them all again if an app is still running).

Improving the internal caches may help, but there is a more fundamental underlying problem. There are also many small nodes that are difficult to dispose of (for example, UniformGroupNode), but they are relatively small and do not significantly affect RAM.

[Mugen87]

WebGLRenderer also creates internal materials or render targets e.g. for the shadow rendering process. We have tried to develop WebGPURenderer according to the same principles regarding the dispose mechanism.

If a material on app level is disposed of and internal materials stay in memory, the renderer probably misses to register an event listener for the material dispose that ensures to clean up the internal material. Same applies to internal render targets, textures etc.

So for example if WebGLRenderer determines a shadow material for a given material, it does the following:

material.addEventListener( 'dispose', onMaterialDispose );

The onMaterialDispose() handler ensures to remove the shadow material when the actual app-level material is disposed of. It's possible similar changes like #32395 are required at other places in WebGPURenderer.

[querielo]

@Mugen87 You’re right, but I’m talking about a slightly different issue.

For example, imagine I have box_1 (material_1, geometry_1), box_2 (material_2, geometry_2), …, box_n (material_n, geometry_n), along with a light source that casts shadows. Even if I remove all references to box_i , material_i, and geometry_i, and properly dispose all materials and geometries, there will still be references to these objects as long as the light source remains active (after this PR #32395 disabling light shadows can remove references on meshes).

If the scene is rendered with post-processing (PP), then we also need to dispose the light sources, the PP pipeline, and all of its passes in order for the meshes to be fully released/removed/disposed from RAM.

I believe this issue doesn’t occur with WebGLRenderer.