So, I currently generate a grid like this :

The way I do it tho is probably not the best (I drop from 400 fps to 100 fps with the grid active)

extends Node3D
@onready var grid_cell = preload("res://Grid/grid_cell.tscn")
var grid_size = 100
var cell_size = 2
var cell_spacing = 0.1

func _ready():
	generate_grid()

func generate_grid():
	for x in range(grid_size):
		for z in range(grid_size):
			var grid_cell_instance = grid_cell.instantiate()
			grid_cell_instance.transform.origin = Vector3(x * (cell_size + cell_spacing),0.1, z * (cell_size + cell_spacing))
			add_child(grid_cell_instance)

that grid_cell.tscn is a simple plane with a texture applied to it.

I was planning on adding an area3D to each cell to detect if the player is within the cell.

Does the grid change in some way? I generate mine once in the ready function. I guess if you have to move it every frame or something that would be a problem.

Why not just use a large plane and a shader that draws the grid?

After messing around it was another object generation that was messing with performance, I donn't get any fps drops (woohoo) !

I actually want to use those mesh positions to place objects, so I don't think a large plane would work.

How do people typically draw grids to place objects ?

  • xyz replied to this.

    Loxyrak If the grid is uniform then positioning can be easily calculated. You don't need repeating reference geometry at all. Godot also has the GridMap node that helps with precisely that.

      You can just have a huge quad with a repeating texture. Placing object can be done with code, no need for objects (the plane collision point and some math is enough).

        cybereality There are a lot of reasons to use individual tiles. You can change the border color of one tile, tiles in a path, accessible tiles, etc. They can store information, like if something else is on it. It's really trivial for a modern computer to generate individual tiles. They also don't have to be square. The math gets kind of weird for hexagonal tiles, but they work fine for astar, where you don't have to use it.

          It's a lot faster to have one quad versus 10,000 quads, even on a modern computer you have to deal with draw calls, and also engine overhead for each object. If you need a specific thing (let's say a different color for the one selected tile) you can have 1 dynamic square that can change color, etc. and place it on the selected part.

            cybereality Well, I don't care to find hexagons and I'm only using a little over 200. Even my computer can handle that without blinking. I would assume those blocks in minecraft are individual. 10,000 quads is nothing for a modern computer. It would still be considered low poly.

              It can add up if you're being wasteful on unnecessary things, yeah. 10,000 draw calls is not nothing versus 1. It's not the poly count, you could easily render a million polys on 1 object. But each draw call (even if it's a single triangle) has CPU overhead. Each object in Godot has overhead, because it has data to it, it could have a script, which now is calling 10,000 times per frame (and this overhead is there even if the script is absent or not doing anything). It adds up.

              Voxel worlds like Minecraft can use many tricks. Such as using hierarchical representations to cull or combine objects (things like octrees to cull hidden blocks, combining 100 blocks with the same texture into one block and batching it into one draw call, etc.).

              Yeah, you could probably eliminate all kinds of things like areas and who knows what, but those things are only important in a large game. If it is a small game, it is fine. I would rather be doing other things and get a game done. I try to only attach scripts to parent objects. When you are making the equivalent of a chess board, you do not need the same programming as an open world game.

              This is not a chess board. It's 10,000 squares, look at the photo in the first post.

              It's borderline, I'll go that far, but I still think you won't even notice it, even with areas or static bodies connected. And it is convenient having areas connected. Sure, you could do it without them, but for selecting and everything, it's nice to have them. At what point do you draw the line using a grid game, that's pretty close to it right there if you ask me, otherwise you would use some kind of moveable graph. Anyway, he's that far, why not just try it out?

              You can select things on a plane just fine (if the hit point is 362, 427 and the grid is 100 x 100, then you know it's block 3, 4 just doing some simple math).

              Also, you can store data in an array or dictionary on a main script, you don't need physical objects to store data.

              Granted, I agree you shouldn't optimize early, but you also shouldn't waste performance if there are simple solutions available.

                cybereality I've done it on a square grid, it is trivial for math, but I would experiment with it and see what happens because it might not always be a square grid, or it might lead to other ideas. That's the whole thing about prototyping. When it got to hexes and shifting them by the sine of 30 degrees or whatever, I didn't debate very long about it. I haven't seen one tutorial where coders used something other than individual hexes. It's kind of like telling coders to use a state machine when they are doing a platformer or whatever. It's not necessary for what they are doing and it will work fine. They got that far, why not finish it. If it's slow, use it on the next iteration. And really, he might find out less is more with that grid size.

                  Tiling, be it rectangular or hexagonal, is a simple form of space partitioning. In other words a grid structure already is an optimization in space management. If you just need scattered objects without any access optimizations, then why call it a grid?

                  I think the OP should specify more precisely what they're after to get better advice. Otherwise we're just guessing. But judging from what they wrote so far, looks like they're not aware of the benefits you actually get from using a regular grid (e. g. player's cell is always implicitly defined form the position, so no need at all for thousands of areas, which is an enormous overkill btw)

                  The goal is that the player can walk to a tile, store that tile information to a variable, and can build turrets, walls, etc on that tile. Atm, I use the tile position and add the turret with the position of the tile, if the tile is full, can't build on it.
                  If the tile is empty, the color of that tile is green.
                  If full, red.

                  The player has an area3D and when an area of group "cell" enters it, it gets stored as the current tile he is positionned on. It works, but I'm always on interested in other ways to do things 🙂

                  • xyz replied to this.

                    Loxyrak You always know on which tile the player is standing simply by looking at player's position.

                        xyz If it was a simple grid in 1 object you mean ?

                        • xyz replied to this.