Godot: Merge meshes

[Zylann]

Merging meshes into one is very useful for performance because draw calls get batched, especially for static objects, or even procedurally generated ones.

I don't think that such a thing exists in the API yet (correct me if I'm wrong). It can probably be done by actually getting all vertices per surface from a Mesh and joining them together, but this is extremely slow to do in GDScript, and requires custom code in C++.

In Unity, the Mesh class has a CombineMesh method with some options like how submeshes (surfaces) are treated, or if transforms have to be applied etc: https://docs.unity3d.com/ScriptReference/Mesh.CombineMeshes.html

Asked on QA: https://godotengine.org/qa/12531/merge-meshes

[bojidar-bg]

Wouldn't it be better if we get autobatching of draw calls with the same Material, like Unity has?

[Zylann]

That's dynamic and static batching, which is cool to have too, but it's just one usage of it.
I'm asking about the API possibility to merge meshes, because there are cases you want them combined in a specific way, be it for procedural generation or editor tools.

[reduz]

Godot already optimizes calls with the same materials, and static batching
in general will not give you much of a performance boost unless you have
thousands of different meshes.

If you have thousands of the same mesh, you can use instancing instead
which is more efficient

On Sun, Feb 19, 2017 at 2:50 PM, Marc [e-mail] wrote:

That's dynamic and static batching, which is cool to have too, but
different. I'm asking about the API possibility to merge meshes, because
there are cases you want them combined in a specific way.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7844#issuecomment-280935316,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z29l87JWgon2P_ThfvWozgQXKUen4ks5reIDtgaJpZM4MFWpT
.

[reduz]

Also, draw calls are cheap nowadays, and it will be MUCH cheaper in Godot
3.0 due to UBO/VAO.
Batching was mostly something really needed for DirectX9 level hardware.

On Sun, Feb 19, 2017 at 9:58 PM, Juan Linietsky [e-mail] wrote:

Godot already optimizes calls with the same materials, and static batching
in general will not give you much of a performance boost unless you have
thousands of different meshes.

If you have thousands of the same mesh, you can use instancing instead
which is more efficient

On Sun, Feb 19, 2017 at 2:50 PM, Marc [e-mail] wrote:

That's dynamic and static batching, which is cool to have too, but
different. I'm asking about the API possibility to merge meshes, because
there are cases you want them combined in a specific way.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7844#issuecomment-280935316,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z29l87JWgon2P_ThfvWozgQXKUen4ks5reIDtgaJpZM4MFWpT
.

[Zylann]

Well, in case it's really about dealing with thousands of them, there is no API to do it. I'm thinking about terrains (always coming back, this one example^^) or procedural things that cannot use instancing due to them possibly being lots of different meshes merged into one.

Is GridMap using instancing? Last time I tried it in 2.x I ran out of FPS really quickly, although all tiles were the same.

[reduz]

2.1 does not support instancing, but in 3.x it does

if you are looking for specific tools for specific use cases, let me know!

On Sun, Feb 19, 2017 at 10:33 PM, Marc [e-mail] wrote:

Well, in case it's really about dealing with thousands of them, there is
no API to do it. I'm also thinking about terrains (always coming back, this
one example^^) or procedural things that cannot use instancing due to them
possibly being lots of different meshes merged into one.

Is GridMap using instancing? Last time I tried it in 2.x I ran out of FPS
really quickly, although all tiles were the same.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7844#issuecomment-280967882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z26DqnGMCY38NVrIcTeiZfmEeXGBxks5reO2BgaJpZM4MFWpT
.

[kubecz3k]

@Zylann when it comes to GridMap you can bake geometry, however you need to do this in ready from code, since inspector 'bake' attribute don't seems to be doing anything (https://github.com/godotengine/godot/issues/3850). Also in case of gridmap there is some kind of performance issue if you have any kind of dynamic shadows on them (https://github.com/godotengine/godot/issues/3849). (Guess this one will go away in 3.0)

[Zylann]

@kubecz3k I didn't know that, thanks for the tip. I use my own C++ module to bake voxel-based terrain, so I do my own batching anyways.

As a result I personally don't have a use case for mesh batching yet, though one case I have in mind is when you have many different static meshes drawn many times (rocks, procedural clutter?), which means instancing will be of little help due to the variety of models.

I'm looking forward to test intensive 3D again when 3.0 will be more stable/feature-complete.

[Zireael07]

Collada scenes come in as several mesh instances, they would be a prime target for such a treatment.

Also as of alpha 2, the same happens to obj.

P.s. Being interested in procedural stuff, another use case is definitely merging procedural parts into one mesh.

[Zireael07]

Any hope of this happening? Best I can do in scripting is by using meshdatatool, but this creates a surface for each of the original surfaces, so no improvement.

[Perrottacooking]

hello Mr. Zylann
Still with the same problem at v3.1.1 Stable?
Thanks for you time

[Zylann]

@Perrottacooking not directly. I do use mesh batching in my voxel module because my concerns about having thousands of meshes were confirmed in various ways (mostly CPU bottleneck due to frustrum culling and eventually the GPU bottleneck). Could not use instancing here as well because it's still not as efficient and prevents features like baked SSAO, "autotiling", face culling, eventually unique features. So yeah I don't directly have this problem right now, since I kinda solved it in C++ by actually doing it, just in a different way. That wouldnt be viable in GDScript tho.

I think I posted this issue initially because someone else needed it and I realized that for procedural generation based on existing base meshes, having the opportunity to reduce CPU usage down to 1 mesh is a boon. Why settle for "good enough on my machine" performance with multiple meshes when you can optimize this with simple batching? It's probably doable in GDScript already, just not efficiently (mesh has to be downloaded from GPU it seems). Well, that was the idea at the time.

@Zireael07 did you need this?

[Zireael07]

Yes, batching several meshes into one is still necessary because eg. Collada imports are usually several meshes when they could easily be one.

[akien-mga]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!