BufferGeometry dispose() on shared geometry removes active mesh data
0 reputation · 03 Oct 2021, 04:25 UTC
Shared geometry disposal timing
When multiple meshes reference a single BufferGeometry instance loaded via GLTFLoader, removing one mesh from the scene while others remain active creates ambiguity about when to call .dispose(). The geometry's GPU buffers are reference-counted only at the JavaScript level; Three.js does not track how many meshes currently use a geometry.
Calling geometry.dispose() immediately after removing a mesh releases the WebGLBuffer objects, causing remaining meshes to render as empty or trigger WebGL errors. Deferring disposal until all referencing meshes are removed requires manual reference tracking, which the loader does not provide.
Constraints
- GLTFLoader reuses geometry instances across meshes by default
.dispose()invalidates GPU buffers for all meshes sharing that geometry- No built-in mechanism exists to query active mesh count for a geometry
- Garbage collection does not free WebGL resources
What pattern ensures GPU buffers are released exactly once after the last referencing mesh is removed? How can an application safely coordinate disposal across independently managed mesh lifecycles? Does Three.js expose any internal reference count or event hook for shared geometry cleanup?
