BatchedMesh: add support for frustum culling per batched geometry

[gkjohnson]

Related issue: #22376, #27111

Description

Add support for frustum culling to BatchedMesh by storing the box and sphere bounds per geometry.

Upcoming PRs

• Raycasting, sorting support
• Object-level bounds
• Add support to ObjectLoader
• Move to core
• Documentation

[Mugen87]

So the PR adds a frustum culling check for each geometry of the batched mesh in onBeforeRender().

This is a different strategy to what is implemented in other classes. Normally, I would have expected bounding volumes on batched mesh level (similar to InstancedMesh or SkinedMesh). The computation of these bounding volumes happens automatically by the renderer (or or other components like in context of raycasting) when the access happens for the first time (meaning when their values are still null). Whenever the bounds require an updated, computeBoundingSphere() or computeBoundingBox() needs to be called on app level since the app updates the geometry data.

I think it would be more consistent to implement the bounding volume computation according to this policy for batched mesh as well.

[gkjohnson]

To be clear you're suggesting that we only generate bounding volumes on an as-needed basis for BatchedMesh, correct? I can adjust that if that's correct.

Whenever the bounds require an updated, computeBoundingSphere() or computeBoundingBox() needs to be called on app level since the app updates the geometry data.

This case is a bit different, though, since we're talking about a geometry that could have hundreds or thousands of bounding boxes - only one of them could be invalidated. I'm thinking adding an optional argument to "setGeometryAt" that indicates that the bounds should be invalidated is a good option.

[Mugen87]

on an as-needed basis for BatchedMesh, correct?

Yes.

This case is a bit different, though, since we're talking about a geometry that could have hundreds or thousands of bounding boxes - only one of them could be invalidated. I'm thinking adding an optional argument to "setGeometryAt" that indicates that the bounds should be invalidated is a good option.

BatchedMesh is indeed special compared to other 3D objects but I think it would be good to have bounds on object level so projectObject() in WebGL renderer can sort out the entire batched mesh if possible.

If you think it's important to have bounding volumes for each geometry of the batched mesh then I'm fine with that. But it would be good to add BachtedMesh.boundingSphere and BachtedMesh.boundingBox which enclose the entire batched mesh. Both volumes should be computed with BachtedMesh.computeBoundingSphere() and BachtedMesh.computeBoundingBox().

Ideally, frustum culling and raycasting test with the object level bounding volumes first, and then with the ones on geometry level.

[gkjohnson]

BatchedMesh is indeed special compared to other 3D objects but I think it would be good to have bounds on object level so projectObject() in WebGL renderer can sort out the entire batched mesh if possible.

I don't know if I agree that this is as useful - but I can support keeping the ability. I'd want the ability to disable that feature, though, since keeping the full bounding box up to date with many dynamic objects spread throughout the scene is not super useful. In this case how do you feel about a different field like "perObjectFrustumCulled" or "batchFrustumCulling" that can be set to toggle the the "onBeforeRender" frustum culling feature?

Also I just updated the PR to generate the boxes and spheres as-needed. When a geometry is replaced the existing bounding box is used or it's marked as needing to be regenerated.

[Mugen87]

In this case how do you feel about a different field like "perObjectFrustumCulled" or "batchFrustumCulling" that can be set to toggle the the "onBeforeRender" frustum culling feature?

That sounds good to me! However, in order to keep the class consistent I would be glad to see the object level features mentioned in #27120 (comment).

It's right that bounding volumes which enclose the entire batched mesh might not be useful for stuff like tiles rendering. But other scenarios might benefit from sorting out the entire batched mesh when rendering/raycasting. By implementing this approach, we keep the class consistent with InstancedMesh but can also provide more fine granular control over frustum culling with an additional property. perObjectFrustumCulled sounds good to me!

[gkjohnson]

Okay! I've just added "perObjectFrustumCulled" flag.

That sounds good to me! However, in order to keep the class consistent I would be glad to see the object level features mentioned in #27120 (comment).

I'll add this in another PR, then.

I guess one concern I have for things like raycasting or frustum culling when elements are dynamic (meaning the bounding volumes have to be regenerated every frame) is that the cost of regenerating the bounding box and / or sphere is more expensive than just checking the ray / frustum intersection with the child bounding boxes. Instancing would have the same issue, though I guess this would have to be tested.

[gkjohnson]

@Mugen87 I just updated the copy and toJSON functions to add support for bounds and perObjectFrustumCulled flag. This should be ready!

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
655.5 kB (162.3 kB)	655.7 kB (162.4 kB)	+281 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev	Filesize PR	Diff
448.1 kB (108.3 kB)	448.4 kB (108.4 kB)	+281 B

[LeviPesin]

I think something like _renderer.backend !== undefined ? _renderer.backend.coordinateSystem : WebGLCoordinateSystem would be more correct. /ping @gkjohnson

[gkjohnson]

I'm not familiar enough with WebGPURenderer to know

[LeviPesin]

@sunag What do you think?

[sunag]

I think we can use _renderer.coordinateSystem, it is compatible with both renderers.