Shakhriddin

@mrdoob, @Mugen87, @gkjohnson What do you think about this implementation of "optimize"?

> TBH, I'm not much in favor of this change. `BatchedMesh` became a very complex component in the past months and this PR makes it even more complex. To me,...

> * We shouldn't be exposing "drawIndex" as a _third_ id that a user can provide (and will never have access to otherwise) > If there is no **drawIndex** there...

Guys, thank you for your response, I thought it would be more useful to implement the optimization function because I worked on a similar case on my project and I...

> I don't have much preference beyond that. Immutability can be a useful characteristic in an API, and if we feel that it shouldn't be possible to do _removeGeometry_, for...

I am not insisting that they accept this PR, simply based on the fact that I think it is necessary to implement `optimize`, I proposed this option. Here the main...

> * We shouldn't be exposing "drawIndex" as a _third_ id that a user can provide (and will never have access to otherwise) > * Functions like `setColorAt` should not...

> Yes I mean that `drawIndex` shouldn't be user facing, which I think had been exposed as an optional function argument in a few places. > Yes, I fixed it,...

I agree with you @Makio64. I have already improved `BatchedMesh` class in my project, except `deleteGeometry`, `deleteInstance` and `optimize` functions custom `BatchedMesh` class can change the overall size of the...

> Replicating this issue with a single `BatchedMesh` is actually quite "simple." You just need to increase the `MAX_GEOMETRY_COUNT` in the `webgl_mesh_batch.html` example to ten times its previous value. On...