Large 2d tilemap causes 4-5ms lag on setcell invocation

stochastics · October 31, 2025, 6:15pm

Godot Version

4.5

Question

I’m working on a top-down farming/simulation style game with a pretty large tilemap (700x700 tiles / 490,000) and there is extremely noticeable lag when I call setcell (4-5ms per frame). I have tried both terrain connect (which is slightly worse than setcell) but even a raw setcell (on a single tile) causes fps to plummet.

I’m trying to get some guidance before I do a large technical refactor. Some posts online seem to suggest that breaking this down into smaller tilemap chunks might provide better performance gains, but this would be quite a bit of work at this point so I’d like a better understanding before I commit to a weekend-long refactor.

I’m wondering if there’s something I could be overlooking in the meantime? Or if having say 100 tilemap layers of 5,000 tiles each is the better way to go.

This post Lag issue with set_cells_terrain_connect seems to mention it but never got resolved.

My cpp is rusty, but trying to look through the source:

github.com/godotengine/godot

scene/2d/tile_map_layer.cpp

250ef8dc3


      
          	}
          	if (cell_flip_v) {
          		dest_rect.position.y = -(dest_rect.position.y + transposed_size.y);
          	}
          	dest_rect.position += p_position;
          
          	r_dest_rect = dest_rect;
          	r_transpose = final_transpose;
          }
          
          void TileMapLayer::set_cell(const Vector2i &p_coords, int p_source_id, const Vector2i &p_atlas_coords, int p_alternative_tile) {
          	// Set the current cell tile (using integer position).
          	Vector2i pk(p_coords);
          	HashMap<Vector2i, CellData>::Iterator E = tile_map_layer_data.find(pk);
          
          	int source_id = p_source_id;
          	Vector2i atlas_coords = p_atlas_coords;
          	int alternative_tile = p_alternative_tile;
          
          	if ((source_id == TileSet::INVALID_SOURCE || atlas_coords == TileSetSource::INVALID_ATLAS_COORDS || alternative_tile == TileSetSource::INVALID_TILE_ALTERNATIVE) &&
          			(source_id != TileSet::INVALID_SOURCE || atlas_coords != TileSetSource::INVALID_ATLAS_COORDS || alternative_tile != TileSetSource::INVALID_TILE_ALTERNATIVE)) {

github.com/godotengine/godot

scene/2d/tile_map_layer.cpp

250ef8dc3


      
          void TileMapLayer::_deferred_internal_update() {
          	// Other updates.
          	if (!pending_update) {
          		return;
          	}
          
          	// Update dirty quadrants on layers.
          	_internal_update(false);
          }
          
          void TileMapLayer::_internal_update(bool p_force_cleanup) {
          	// Find TileData that need a runtime modification.
          	// This may add cells to the dirty list if a runtime modification has been notified.
          	_build_runtime_update_tile_data(p_force_cleanup);
          
          	// Callback for implementing custom subsystems.
          	// This may add to the dirty list if some cells are changed inside _update_cells.
          	_update_cells_callback(p_force_cleanup);
          
          	// Update all subsystems.
          	_rendering_update(p_force_cleanup);

I’m assuming this is because the single set_cell is still forcing an internal update, and on such a large resource, this is the problem?

mrcdk · October 31, 2025, 6:57pm

Did you change the TileMapLayer.rendering_quadrant_size or enabled CanvasItem.y_sort_enabled? The quadrant size is a rendering optimization so changing it to a lower value or enabling y-sort (it forces it to 1) will affect performance every time the tilemap is changed.

Do you have physics or navigation layers in your TileSet? Modifying the tilemap will also modify the underlying shapes and polygons so it will take more time too.

stochastics · October 31, 2025, 9:51pm

I do have physics layers but not navigation.

Interestingly, if I uncheck “Occlusion Enabled” and “Collision Enabled”, the lows go down to like 40fps and it lasts for a long time.

Here’s some experiments with rendering quadrant size (fps isn’t ACTUAL I’m just trying to illustrate the jitter severity versus duration):
1 - Unplayable
4 - Jitter is mild, but lasts incredibly long and stacks up | fps avg: 80, highs: 80, lows: 80
8 - Jitter is noticeable, but lasts longer | fps avg: 160, lows: 140, highs: 160
16 - Jitter is sharper, but over faster | fps avg: 180, lows: 120, highs: 180
32 - Jitter is extremely sharp, but over quickly | fps avg: 180, lows: 100, highs: 180

stochastics · November 1, 2025, 3:28pm

So I’m at a bit of a loss, I actually enabled navigation and it seems like the jitter got significantly better? It’s barely perceptible at this point.

I would think that enabling occlusion, physics, and navigation would actually be worse for performance not better?