- Home /
Suggested maximum size for a combined mesh
Hi everybody,
My project is a 3D action game for mobile (testing in Android now). The scenario is a procedural terrain generated by around 100 pieces. All the pieces share the same material and have a low number of vertices. But some pieces are more complex and break the dynamic batching because they have too many vertices.
My idea has been to combine all the pieces in a single mesh with CombineMeshes. And it works. Now I can have one single big mesh instead of 100 small meshes. The size of the big mesh is around 20000 vertices (and 10000 triangles). I don't need to worry about the dynamic batching of the terrain pieces. The number of batches (seen in Editor Stats) is smaller now.
I am just worried that 20k vertices is too much for a single mesh in a mobile game. Although my phone (2 years old) can handle it without problems. And my plan is to make bigger terrains (50k in total maybe).
So, in your opinion, is it ok to have a big mesh with 20k or more vertices? or will it be better to have several smaller meshes? For example, combine meshes with a limit of 10k vertices.
Thanks to whoever has an opinion on this matter.
Answer by AurimasBlazulionis · Sep 13, 2016 at 03:54 AM
It is completely OK, As long as you do not exceed 65k vertices, you will be fine. Combining meshes into one will only reduce draw calls, thus improving performance.
Where did you get that 65k vertices limit? That is exactly the number I was looking for. Thanks.
Around 65k is a limitation of unity. This is what a single mesh can be.
Also, never forget accepting correct answers as other people will know which one is correct.
For feature reference: Unity standard uses 16bit meshes which allow up to 65k something vertices. You can however allow Untity to use 32bit meshes but when doing so you can't make use of dynamic batching which drastically impacts performance. But with 32bit meshes you can go up to 4 billion something vertices? (not sure about this but a 16 bit integer can go up to 65k while a 32bit can go to 4 billion (2 bil positive, 2 bil negative) so I'm just guessing here.
Answer by CarpeFunSoftware · Sep 13, 2016 at 04:38 AM
My understanding: You CAN combine it all into a big mesh, within the limits, but why would you want to? Sure, the polygons that are not in the view frustum will get culled eventually, but it's better to cull the entire object if it is out of bounds.
I usually divide things like terrain up into large logical "chunks" that are easily culled. Do a test case where you have lots of stuff BEHIND you and in front of you in one big 64K (or whatever) mesh. Then do another with it cut into chunks where many chunks are not visible.
A mesh object is stored as an array of all that data. Why process the whole thing all the time? Unity knows the bounds of the meshes and can cull based on that (object culling). If 3 draw calls are faster than 1 large one...you "win". If not unity can often batch them for you and will combine them internally (assuming you don't break batching). If I remember properly, dynamic batches are smaller, though, so you may want to "batch" them yourself. I'd still do it in chunks, though.
This calls for testing in your use-case to see what works best. Various things break batching, for example.
(2 cents)
I agree, but when the area is not so big and the mesh does not change, it makes a lot of sense to combine everything into one mesh. Also, as the OP said, his combined mesh is 20k vertices, which is not so much, because phones/tablets 3 years old can easily handle over 100k verts.
That's right. The terrain is big enough to have part outside the camera view. But, it's not huge. By the way, it is a top down camera. Let's say that I split the terrain in big chunks, camera view size. In the best case, only one chunk needs to be drawn. In the worst case, 4 chunks need to be drawn. I estimate 5k to 10k vertices per chunk for that size. What is more efficient? To draw 4 chunks of 10k or a big mesh of 50k? $$anonymous$$y guess is that it is more efficient to draw only one mesh. But that is supposing that the time needed to draw one mesh of less than 65k is more or less the same as drawing one mesh of 10k.
As you can see, it is not a lot of vertices. $$anonymous$$odern phones can move a lot more. $$anonymous$$y concern is if old phones will have a huge performance drop because the mesh is too big.
In case I need bigger terrain I can made chunks. But that is not the case. I think I can limit the terrain to 65k vertices.
$$anonymous$$ore info: shader is mobile diffuse and there is only one directional light. I have realtime shadows enabled. The terrain has no collider (player is flying above it).
Well in that case, if it's top down and you already know you're drawing all 4 most of the time, sure, combine them. Sounds like they're in the view frustum 90% of the time.
The things you'd have to watch out for (in general, not necessarily your specific case): 1) Occlusion Culling is done on a per-object basis, so having one big mesh with occlusion culling active won't gain you anything. 2) If you're re-computing the terrain as the player moves for some reason and you have to itterate through 64$$anonymous$$ verticies and drop some, add others, and you need to do that per-frame... it gets expensive vs "stripes" or "chunks" that you can drop off the end of a grid and then add more. 3) Culling can happen TWIC$$anonymous$$..once for the mesh and once for the SHADOW...so that's a double-bump for culled stuff. (You mentioned shadows in the reply).
Like I said, it all depends on your use-case. Pat answers are just pat answers...we don't have the details of how/when you need to compute stuff, for example. You'll have to know your situation, think about it, and maybe do some tests. You may find that you'll eventually exceed the vertex limit and have to cut it up anyway! :p So...
I've have a set of "helper" routines in the game I'm working on now that combines meshes by material (destructible environment) and drops them into a "grid" in the game world. This grid is configurable in edtior. So I could have a 1x1 grid (your one large mesh) or, say, a 5x5 grid. Whatever. Thus I can simply change a variable in the editor and retest. Tests so far show that the multi-chunk grid is faster. But that's $$anonymous$$Y use case, not yours (and it's not terrain...my terrain IS cut up though, for different reasons than I want to explain now...but performance is still one of them).
There's no one perfect answer. And although draw call reduction 99% of the time is faster, there are cases where adding a few extra ones is faster if you culled objects. A variation on an old saying "The fastest objects are the ones you don't draw/compute-much".
Very useful comment, thanks. That about the shadows, I will keep it in $$anonymous$$d.