Extreme lag (FPS down to 1) when TileMap collision shapes are visible, when its parent is a RigidBody2D

[FoxyFox909]

Tested versions

• Reproducible in:
  • v4.3.dev2.official [3524346]
  • v4.3.dev1.official [9d1cbab]
  • v4.2.stable.official [46dc277]
  • v4.2.beta4.official [93cdacb]
  • v4.2.dev6.official [57a6813]
  • v4.2.dev5.official [e3e2528] Seems to be first occurrence.
• Not reproducible in:
  • v4.2.dev4.official [549fcce]
  • v4.2.dev2.official [da81ca6]
  • v4.2.dev1.official [0c2144d]
  • v4.1.3.stable.official [f06b6836a]
  • v4.1.2.stable.official [399c9dc]

System information

Godot v4.3.dev2 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 Ti (NVIDIA; 31.0.15.3619) - Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz (12 Threads)

Issue description

When a TileMap is made the child of a RigidBody2D, and that TileMap's TileSet has at least two different physics layers, and one tile is assigned a polygon for each of those physics layers, Godot will slow down to a crawl (FPS will become 1) as Physics Time begins to take 100+ ms.

Possibly related to #83354

2024-01-21.00-23-37.mp4

Steps to reproduce

MRP included at the bottom.

To reproduce with MRP:

• Run Project. Hold click and drag tiles or use the Add Row button to add some tiles at runtime.
• Use the Toggle Collision Visibility to toggle the Collision Shapes' visibility.
• Observe the FPS drop to 1, and run Profiler to see Physics Time rise up to 100+ ms. This happens for me at around 350 tiles added.

Detailed steps to reproduce from scratch:

• Create a RigidBody2D.
  • Optionally, set its can_sleep property to false. This issue appears to be closely related to the physics process. The issue will NOT occur when the RigidBody2D's sleeping or freeze are true, but will occur immediately after the RigidBody2D starts to be physics-processed again. Therefore, can_sleep could make it appear like the issue is not there.
  • collision_layer and collision_mask seem to not be relevant, and the issue will happen when they are either set or empty.
• Add a TileMap child to that RigidBody
• Add a TileSet to the TileMap with two physics layers.
  • collision_layer and collision_mask seem to not be relevant, and the issue will happen when they are either set or empty.
• Add an Atlas, and set up one tile to have a polygon for each physics layer
• Implement some way to add the aforementioned tile to the TileMap at runtime using set_cell.
• Make Collision Shapes visible
  • Either through Debug -> Visible Collision Shapes, or by changing the TIleMap's collision_visibility_mode property at runtime. Both have the same result.
• Run the current scene, and start adding tiles at runtime.
• At a certain point (for me it's at around the 350-tile mark), the issue will start happening, and FPS will drop to 1, and Physics Time will rise to 100+ ms in the profiler.
  • If using the TileMap's collision_visibility_mode, you can turn the Collision Shape visibility on and off at runtime. If the visibility is turned off, the FPS goes back to normal. If the Collision Shapes are made visible again, the issue quickly returns.

Minimal reproduction project (MRP)

visible_collision_shapes_lag_mrp.zip

[FoxyFox909]

I tried a variation to reproduce this issue, and was successful. I tried a hierarchy where the TileMap is NOT a child of the RigidBody2D, but is instead a sibling, and has its transform modified by a RemoteTransform2D as such:

The issue still occurs, as long as the RemoteTransform2D is trying to push at least ONE of either position, rotation, or scale from the RigidBody2D to the TIleMap.

[matheusmdx]

Bisecting points to #81070 as the culprit:

[akien-mga]

CC @groud

[groud]

So, I tried the MRP with latest master, I cannot reproduce the bug.

I suspected the culprit could maybe be due to the clear_layer(1) called in the TileMap node, as removing it seemed to improve the performance a bit. But even with this removed, I cannot find any other heavy processing in the MRP that could cause performance issue (the TileMap internal update is not ran, including the debug preview, which is not ran too)

So well, either the bug is fixed on master, either the MRP isn't good enough to show the issue.

[matheusmdx]

Tested with latest master [b7feebe] and indeed is not reproducible anymore, so was solved in master

[Calinou]

Closing per the above comment.