[4.0] StaticBody3D not detected into an Area

[kevinloustau]

Godot version

v4.0.alpha.custom_build [2aee84c]

System information

Windows 11

Issue description

Moving a StaticBody3D into an Area. I can't detect the body into the Area
It is working correctly using 3.4.2, but not on master at this date.

Steps to reproduce

• Move a StaticBody3D programmatically into an area
• print a message from the area signal "on_body_entered"

Minimal reproduction project

StaticBody and Area 4.0.zip
StaticBody and Area 3.4.2.zip

[lawnjelly]

This difference is likely to be the BVH code which is mostly responsible for area / static collisions, and is shared between 3.x and 4.0. The 4.0 version has intentionally got temporarily behind bug fixes in the 3.x version as we made some large changes / bug fixes and wanted to make sure these worked, but I will be porting this back to 4.0 very soon (this is mostly just a straight copy of files).

There's also a related longstanding bug with areas and statics (that pre-dates the BVH) that I will hopefully be fixing soon, but it doesn't seem to be the one in this issue.

[lawnjelly]

I've just tried this with #57630 and it doesn't show the message even with the updated BVH. I'll try and have a debug but I'm not sure of what other changes there may be between the two version in the physics.

Ok I've debugged this, with a special build that corrects for the area / static bug and allows this (just in case that was the problem). The BVH is sending the pairing callback correctly, but the physics is not acting on it to send a signal for some reason.

So I think this would need a physics guys to debug.

[rburing]

In the minimal reproduction project, the position.y -= delta * 2.0 code on the box can be moved from _process to _physics_process. With this change, still neither area detects the static body entering. However, when the constant 2.0 is replaced by something in the range between 41 and 128, only the first area detects the static body entering. When the constant 2.0 is replaced by something in the range between 164 and 251, only the second area detects the static body entering. I hope this can help to figure out what's going on here.

[rburing]

The current design of (the code of) Godot Physics is that unmoved areas do not collide with static bodies. In the minimal reproduction project, the internal GodotAreaPair3D object (pairing the area and the body) gets created and hence added as a constraint to the body and to the area, but the Godot Physics step GodotStep3D::step just ignores it: it only considers the constraints of moved areas and active bodies (and static bodies are never active), so no collision is detected. The reason the higher velocity caused the collision to be detected is that the areas are considered "moved" on the very first frame (and the velocity was such that the collision happened on the first frame).

In 3.x with Godot Physics the behavior is the same; no collision is detected after the first frame (though the AreaPairSW object gets created only after changing the tree_collision_mask to 3 in the BroadPhaseSW). In 3.x with Bullet Physics the collisions are detected (by design of the Bullet Physics server), which explains the discrepancy in the original report.

To address this issue either the design of Godot Physics should be changed (to somehow consider more areas for collision, with the restriction that it should still be efficient), or this caveat should be added to the documentation of every relevant method and signal.

[lawnjelly]

Ah 😀
I'm so dumb I think the reason this isn't working is by design.

The object you are moving is a static body. In physics the word static is used to refer to objects which should not move. If you are moving it, it is not meant to detect collisions. If you want to move an object and detect collisions, then it should be a kinematic body, a rigid body, or an area. This is probably the entire reason there is a static_body at all, to allow something that is optimized for not moving.

The current behaviour therefore makes total sense, and it maybe does do a collision detection on the first entry into the world.

The fact it works in bullet is likely because bullet has no distinction between static and dynamic objects (in a sense it works by accident, but it is not intended).

Yes even the documentation seems to mention this that it should not move. Maybe we need to make it clearer that if it does move, it is not intended to detect collision:
https://docs.godotengine.org/en/stable/classes/class_staticbody.html

So yes am in agreement with @rburing but assuming this is correct I think it just needs the docs making clearer, I don't think it should be changed.

If you want to move something like this but not have it controlled by physics, then it would seem that by definition it should be a kinematic body rather than static, afaik.

[lawnjelly]

I've marked this as a good first issue : modifying the docs to make clear that statics are intended to be non-moving, and are not guaranteed to detect collisions when moved.

[mohamedAdhamc]

I've marked this as a good first issue : modifying the docs to make clear that statics are intended to be non-moving, and are not guaranteed to detect collisions when moved.

Yes, I actually would like to do just that. Do I have to be assigned or can I just make a pull request?

[lawnjelly]

Yes, I actually would like to do just that. Do I have to be assigned or can I just make a pull request?

No need to be assigned, just make a PR. 👍

If it was a large PR sometimes it is worth making a note that you are working on it so multiple people don't duplicate work at the same time, but for small ones like this there is usually no need.

[mohamedAdhamc]

Yes, I actually would like to do just that. Do I have to be assigned or can I just make a pull request?

No need to be assigned, just make a PR. 👍

If it was a large PR sometimes it is worth making a note that you are working on it so multiple people don't duplicate work at the same time, but for small ones like this there is usually no need.

Hey excuse my ignorance but would you have an idea as to where in the documentation the description of staticbody3d is, because I cant seem to find it.

[Calinou]

The file you need to modify is doc/classes/StaticBody3D.xml in the master branch.

See Contributing to the class reference for more information.

[mohamedAdhamc]

The file you need to modify is doc/classes/StaticBody3D.xml in the master branch.

See Contributing to the class reference for more information.

thanks will work on it

[mohamedAdhamc]

done

[AttackButton]

@kevinloustau as I did comment in #58710 (comment), in godot 4.0, you need to use the AnimatableBody instead of the StaticBody when your intention is to move the object.

[TokisanGames]

I think the reason this isn't working is by design.

This is a bug, not a documentation issue. The behavior is different from Godot 3 (default engine, Bullet). I have static bodies that do not move. I have areas attached to kinematic bodies, and the areas do not detect when the static bodies enter them. It worked fine in Godot 3. Imagine a switch on a wall, and the player detects it has an interactable object in front of it. Currently only my kinematic bodies are detected. All of my pickup items (weapons, shields, potions) and interactable nodes are broken.

This issue isn't about StaticBody and whether it moves or not, it's about Area3D. The whole purpose of Area3Ds is to detect physics bodies without calculating collision. Area detection should work with all physics bodies if the Area is monitoring, the collisionshape is enabled, and the collision layer and layer mask line up.

Area3D Manual page - Nothing about static/kinematic/etc as that is irrelevant.

3D area that detects CollisionObject3D nodes overlapping, entering, or exiting. 

This issue should be renamed to "Area3D doesn't detect StaticBody3D".

---

Edit: It appears this issue is a duplicate, as the original is still open from 4 years ago. #17238.
It was confirmed then that it is definitely a bug 1, 2, not a documentation issue.

The Area has to be marked both Monitoring and Monitorable, which is contrary to the documentation. Then the Area3D will send signals when static bodies enter it.