BatchedMesh: add deleteInstance()

[Jordan-Lane]

Description

The BatchedMesh currently has no way to remove an instance.

Solution

Adding the deleteInstance() method to the BatchedMesh class will allow users to remove instances easily from the BatchedMesh.

The previous commented out code stated that we would need to implement an optimize function to be able to repack the data. Instead, I added a _fragInfo array to keep track of 'fragmented' or open blocks. The BatchedMesh will still fill the DataTexture the same way it did before, but once it is at capacity, then it will begin adding instances to open spots in the Texture.

Additional context

The BatchedMesh has been a pleasure to work with, I just need the ability to remove existing instances. This is my first time opening a PR to three.js, so please let me know if I am missing anything. I am open to any additional changes or suggestions!

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	686.03 169.81	686.37 169.89	+345 B +78 B
WebGPU	835 223.93	835.34 224.02	+345 B +82 B
WebGPU Nodes	834.5 223.81	834.85 223.89	+345 B +82 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	462.34 111.55	462.34 111.55	+0 B +0 B
WebGPU	531.77 143.36	531.77 143.36	+0 B +0 B
WebGPU Nodes	488.43 133.22	488.43 133.22	+0 B +0 B

[gkjohnson]

Thank you! #28638 also implemented deleteInstance but I quite like the approach of reusing instance Ids which will generally be more performant than having to re-pack the matrix & color buffers when trying to shrink and remap the list of instances.

The only potential point of confusion is that a user will have "deleted" an id only for it to be re-used again, which isn't necessarily severe. It just means that users will need to be diligent about tracking their ids.

cc @Mugen87 unless you have objections I'm happy with this approach for instance deletion and is a lot less complex than the other implementation. Supporting deletion / repacking of geometry is still an open question but we can address that in the future.

[gkjohnson]

What does the name "_fragInfo" refer to? It would be better to call this something like "availableInstanceIds"

[Jordan-Lane]

Sounds good, I like the name "availableInstanceIds". Will make that change

[gkjohnson]

I think we should check if there are any available deleted Ids and reuse those ids first rather than waiting until the full capacity has been used.

[Jordan-Lane]

I like this idea. It would be best to keep both the drawInfo and the available deleted ids as small as possible. I will make that change

[Mugen87]

cc @Mugen87 unless you have objections I'm happy with this approach for instance deletion and is a lot less complex than the other implementation. Supporting deletion / repacking of geometry is still an open question but we can address that in the future.

Sounds good!

[Jordan-Lane]

@gkjohnson Updated the PR with your suggestions

1. _fragInfo has now been renamed to _ availableInstanceIds
2. When adding a new instance we prioritize using any available Ids before expanding the drawInfo