3D grid placement in Godot 4: full setup tutorial

This is the written version of the full video walkthrough: the same steps in the same order, each with a timestamp link to the moment it happens on screen. Watch it, or follow along here — the two say the same thing.

One thing to get out of the way before step 1, because it trips people up: the recording's locked isometric camera is the game's choice, not a setting the plugin asks for. GridPositioner3D.camera is just a reference, and the 3D setup keeps whatever camera your scene already has — it only spawns one when the scene has none, and it never re-aims yours. So take the representation from the video and change the perspective to whatever your game uses: the part that has to change for 3D is the resource definitions and the node hierarchy, and those are the plugin's components. Everything below applies unchanged to a top-down, third-person or freely rotating 3D scene.

Use Grid Placement 6.3.0 or newer before you start. This walkthrough was recorded on 6.2.2 and re-checked against 6.3.0, where the one thing that changed is who owns the placer: Setup Scene no longer adds a PlacementOwner node, and the optional player reference lives on GridPositioner3D.placer_root. If you are on 6.1 or an earlier 6.2 build, two more names differ — the panel was BuildPanel and the object selector PlaceableSelectionUI; both are renamed below. Everything else in the setup is the same. The patch notes cover the rest of what changed; this article stays on the setup.

Every instruction below is checked against the shipped plugin source, and a test suite in the plugin repo pins the names this article uses, so a rename breaks a test instead of quietly invalidating the page.

You start with the plugin installed and nothing wired, and you finish able to press play, open the placement panel, drag out a pad, and stack crates on it.

1. Enable the plugin, then run the 3D hierarchy setup

0:57

Enable it first: Project → Project Settings → Plugins → Grid Placement.

Then Project → Tools → Grid Placement → Setup Hierarchy → 3D. The builder adds the rig you would otherwise wire by hand:

• GridPlacementHost — owns the bundle and the backend services.
• A world node with a GridMap surface for the terrain you paint onto.
• An objects parent for placed scenes.
• PlacementLevelContext — points at that GridMap through target_map_3d, and at the objects parent (2:09).
• GridPositioner3D — the aiming node; its placer_root takes the node the player steers, and leaving it empty is supported when no rule needs a player (2:01).

The one-click setups, and how much they save you

The recording leans on four editor actions, and between them they replace what used to be an afternoon of hand-wiring. Every one of them is idempotent and additive: they fill in what is missing and leave your own values alone. The plugin's own One-Click Setup guide covers the same ground in more depth — what each command builds, and what it deliberately leaves to your game.

Action	What it does	In the video
Grid Placement → Setup Hierarchy → 3D	builds the host, the GridMap surface, the objects parent, the level context and the positioner in one press	0:57
Grid Placement → Setup Scene	the same builder, but you pick the grid type from a popup instead of from the submenu	—
Grid Placement → Setup UI	adds the panel, the mode hotbar and the target informer	3:15
Grid Placement → Setup Default Input Actions	writes every input action the plugin needs, without overwriting a name you already use — this is why step 11 is one click and a restart, not a hand-built Input Map	11:26
Grid Placement → Validate Current Scene Setup	lists what is still missing (including absent input actions) before you press play	—

Two presses on purpose: the rig works headless, so Setup Hierarchy does not force the UI on you, and Setup UI stays a separate decision. Nothing here touches your camera — it is wired to the rig as a reference, and the camera you already have keeps control of the view.

2. Check what the demo already wires for you

2:31

demos/3d_iso/iso_3d_tutorial.tscn is the same rig, wired with resources you can read: the bundle, the session, the catalog and the terrain palette. Its camera is a plain IsoLockedCamera the demo owns — exactly the split described up top, the demo keeps the view and the plugin only reads it through the positioner.

Read those before building your own, and see Getting started for the parts this article skips.

3. Know the three UI pieces

3:32

• ModeSwitchBar — the hotbar that switches placement modes.
• TargetInformer — reports what is under the cursor.
• PlacementPanel — the Terrain / Objects tabs; enable_terrain_palette has to be on for the terrain side to appear (3:15).

They ship as template scenes. Step 10 detaches the panel from the template on purpose.

4. Create scene placement entries

3:41

Scene placement entries are what older versions called placeables. Each is a resource — ScenePlacementEntry — carrying a packed_scene (what gets instanced), profiles (the panel grouping) and an optional snap_profile_3d (the rules). Create one in the entries folder and assign the scene — in the recording, a plain cube standing in for a crate (4:24).

The scene is only what gets instanced. The resource is where behaviour lives.

5. Give the entry a 3D snap profile

4:40

Open the entry, add a snap_profile_3d, and set its family — call this one crate. Family is what an entry is; snaps_with is what it may attach to, and it is a directional accept-list.

Leave snaps_with empty on this first entry. That is the plain crate you drop wherever there is open space.

6. Duplicate it into a stackable crate

5:06

Duplicate the entry, rename it (the recording uses crate non-stacking and crate stackable), and point the duplicate at the stackable scene.

Then the two settings that make it stack:

• snaps_with: ["crate"] — it accepts crate-family hosts, so it sits on any crate (5:47).
• require_column_support — on. The footprint needs column support underneath, which is what lets the crate stand on the terrain as well as on other crates (6:02).

require_column_support is the property the inspector shows; require_ground_cell is the stricter sibling that demands a GridMap ground item in every footprint column. Leave occupy_columns on — that is what stops two CELL pieces claiming the same column.

7. Register the GridMap tiles

6:21

Each paintable tile needs a TilePlacementEntry whose terrain_name matches the tile's name on the GridMap (pad and block in the recording; ground, block and stone in the demo). target_layer_name is there if you paint into a specific layer, and demolishable controls whether the tile can be removed again (7:13).

Group the entries with a TerrainPalette and its entries array (7:26).

8. Group the entries into a catalog and a placement profile

7:47

• PlacementCatalog — scene_entries and tile_entries: everything the panel can offer.
• PlacementProfile — the UI grouping, separate from family. Set its display_name (objects) and add it to each entry's profiles array; that is what puts them under one tab (8:07).

Drag and drop assigns the profile to an entry.

9. Decide the tile rules

9:14

Tile entries carry two switches that matter here:

• require_existing_ground — off in the recording, so a pad can be painted into open grid space. Turn it on if your game should refuse floating tiles.
• stacks_on_occupied_cells — off by default; on allows painting over an already-painted cell.

Anything beyond those is a placement_rules entry. The shipped tile-paint rules are ExistingCellRule, TilePaintCollisionRule, ProviderCellBlockRule2D and AdjacencyRequiredRule; note that ExistingCellRule is 2D-only (it reads a TileMapLayer), so it does not gate 3D GridMap painting.

10. Point the panel at your folders and palette

9:38

Make local the panel rather than using editable children: make local detaches the instance from the template, so a template reinstall cannot overwrite your wiring (10:10).

Then:

• SceneEntrySelectionUI — scene_entries_folder and category_profiles_folder (10:21).
• TerrainPaletteUI — terrain_palette (10:48).
• PlacementPanel — enable_terrain_palette, with the catalog assigned on the session (11:19).

11. Create the input actions

11:26

Project → Tools → Grid Placement → Setup Default Input Actions writes the actions without overwriting names you already have (12:13). Restart the editor afterwards so the Input Map shows them. The confirm action is the one that commits a placement (12:21).

12. Play: paint a pad, then stack crates on it

12:29

Press play, open the panel, and pick the terrain tab. Hotkey 2 enters build mode by default; drag out a pad (the recording does an 8×8) (12:35).

Switch to objects and place blocks: because the block entry can stack it sits on other tiles, while the non-stacking crate accepts one crate per spot and refuses a second (13:31). The stackable crate goes on crates and on ground (13:54).

13. The limitation you will hit: GridMap height is fixed

12:57

A 3D GridMap gives every tile the same height. The recording's pad is deliberately shorter than a block, so a block on a pad floats, with a visible gap. That is the data, not a bug.

If your game needs objects at genuinely different heights, compare against the scene-stacking approach: 3D Object Placement.

What this walkthrough does not cover

Rules, validation and manipulation beyond snapping and stacking are in the guides: start with Placement rules, and for the object-versus-terrain decision Choosing terrain vs objects. For whole rooms placed as one object, with storeys stacked on top of each other, the 3D room placement tutorial takes the same rig further.

Grid Placement is a commercial plugin for Godot 4, available on itch.io; the guides and API reference are public.

If you would rather watch it

The video walkthrough covers this article end to end in about fifteen minutes: the same thirteen steps, the same four one-click setups, with the editor at full size. Every step above links to the second it starts, so you can jump from a step you are stuck on straight into the recording.