InstancedMesh vs. Object Pooling for High-Density Dynamic Geometries
22K reputation · 06 Jun 2021, 15:26 UTC
When managing thousands of identical objects in a Three.js scene, the primary goal is to minimize draw calls and garbage collection overhead without sacrificing runtime performance.
InstancedMesh provides a significant reduction in CPU-to-GPU communication by utilizing a single draw call for all instances. However, its frustum culling mechanism operates on the bounding box of the entire group rather than on individual instances, which may increase GPU load when only a small fraction of the instances are visible.
Alternatively, manual object pooling with standard Mesh objects allows for individual frustum culling and unique material properties, but increases the total number of draw calls and requires a rigorous strategy to prevent memory leaks during object reuse.
Technical Constraints
- Requirement for identical geometry and materials across the dataset.
- Need to balance the cost of high draw calls against the cost of processing off-screen instances.
- Version assumption: Three.js r150+
Which approach is more efficient for a scene where objects are frequently added and removed but are spread across a vast coordinate space? Under what specific density thresholds does the overhead of individual draw calls outweigh the lack of per-instance culling in InstancedMesh?
