"Merging" meshes with code

[Amerio.Stephane]

Hello,

Is it possible to "merge" (simple addition, not an actual CSG operation!) two ObjectMeshDynamic in code. The source meshes are generated from code but with different transform. The merge would "add" object2(with transform M2) into object1 (with transform M1). They have a single material and surface. This would be a one-time operation at run-time, so performance is not an issue.

Rationale: I'm generating tens of thousands of small meshes, very close to each other, all different (so a Cluster is not an option), and I feel they would benefit from being merged in small groups. Or should I not be concerned?

Thanks!

[karpych11]

Hello,

I tried to combine 40,000 objects into one mesh. The resulting object contains 40,000 surfaces, each containing vertices and indices from separate objects. After that, performance improved from 42ms to 15ms. A separate material can be set for each surface. You can see the result here. An example is in the attached files.

AppWorldLogic.cpp AppWorldLogic.h

[Amerio.Stephane]

That's a quick answer! Thanks a lot for the sample code and the performance boost proof!

[romain.janil]

could this batching be extended to an Editor functionality to static meshes? Like a merge meshes by material but after some world editing (should be one way of course, keep disabled copies of orginal meshes and create one big mesh out of multiple static meshes with transfoms but with single material/single surface) ? It's already possible to do that and export several meshes as one (export as .mesh) but then materials are lost which is a pity since original meshes in this use case have same materials/surfaces already.

Edited October 21, 2021 by romain.janil

[silent]

romain.janil

While this seems to be silver bullet to all the performance issues, on practice there are a lot of cases when such merging will not give any results (or even reduce the performance).

Right now we don't have any plans to add this code directly into the editor, but the situation could change in the future.

Thanks!

[romain.janil]

Hi no problem, it was just a suggestion, and indeed it's always about finding right balance between n objects/n meshes/n surfaces versus size of meshes etc...