Using NavigationObstacle with StaticBody produces a warning

[timothyqiu]

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.

The NavigationObstacle3D is intended for constantly moving bodies like CharacterBody3D or RigidDynamicBody3D as it creates only an RVO avoidance radius and does not follow scene geometry exactly.
Not constantly moving or complete static objects should be (re)baked to a NavigationMesh so agents can not only avoid them but also move along those objects outline at high detail.

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:

A static body is a simple body that can't be moved by external forces or contacts.

So I see no reason that it should not have a NavigationObstacle child.

Steps to reproduce

Add NavigationObstacle3D node as a child of StaticBody3D.

Minimal reproduction project

No response

[smix8]

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.

[timothyqiu]

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)

[sadovsf]

@timothyqiu I would say that for this use case there is AnimatableBody3D

[timothyqiu]

@sadovsf AnimatableBody3D inherits from StaticBody3D, so NavigationObstacle3D still produces a warning for it.

[sadovsf]

I dont see this being the case in beta3:

[timothyqiu]

@sadovsf Try putting the node as a direct child of AnimatableBody3D :)

[sadovsf]

@timothyqiu true, question is what is intended usage. But this type of collisions should be supported for sure

[smix8]

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.