-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using NavigationObstacle with StaticBody produces a warning #66932
Comments
Because you should bake static geometry to the navmesh for both pathfinding quality and performance. Just because Godot allows you to move a StaticBody node around every frame (static only in name) like a KinematicBody or RigidBody node does not make the use with an avoidance obstacle less wrong. The warning was added because people would add obstacles to all their static collision geometry in the level and then complain about the horrendously bad path movement as a result. Reminder that obstacles do not change the resulting path from the pathfinding, they only affect the actual actor movement in a radius. Basically if you use obstacles for the walls in your level that wall does not exist in the pathfinding, it will only push the actor in a semi-random direction away while moving inside that radius and if multiple obstacles overlap the result is unpredictable, e.g. might get pushed in collision or off the navmesh. If you want an actor to move around e.g. corners in your level geometry in detail using obstacles is the worst option you can pick. |
I understand that the obstacles don't affect pathfinding. The point of this issue is that static bodies are not always for building static geometry. There're valid use cases for using static bodies as ... obstacles. e.g. obstacles in an obstacle course that move back and forth. This kind of physical objects can push the characters but can't be affected by other objects (e.g. stopped/slowed by the player), which makes it perfect for static bodies. And AI characters are supposed to avoid them. In this gif, the pink blocks can be static bodies: For why static bodies can move, see godotengine/godot-proposals#2184 (comment) |
@timothyqiu I would say that for this use case there is |
@sadovsf |
@sadovsf Try putting the node as a direct child of |
@timothyqiu true, question is what is intended usage. But this type of collisions should be supported for sure |
Changing obstacles from Node to Node2D/Node3D should be done. Would not break anything and remove the need for a warning (with the rvo rework in mind) and make the obstacle node use more flexible. Could still keep the old functionality or be attached as a child node but not as a hard requirement for usage. There is no real technical reason to have NavigationObstacle nodes depend on a parent node compared to the NavigationAgent nodes. I think this was only done back in the day cause the obstacle started out as a cheap / shallow copy of the NavigationAgent node and it was never questioned enough if it would make sense. |
Godot version
4.0.beta2 / 3.5.1.stable
System information
Arch Linux
Issue description
A
NavigationObstacle
node will produce a warning if its parent is a static body.But static bodies can be constantly moving too, they are just not movable by others. This is documented in 4.0 classref, but also applies to 3.x:
So I see no reason that it should not have a NavigationObstacle child.
Steps to reproduce
Add
NavigationObstacle3D
node as a child ofStaticBody3D
.Minimal reproduction project
No response
The text was updated successfully, but these errors were encountered: