What is the impact of smaller cell sizes in a grid when it comes to performance?

Unity Engine
,
1

My project uses a lot of tilemaps. A lot. There are several grids that I use to manage these tilemaps.

Recently, I’ve been using a grid cell size of 0.1 on the X and Y, which gives me a crazy amount of flexibility when it comes to placing tiles. The tiles that I use are not your typical grid based tiles. They are all over the place in terms of sprite sizes (I use sprite atlases to mange my sprites). To get the look I’m after, I need to be able to place tiles in such a way that allows me to move them freely without being locked to a grid. However, I still need to use tilemaps, otherwise I’d have 10’s of thousands of game objects, and that’s not good.

The lowest I typically make my cell size is 0.3 on the X and Y. This still gives me flexibility when placing tiles, but I wanted to try and go even smaller. Does this smaller cell size result in a performance loss due to some internal calculations with tilemaps?

For reference, I have a few, very large tilemaps that I split into sections for performance reasons. These tilemaps are in a grid with a cell size of 0.3 on the X and Y. I also created a few smaller tilemaps inside another grid with a cell size of 0.1 on the X and Y. Even in scene view, the large tilemaps inside the grid with the larger cell size gives me better performance (again, even in scene view and not an actual build) than the much smaller tilemaps inside the grid with the smaller cell size. This leads me to believe that the smaller the cell size, the greater the impact on performance.

I just wanted some confirmation on this, aside from my observations. For now, a cell size of 0.3 on the X and Y gives me the best performance overall, so this seems like the best choice, but I couldn’t find any mention of cell size with regards to performance in the Docs, but perhaps it’s mentioned elsewhere?

2

It’s gonna be different on every target piece of hardware.

More specifically, it is likely more the geometry processing, as smaller cells require many more vertices to be generated, but that’s just my silly random guess.

That’s certainly a reasonable conclusion for you to draw, but know that this is only valid in your specific engineering context: your camera size, object speeds, etc. You know your engineering surface better than any of us and the answer for your game might not be the same as for another game.

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
  • 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.

https://discussions.unity.com/t/841163/2

Remember that you are gathering information at this stage. You cannot FIX until you FIND.

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Don’t forget about the Frame Debugger window either, available right near the Profiler in the menu system.

Notes on optimizing UnityEngine.UI setups:

https://discussions.unity.com/t/846847/2

At a minimum you want to clearly understand what performance issues you are having:

  • running too slowly?
  • loading too slowly?
  • using too much runtime memory?
  • final bundle too large?
  • too much network traffic?
  • something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

“Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs.” - Mike Acton

3

Always love to hear from Kurt :wink:

Thanks for the great explanations!

From the small tests I’ve performed on lesser hardware (Steam Deck) than my own desktop environment (13900K, 4090, blah blah blah…), it seems as though my conclusions about the cell sizes are, at least, in the ballpark.

Obviously, profiling and testing, testing, and more testing, is going to reap more rewards than guessing, but I suppose my motivation for posting this question about cell sizes in the first place was to arm myself with just a bit more information regarding the engine’s capabilities for future use. You can never stop learning, and over the course of the past two years, what I have learned about Unity is staggering, and yet it’s minuscule compared to what’s actually possible.

Thanks again, Kurt. All good advice, as usual.

4

i think the overall notion is gonna be, the more tiles the tilemap has, the worse the performance, isnt the smaller cell size forcing you to display more tiles than the larger cell size?

5

It allows you to place/overlap tiles much closer to each other, but not necessarily display “more” tiles (although that’s an option). I still use the same amount of tiles. The tiles that I use are all very odd sizes and shapes, so having the freedom of being able to place them where I want them, and not limit myself to a larger cell size (which forces you to place tiles further apart from each other), was advantageous. However, there appears to be a pretty severe trade-off if you happen to use a small enough cell size.