InstancedMesh frustum culling with transformed instances — bounding sphere configuration

Context

Three.js InstancedMesh uses a single boundingSphere computed from the base geometry at construction time. This sphere drives frustum culling for the entire batch, but it is not automatically updated when instance matrices change via setMatrixAt or direct instanceMatrix manipulation.

Goal

Achieve correct frustum culling for a large dataset (10,000+ instances) where instances are repositioned each frame — for example, a particle system or crowd simulation — without incurring the cost of recomputing a tight world-space sphere every frame.

Constraints and uncertainty

The default computeBoundingSphere() only re-evaluates the base geometry, ignoring transformed instance positions. Assigning a custom boundingSphere is permitted but unvalidated; an overly conservative sphere wastes GPU work, while an undersized sphere causes visual popping. No built-in API exists to derive a tight sphere from all instance matrices, and userland iteration over the instanceMatrix buffer each frame is expensive at scale.

Questions

1. What is the recommended pattern for configuring a fixed or periodically updated boundingSphere that balances culling accuracy against per-frame computation cost?
2. Does Three.js provide any internal hook or extension point to supply a custom culling volume for InstancedMesh without replacing the entire frustum test?
3. Are there documented heuristics for choosing a conservative sphere radius based on instance distribution bounds that avoid both over-culling and excessive off-screen draw calls?