Scale is a contract.
The official Rapier instancing example renders 400 boxes and 400 spheres. This route makes that batch boundary measurable: change the instance count, rebuild the indexed rigid-body arrays, and compare shared-buffer cost with the renderer's live frame work.
Preparing a shared geometry batch and indexed Rapier body arrays...
- physics
- -
- instances
- -
- draws
- -
- buffer
- -
- build ms
- -
- render ms
- -
- selected
- -
- fps
- -
Select an instance to inspect the indexed body and the shared matrix buffer that renders it.
new THREE.InstancedMesh(..., count)allocate a bounded batchDynamicDrawUsagedeclare per-frame matrix updatesphysics.addMesh(mesh, mass, restitution)create indexed bodiesbody[] + collider[]one array entry per instanceinstanceMatrix.needsUpdatepublish the physics writebackrenderer.info.render.callsobserve draw-call workRapierPhysics private timeraddon-owned 60 Hz step loopphysics.removeMesh(...)replace a batch safelyThe batch size is a resource decision, not only a visual decision. This lab measures the Three.js render path and buffer footprint; the Rapier wrapper's internal timer remains private, so its step cost is reported as an ownership limitation rather than fabricated as a renderer metric.
Rapier is loading. The selected instance will expose one member of the indexed body/collider arrays.
Based on the official Rapier instancing example, InstancedMesh docs, and RapierPhysics docs. Measurements are local browser evidence, not a universal performance claim.