three-mesh-bvh serialized data

[arpu]

Hey would it be possible to add three-mesh-bvh serialized data to the glb?

right now i generate the bvh data on glb loading on client side

[donmccurdy]

I think it's safe to say this is possible. The process would look something like:

1. For each glTF Primitive construct a THREE.BufferGeometry
2. For each THREE.BufferGeometry, compute BVH with three-mesh-bvh
3. Serialize the BVH, storing the binary data either in spare accessors identified by Extras, or a custom extension like THREE_mesh_bvh.
4. Implement a plugin for THREE.GLTFLoader to access and deserialize the BVH data

I guess the other big question would be — is this the 'right' way to approach the problem? — and I'm not sure. There are alternatives like 3D Tiles that can assemble glTF models into a larger BVH, but (if I understand three-mesh-bvh correctly) this won't accelerate raycasting in the same way. There are also some ideas for spatial indexes within glTF files, but it's early days there.

The choice also somewhat depends on your use case — lots of simple objects? Or fewer, but more complex, objects? @gkjohnson might be the best person to ask about what general approach to precomputing a BVH is best.

[gkjohnson]

A user provided an example of how they're precomputing a BVH with three-mesh-bvh and storing and then loading it via custom GLTF extension in this issue. I think it's an interesting use case and probably a worthwhile one particularly in cases when generating the BVH can take 10s of seconds when using more detailed split settings. I've created this issue for the sake of tracking the concept of CLI tool for generating a BVH file or embedding one in an existing GLTF file and making the process more ergonomic. I'd need to think it through a bit more, though, to understand what a generic implementation might require. Unfortunately this isn't something that will be that high on my list but if anyone is interested contributing some help feel free.

There are alternatives like 3D Tiles that can assemble glTF models into a larger BVH, but (if I understand three-mesh-bvh correctly) this won't accelerate raycasting in the same way.

Depending on the 3d tiles implementation the tile bounds can at least be used as a kind of top level acceleration structure but it's probably less useful for accelerating raycasts against complex leaf node geometry. The 3d tiles renderer I worked on, for example, overrides the raycast function for the root tile take advantage of the existing bounds hierarchy to minimize the number of bounding box checks that have to be done.

lots of simple objects? Or fewer, but more complex, objects?

Generally three-mesh-bvh is best for larger, more complex object. For lots of simpler, dynamic objects a different top level acceleration structure like an octree or spatial hash index would be better, I think, but considering those structures are intended to frequently updated I don't think there'd be a big benefit to pre computing them.

[donmccurdy]

Neat to see already implemented! I don't think I have much to add to the Gist – a better starting point than my writeup above in that case. 😄