godot: The fact that `GridMap`s do not have collision until the frame after entering the tree is not documented

Godot version

v4.0.2.stable.official [7a0977ce2]

System information

Fedora 37

Issue description

The methods intersect_ray, intersect_point, and intersect_shape from PhysicsDirectSpaceState3D do not take GridMaps from the scene into consideration, and will not collide.

Steps to reproduce

  1. Try to check for a collision with a GridMap using one of the aforementioned methods.
  2. No collision is ever reported.

Minimal reproduction project

GridmapQueries.zip

GridmapQueries.zip

Edit for easier searching: RayCast, IntersectPoint, IntersectShape, IntersectRay

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 17 (10 by maintainers)

Most upvoted comments

At risk of duplicating my question in https://github.com/godotengine/godot/issues/77872, is there a way to know when a given node has become truly ready, i.e. has finished its entire full setup?

There is no standardized way for this – you may need to use await get_tree().process_frame for one or more frames in _ready(), depending on the node.

Specific nodes could emit a signal when truly ready (and/or call a dedicated virtual method), but this needs to be implemented on a per-node basis.

The issue with relying on “ready” as a notification is that it is just a notification that gets send after all the other notifactions like “enter tree” or “enter world” in the loop and it does not check anything.

If the node has a more complex or threaded first time setup it is not blocking the notification loop so “ready” is send even while technically the node has not finished its entire full setup.

Is it that process_frame’s first emission is related to whether a scene’s nodes (e.g. GridMap) are “truly ready”, or simply that awaiting it gives us a good chance of having waited long enough?

await get_tree().process_frame just means “wait 1 frame before running the code below this line”. It’s a way to delay code without blocking execution.

The issue with relying on “ready” as a notification is that … it does not check anything.

“ready” is send even while technically the node has not finished its entire full setup.

At risk of duplicating my question in #77872, is there a way to know when a given node has become truly ready, i.e. has finished its entire full setup?

I’d recommend in these cases to search for bug reports

That was, in fact, close to the first thing I did. Alas, I searched for is:issue is:open gridmap raycast and the like - you’ll notice that the first instance of the latter keyword in this issue is my first comment, so I wasn’t able to find it until now. Nor did I find anything using search engines except several unanswered questions on https://godotengine.org/qa/questions and the subreddit.

I searched the best I could with the symptoms I observed, and now that I’ve been directed here I’m not complaining, simply commenting to give this hypothetical “someone” further context on the open documentation issue, that being that a reasonable person acting in good faith can and has fallen into this snare. No need to snip.

You can not query the physics space in a _ready() function at game start. The PhysicsServer had not time to sync, same with Navigation or all kinds of other servers. The _ready() function of nodes is not the right place to do server queries at game start.

That is odd, because it does work in the ready function with StaticBody nodes, just not GridMaps. I have updated the MRP to demonstrate this.

This fact should probably be documented better, none of the method or property descriptions for direct_space_state or the methods mention it.