Grid system with visual display and best optimzation

I was wondering how can I create a grid system that does show each grid visually both in game and in editor without creating a game object for each grid (unless thats the only way). I need to be able to adjust properties on each grid and have the grid reflect it visually accordingly.

If there is not other way but but to spawn a grid game object to display it visually, then about many grid can I display before I run into frame rate issues?

There is, you could use a custom mesh with voxel colors and stuff, or even a normal cube with a texture on it and set the textures colors
There is always a better way than spawning 10million little objects

Depends the style and size of the grids you want and how much you need to have displayed at once… If you grids are small (ie 100x100) and cells are colored quads you’ll get away with a gameObject per cell.

If you world can be massive (ie: 10000x10000) then you need to go the smart way.

The base of anything you’ll do is probably to separate data from visualization, so that your cells exist in memory even though they don’t have a spawned visual representation.

When you have that data setup, you need to calculate which cells are currently within in viewport range and depending on what you’re doing, either create a mesh for the whole displayed area or spawn (from a pool !) gameObjects for each cell.

When the player moves the camera you calculate the delta with previous viewport and add/remove only the cells that need to be and it should be an extremely runtime efficient way to display grids of anysize. In editor you could enforce a refresh of the display when values are tweaked.

Note that if zoom is possible you need to take that into account when calculating cells in viewport range and you migh need to consider LOD of some sort.

When you said a normal cube, and changing its texture and colors, won’t each cube be a grid and I still need to spawn a cube for each grid?

100x100 is likely more than enough for me.

Though I am wonder how I should proceed with the method you suggested. Do I spawn visual objects during run time? Or do I set them up in editor first, and enable and disable them accordingly at run time?

No, I meant a cube with a texture, 1 single cube, and then by setting the colors of the texture, you can 1 cells color, but I think it would be a bit unefficient

So 1 grid texture, and I manipulate the texture at run time base on memory grid? Doesn’t that texture manipulation at run time fall under shader stuff?

It could, but by using SetColor, you can do it without shader, but like I said, it could be very inefficient

Hard to tell what’s best without knowing more about what you’re trying to do and what is your context, like is this for a mobile or desktop/console game ?

If you need to tweak things in editor it might be simpler for you to create objects at edit time… (and nothing prevents you from making a script you can use either at edit or run time and decide later wether you’ll keep preplaced objects or not)

It is for PC. It is a platformer and I want to set up the the editor like a level editor in game so our level designer can easily generate levels.

I’d suggest you to do the following:

  • Create a plane object, make it as large as required (the overall size of a grid)
  • Assign this plane a tiled material with a square texture (make sure that each tile has a size of a required cell)
  • Add a collider to this plane
  • Check whether a user clicked/tapped on the plane or not (there are a lot of posts about how to do this) and calculate an x-y index of a virtual/plane cell selected
  • Create another plane/thin cube with a size of a cell, you can set this object’s color to something different from plane’s one (remove a collider from this cell, it’s just a renderer)
  • If some virtual cell on a plane has been selected reposition the cell game object and display it

I hope this trick will help you.

2 Likes

Nice clean & easy solution for a simple grid system indeed, well suited in many situations, but how does he gets the cell customization he asked about this way ?

Also beware it might looked jagged in the distance if viewed at some angle with perspective cam (should be fine in 2D view with ortho cam however).