MergeMeshes Optimizations (Subclass, Async etc.)

Questions
1

Hi,
does someone have an example or explanation for the meshSubclass parameter in MergeMeshes function? Mesh | Babylon.js Documentation
We supply the function with an array of meshes, but meshSubclass only has one mesh. Do I have to understand it in a way, that I have an existing mesh and its vertex data will be overwritten by the merged mesh?
So without its use its a new mesh (immutable approach):
const mesh = MergeMeshes([mesh1, mesh2], true, true, undefined)
and with it, it will be mutated?
MergeMeshes([mesh3, mesh4], true, true, mesh)

Maybe follow up question: If I have a large mesh with many submeshes, is there an efficient way to replace a submesh even if indices of the new meshes are more than before?
I would like to reduce recalculation time for a mesh and only replace altered parts.
Partly answering it myself, looks like @Evgeni_Popov made a CompositeMesh here: Different meshes that share the same material, batching drawcalls? - #11 by Evgeni_Popov Not sure if it is fully covering my question, but seems nice.

And another thing I noticed for MergeMeshesAsync: This function uses a coroutine that needs one frame? for each VertexData type (position, color, uv…), since it yields after each one of them. I was rather expecting a function that would use another thread. Would it make sense to have such a function? Probably would need SharedArrayBuffer for faster I/O, but I also read some time ago SharedArrayBuffers dont have wide support yet. Just some thoughts…

2

No, if I understand it well, the meshSubClass, if provided, will be extended with the new data, existing data won’t be overwritten.

MergeMeshes is not able to replace data with other data, it can only create a new mesh or add data to an existing mesh.

cc @RaananW or @sebavan regarding the coroutine question.

1 Like
3

I assume you are referring to a worker when you mean thread?

Yes, there is room for improvement here. If you want to run the merge in a worker you will need to first copy the data to the worker, which will also take some time. What also costs a bit of time is bringing the data back and construct a mesh out of it.
You are right - it runs each one in a single frame (optimally). The idea is to do whatever we can to not block the main (UI) thread, but there are no fixed numbers we can use - i.e., if a mesh has more than 1000 indices it will take longer than a frame, and therefore we should divide it to 2 frames. But again - there ia always room for improvement, and we will love to hear if you have ideas.

2 Likes
4

Thanks for the explanations! Yes I am referring to a worker. Maybe I should just try it at some point with a big mesh in a playground and measure the performance. I could imagine that also the coroutine could use some more options concerning i.e. yield after x indices.

@Evgeni_Popov so MeshSubClass would be a rather nice approach for i.e. streaming mesh data?

1 Like
5

Yes, indeed!

2 Likes