You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Kikedao
changed the title
Expose count in BatchedMesh
Expose 'count' property in BatchedMesh
Apr 10, 2024
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.
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.
Description
BatchedMesh
doesn't have a publiccount
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 ascount
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
The text was updated successfully, but these errors were encountered: