InstancedMesh/SkinnedMesh and computeBoundingBox().

Geometry bounding box gives a somewhat misleading result when used in an InstancedMesh.

    var count = 10000;

    var mesh = new THREE.InstancedMesh( geometry, material, count );

    var dummy = new THREE.Object3D();

    for ( var i = 0; i < count; i ++ ) {

    	dummy.position.set(
		Math.random() * 20 - 10,
		Math.random() * 20 - 10,
		Math.random() * 20 - 10
	);

	dummy.updateMatrix();

	mesh.setMatrixAt( i, dummy.matrix );

    }

Using new Box3().setFromObject(mesh) only gives you the Box3 for the single geometry, and not for the whole instance.

[mrdoob]

SkinnedMesh case is a less visible glitch. But yes, we should solve this at some point.

[gkjohnson]

Classes like InstancedMesh or SkinnedMesh needs to be considered in order to compute proper AABBs and bounding spheres.

I agree – there are cases even with just a mesh where being able to specify the bounding volume per-object rather than per-geometry would be beneficial. Materials can change the apparent bounds of geometry, as well, with custom vertex shaders, instancing, and displacement maps (which I also think don’t work correctly at the moment).

I still think it’s valuable to store the bounding volume on the geometry, though, to share the volume instances. Maybe the responsibility of checking for frustum intersection should shift to the objects? Should the Mesh class define an intersectsFrustum function that can be implemented by derivative classes? I think this would help with the problems mentioned here. Here’s a simple example:

Mesh.prototype.intersectsFrustum = function ( frustum ) {

  var geometry = this.geometry;
  var box = this.boundingBox || geometry.boundingBox;
  return frustum.intersectsBox( box );

}

This would allow a bounding box to optionally be set on the Mesh to account for cases where the material changes the visual bounds of the shape. Of course raycasting would also have to be updated to support custom intersections if desired but that’s already override-able.