Three.js: Feature Request: Support raycasting against BufferGeometry with morph targets

[WestLangley]

I assume we want to support this...

[Mugen87]

Hint: Mesh.raycast() already supports this with Geometry. It is therefore all the more important to provide this feature in context of BufferGeometry.

I'll have a look at this 👍

[Mugen87]

I have the code ready but I discovered something problematic in my tests. Even if Mesh.raycast() supports BufferGeometry with morph targets, the ray intersection tests always fails if the morphed geometry is bigger than the original one. The problem is that the bounding volumes are computed for the static geometry once and not updated with the morphed geometry 😅 . This happens already with Geometry. The method only works correctly if the user manually computes the bounding volumes.

To solve this problem, the library could compute bounding volumes that encloses the maximum extent of the geometry. Or it updates the bounding volumes per frame although this is less efficient than the previous approach. But it would be a nice feature to have the real AABB or bounding sphere of the mesh.

BTW: three.js needs something similar if it ever wants to support raycasting against skinned meshes. Unity for example offers both type of bounds computation in this context.

[Mugen87]

I suggest for now to add support for morph targets to BufferGeometry.computeBoundingBox() and BufferGeometry.computeBoundingSphere(). Both methods would compute the bounding volume that encloses the maximum extend of the geometry.

[manthrax]

The tricky part of supporting these kinds of operations is that they are dependent on the animation data.

For instance lots of skinned characters I encounter in the wild have vertices that are immediately transformed to a completely different volume by the first frame of animation.. so without the context of the animation and its current frame of playback.. you can't really compute anything meaningful in terms of a bounding box or sphere. Additionally, any automagic computation or updating of boxes, would then preclude the animation being done on the GPU, and incur a cost proportional to number of transformed vertices, to update that bounds.

The problem is also compounded by the fact that some characters are composed/exported as multiple meshes separated by material but bound to the same skeleton.

That said, having a version of computeBoundingBox and computeBoundingSphere that did the heavy/accurate version for a given frame, would be super useful.
I would then probably make a 1 frame animation of the character, stretched out to their largest anticipated range of motion.. compute the boundingbox of that frame in my app, expand it by some fixed padding amount, and just use that, and forgo having super optimal frustum culling in favor of simplicity with just using conservative bounds.

As it stands now, I'm pretty much having to hand define a default bounding for each new character I import.

[WestLangley]

I'm pretty much having to hand define a default bounding for each new character I import.

@manthrax Or you could set

mesh.frustumCulled = false;