Does set_cell update collision automatically?

Within the same frame, yes — the TileMapLayer batches updates and a physics rebuild happens at frame end. The bug pattern: code mutates tiles in a custom thread or before the layer has fully entered the scene tree. Force an explicit rebuild with notify_runtime_tile_data_update or call update_internals.

What's the difference between TileMap and TileMapLayer in Godot 4?

Godot 4.3+ deprecated TileMap in favor of TileMapLayer — each layer becomes its own node for cleaner Z-ordering and per-layer transforms. Migrating: split each TileMap layer into its own TileMapLayer child.

Why does my collision lag one frame behind the visual?

The visual updates immediately on set_cell; physics rebuild happens during the next physics tick. Either query physics state next frame, or use call_deferred to run dependent logic after the rebuild has settled.

Fix: Godot TileMapLayer Physics Collision Not Rebuilding

Quick answer: Call tilemap_layer.update_internals() after a batch of set_cell calls. Verify the source TileSet’s collision polygon is non-empty for the tile id you placed.

A destructible-wall mechanic clears a tile with set_cell(coords, -1). The visual gap appears immediately; the player’s rigid body still bounces off invisible geometry where the wall used to be. Physics didn’t catch up with the visual.

How TileMapLayer Rebuilds Collision

Each TileMapLayer node maintains an internal PhysicsBody2D per-physics-layer. When you call set_cell, the layer marks itself dirty. On the next frame’s internal update, the body rebuilds based on current tile occupancy and TileSet collision polygons.

Two patterns trip this up:

You mutate tiles and immediately query collision in the same frame — the rebuild hasn’t happened yet.
You change tiles from a thread or callback that runs outside the normal node lifecycle (e.g., a deferred multiplayer sync) — the dirty flag fires but the rebuild is delayed until the next physics tick.

The Fix: Explicit Update

@onready var walls: TileMapLayer = $WallsLayer

func destroy_wall(coords: Vector2i):
    walls.set_cell(coords, -1)
    walls.update_internals()   # force collision rebuild now

update_internals() runs the dirty-rebuild path synchronously. The physics body is current before the next line of your code executes. Downstream physics queries see the new shape.

Verify TileSet Collision

If update_internals() doesn’t help, the TileSet itself might be missing collision data for the tile you placed. Open the TileSet resource:

TileSet panel → Physics Layers → ensure at least one layer is added.
Click a tile in the atlas. In the right panel, switch to the Physics tab.
Draw a collision polygon for the tile (or use “Add a rectangle” for solid blocks).
Save the TileSet. Tiles using this id now have collision.

Missing polygons silently produce tiles that draw but don’t collide — the inverse of the original bug. Both directions exist.

Batched Updates

For multiple tile changes in one tick:

func clear_room(rect: Rect2i):
    for y in range(rect.position.y, rect.end.y):
        for x in range(rect.position.x, rect.end.x):
            walls.set_cell(Vector2i(x, y), -1)
    walls.update_internals()   # one rebuild for all changes

Calling update_internals once at the end is much faster than per-cell. The TileMapLayer’s internal coalescing handles this if you skip the explicit call, but only on the next frame.

Verifying

Enable Debug → Visible Collision Shapes. Mutate a tile. The collision polygon outline should disappear at the same instant as the visual. If the outline persists for a frame, the rebuild is lagging.

“TileMapLayer collision rebuilds are deferred by default. Call update_internals when you need synchronous correctness.”

Wrap destroy_wall and similar runtime mutations in a helper that always ends with update_internals — saves the lag-by-one-frame trap.