Static batch, or mesh combine?

Unity Engine
, , , , ,
1

So i have game with many levels. Most of them have static objects, like walls, surrounding, but everything is generated from tiled maps or placed randomly. For now im doing this in that way:

  1. Instantiate object from list of possible elements or get them from object pool. Source elements are never used, they are hidden.
  2. I have some sort of object “parents-group” with simple script, using CombineInstance, CombineMeshes() etc, to combine all these objects relocated to their groups (for example: trees to tree-group, walls to wallgroup, stones to stonegroup)
  3. After mesh is generated, all instantiated elements are hidden, and waiting for next level. If player die at level, they are reused (only moving/interactive items are resetted)
  4. At next level, combined mesh is replaced by new mesh, and objects are reused or created new, if pool is empty

I did this some time ago, but remember this actually reduces Batches. My levels for now have about 100-300 batches and 100k-300k Tris/Verts, but both rather below 200 (200k). I don’t know if this proportions are okay.

Now im wondering, if grouping them in these groups, and then cast at them StaticBatchingUtility.Combine would be better?
I see downside of this - all objects combined in this method are unusable now, and I need to remove all group, all objects and reinstantiate them again. As far I know it’s very recommended to avoid instantiating and using object pools.
This is stricte theoretically topic for now, because i didn’t see any lagging and problems with my game on mobile FOR NOW. But if I add more and more objects, maybe this cause some problems.

2

Grab your wondering and move from the theoretical to the actual, where it actually matters.

Remember, theoretical performance DOES NOT MATTER!!

For all performance and optimization issues, ALWAYS start by using the Profiler window:

Window → Analysis → Profiler

Generally optimization is:

  • avoid doing the thing that is slow (easiest)
  • do it fewer times and store its result
  • do the slow thing less frequently over time
  • do the slow thing when nobody cares much (during level loading or in another thread, etc.)
  • find a faster way to do the thing (hardest)

DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out: measuring with the profiler.

Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

3

I mean, when I was making mesh combining feature, I indeed watched in profiler, if this actually DOES something, or not. And numbers was decreased, maybe not drastically, but always. Also Im learning and it’s fun.

Yes, i know that, if I will do second option, and compare them, answer will come. But this also mean work to do :smiley: so I decided to first ask more experienced users what is their opinion, because maybe this is not worth time spent on remaking this. Now it isnt my priority. Still, I was thinking it is good topic to be asked.

4

Experienced users reach for the profiler, perhaps the frame debugger.

Again, opinions and theory don’t matter.

At a minimum, measure first, don’t guess.

What matters is how your specific software runs on your specific hardware.

And since your original post mentioned object pools, just beware:

The costs and issues associated with object pooling / pools:

In very rare extremely-high-count object circumstances I have seen small benefits from pooling.

In MOST circumstances, object pooling is a source of complexity, bugs and edge cases while not giving any measurable benefit.