Does Three.js have a way to detect if an arbitrarily-rotated box intersects another object?

It is easy to call intersectsBox on Box3 instances, but those are world-axis-aligned.

Suppose I want to have a box (a Mesh with BoxGeometry) which is arbitrarily rotated in space.

What I want to do is something like box.geometry.intersectsBox(other) with the arbitrarily-rotated box, but I don’t see an API for that (or I missed it).

What I don’t want to do is box.geometry.boundingBox.intersectsBox(other), because that returns the world-axis-aligned bounding box.

Is there any such helper for intersecting with arbitrarily rotated boxes?

1 Like

Something like this does not exist since you would have to perform a box/triangle intersection test for all triangles of the mesh. Such an approach has a horrible performance and is not recommended.

It seems you are actually looking for a so called oriented bounding box (OBB). Unfortunately, three.js does not provide a OBB class in its repository and I have never seen a third-party plugin. The implementation is complex, especially the computation of the best-fitted OBB for a given geometry.

Yep, seems like an OBB is what I was looking for. But in my case, I was looking for an OBB box for a box geometry (the easiest case).

In particular, I was hoping that I could make a box from an ortho camera view box, and see what intersects inside of it.

But maybe there’s a better way? How would you check if something is inside an ortho view?

Well, it depends a bit on the desired accuracy of the test. In most cases, I would start with the same test which is used for view frustum culling.

You create an instance of Frustum based on the camera’s projection matrix and then perform intersection tests with the object’s bounding sphere.

You need at least planes for one box, you can then transform this test box into the other boxes spaces so they are axis aligned.

Ah, yep, I see how WebGL renderer is doing it: here and here.

I forgot that that also works with ortho camera.

Curious: can we take any box with any orientation, and make a frustum from it, as if that box represents an ortho camera view box? Maybe we position an OrthographicCamera at the same location as the box, and get the frustum from that. But we would need to adjust the ortho cam zoom to match appropriately first? If we can do that, seems like an easy way to use OBBs for intersections, which could be better for things like long/slender non-axis-aligned objects.

It’s no good idea to mix the concepts of frustum and OBB. The main reason of using an OBB is the computation of a best-fittet box for a given geometry. You can’t do this with a frustum class. I mean it’s okay if you want to experiment with THREE.Frustum for intersection tests but please don’t speak of OBBs in this context :wink:.

OBBs are usually defined by a center point, a size or half size vector and a 3x3 rotation matrix. A frustum is defined by six hyperplanes.

If I’m using what Three.js gives me out of the box, and I don’t want to do all the hard maths to create new classes, then I think making a representation for an OBB using an orthographic camera “Frustum” (which happens to be a rectangular box) is perfectly okay if it falls within all my performance requirements. An oriented orthographic camera frustum is, literally, a representation of an oriented box. :stuck_out_tongue_winking_eye:

It is a more or less free world, three is open source, I really believe that one should use it in any way one sees fit.

1 Like

It wouldn’t have to be a minimal one for trusktr’s case.


But the frustum culling checks are coarse:

Anyway, a possible extension would be to create a helper function that takes two Box3 objects and two corresponding transforms that define their coordinate systems, and use the Separating Axis Theorem to check for an intersection.

@Mugen87 how come you rarely if ever mention your implementation(s) of OBB?
I found your YUME obb code a while ago and used it succesfully (thank you), and more recently this:
Would you not consider these good enough?

I’ve ported this code from my project Yuka (Yume is archived, so forget it^^) since multiple three.js devs wanted this implementation directly in the three npm package. The only routine that’s missing is the computation of the best-fit OBB. You can already use it in Yuka, but it will take a bit time to port it.

But even without this method all intersections tests as well as raycasting already work. Feel free to use it, the implementation is well tested and should be performant.

1 Like

Alright, thanks for your reply :slight_smile:
It’s in Three since v114, correct?