Expose 'count' property in BatchedMesh

[Kikedao]

Description

BatchedMesh doesn't have a public count property, InstancedMesh does though (https://threejs.org/docs/#api/en/objects/InstancedMesh.count).

Without it it becomes pretty complicated to know how many objects/geometries have been added to a BatchedMesh instance and do operations like traversing all of them to set the matrices, make sure you are in the range before updating one of them, etc.

Solution

I see that the BatchedMesh implementation is already using a private _geometryCount property, it should be as easy as to rename it as count and update the docs.

Alternatives

I think the proposed solution is the best as it would converge the API with InstancedMesh.

Additional context

No response

[Mugen87]

BatchedMesh doesn't have a public count property, InstancedMesh does though

Batching and instancing are two different things and it's not always a good idea to force an aligned API of InstancedMesh and BatchedMesh, imo.

I see that the BatchedMesh implementation is already using a private _geometryCount property, it should be as easy as to rename it as count and update the docs.

We can't implement the solution as suggested since users might assign values to count which interferes with how BatchedMesh uses the property internally. A getCount() method that reports the value of _geometryCount should work though.

@gkjohnson Do you see any issues with getCount()?

[gkjohnson]

it's not always a good idea to force an aligned API of InstancedMesh and BatchedMesh, imo.

I agree it doesn't make sense to align the APIs just for the sake of alignment. I think the use cases should be provided when suggesting API changes like this so it can be evaluated whether the suggested solution is the right one. But I assume this is for determining whether more geometry can be added?

Especially with BatchedMesh, though, (and #28462) whether a new geometry and instance can be added is more complicated than just count. It depends on the pre allocated vertex / index buffer lengths. And - once the optimize and delete functions have been added - just because there is an amount of free space doesn't mean it isn't fragmented (meaning optimize must be called).

I think functions like optimize and delete need to be considered and implementation plan made before making more changes like this to the class.