About move and collide and the safe margin.

[yosoyfreeman]

Hi! I have a question. Move and collide has the safe margin, which will depenetrate or move the body away from anything in that margin that is considered to be touching. I been using it to make checks with zero velocity as we talked in the other topic about collision suggestions, and increasing this value to allow near geometry to be counted as a collision.

However, what actually happens is that the body is moved away by the safe margin and then proceeds to gather the information. So increasing the safe margin makes gathering nearby collisions harder, not easier.

I understand this when recovery as collision is set to false, as you probably don't want those normals in that case. But the safe margin is technically part of the recovery process and in fact the parameters reads as such on the documentation:

If recovery_as_collision is true, any depenetration from the recovery phase is also reported as a collision; this is used e.g. by CharacterBody3D for improving floor detection during floor snapping.

So if you try to use it for such purpose as is my case, the safe margin actually prevents the body from gathering such collisions in first place.

This can be easily confirmed if you force the solver to under resolve with a 10% resolution only, you will se that now this contacts are reported.

After various months of work i almost finished my character and movement system from scratch, but i'm having troubles getting reliable information about all the collision normals. Unless we force the kinematic solver to underperform, which increases the risk of getting stuck, no information will be gatherer.

I think it makes sense to report this normals used to move the body to the initial position used by the safe margin as collisions if recovery as collisions is set to true, otherwise we will remain having issues by lost collisions (As it currently happens in godot move and slide too) due to numetical issues and the safe margin preventing the body to actually reaching the surfaces its meant to report.

I would love to know your opinion.

Freeman.

[mihe]

Apologies for taking so long to get to this. It's been a busy week.

I'm not entirely sure I understand the issue you're having, nor what you're suggesting should be changed.

Are you saying you want PhysicsServer3D.body_test_motion/RigidBody3D.test_motion/PhysicsBody3D.move_and_collide to return the collision data from the recovery step if there's no collision data from the final collision check, as is often the case when you have a zero motion vector and a high "recovery amount"?

[yosoyfreeman]

Hi! Don't worry!

Pretty much, yes. My reasoning is that is meant to report collisions previous to the movement itself, and this collisions fall under that category. Otherwise, you don't really have any control about what is really considered to be "touching" the body.

As the docs says, anything under the safe margin will be considered to be colliding and the body will be pushed away, however, if the collisions that pushed the body away are not reported, is easy to create a situation in which the body is pushed away by the safe margin but you don't still have no information about what pushed it. This makes really hard to achieve the goal of "Gather information about the things without moving against the things", which i think is something people in general have troubles with.

To be clear, this would not fix this issue on the controller itself, but it could be a good step on the right direction.

---

When i was writing the answer and some other suggestions, something clicked on my head. The safe margin is not being used at all. I made a video to show you. I used values as big as 1 and 2 meters to confirm and disabled "test only". The body is in fact not being moved away from the surface in first place. It only works on the direction of the movement.

2024-05-06.15-39-25.mp4

The same body, with movement to the right.

2024-05-06.15-43-15.mp4

As you can see, the safe margin is exclusively enforced in the direction of the movement, which is not what the docs says and as far as i know not what most people understand from it.

This explain lots of the issues i been experimenting with it. This is preventing the body to reach the surface by a margin only in the direction of the movement... Which is what we don't have after the movement and i been trying to do manually, but it is not correcting any other direction of the motion. This is the kind of margin that goes after a collision, to keep a safe margin from it, not before! It also perfectly explains why it has shown useless in order to unstuck the body.

I am now extremely curious to know if this was the intended behavior in first place... This works exactly the same in Godot physics, it is not because of Godot Jolt.

[mihe]

Pretty much, yes. My reasoning is that is meant to report collisions previous to the movement itself, and this collisions fall under that category. Otherwise, you don't really have any control about what is really considered to be "touching" the body.

As the docs says, anything under the safe margin will be considered to be colliding and the body will be pushed away, however, if the collisions that pushed the body away are not reported, is easy to create a situation in which the body is pushed away by the safe margin but you don't still have no information about what pushed it. This makes really hard to achieve the goal of "Gather information about the things without moving against the things", which i think is something people in general have troubles with.

The documentation is not quite accurate to the way it's actually implemented. It's not that the recovery itself is reported when using recovery_as_collision, it's that recovery_as_collision causes the final collision check to happen even if there was no hit by the shape-cast, as you should hopefully be able to see here. But at that point you may or may not have recovered to outside of the collision entirely (regardless of what recovery_as_collision is set to) as you point out. Whether this was the original intended behavior or not I can't say, but this is the way it works in both Godot Physics and Godot Jolt.

So the issue with your proposed change (assuming it's viable to begin with) is that the recovery never reports any collision data on its own, so that in itself would need to change, and then I guess you'd also need to decide what collision data to keep when you have a collision in both the recovery and the collision check. In any case, this strikes me as a scary change that I would prefer to see implemented in Godot itself first.

The safe margin is not being used at all. I made a video to show you. I used values as big as 1 and 2 meters to confirm and disabled "test only". The body is in fact not being moved away from the surface in first place. It only works on the direction of the movement.

This seems to work just fine for me, even with a zero motion vector.

(By the way, I would suggest not using a StaticBody3D for your character, since it doesn't have any velocity and therefore will not impart the proper collision response on bodies it collides with. You should use an AnimatableBody3D (or just a CharacterBody3D) instead, since those are actual kinematic bodies that have velocities.

[yosoyfreeman]

Thank you a lot for the context Mihe! I fully misunderstood the documentation, as you say is not really descriptive of what is really happening, so i thought we were already collecting that information and was a matter of exposing it. I see how it is a non trivial issue now.

I'm using a static bodies because is easier to work on prototypes and certain kind of test without all the built in features. This projects are not for production games but made specifically for developing solution for some of the problems that the character node presents.

regarding bigger changes on the Godot side:

A few days ago i made this post: Robustness and stability of physics interactions in Godot. A 4 years retrospective.

I tried to make a coherent explanation of some of the impediments we have right now. Emi told us the work for making the public hire offers should be done soon and the team seems to agree that narrowing the problem down from "Fix physics in godot" to something more approachable to start working on is a good idea. In those terms ClayJohn updated me on the situation and told me that they agree that focusing the next efforts in fixing the fundamentals of everything else for character movement is a good path. This translates to finally implementing a solid sweep test/ shape casting library. Reduzio did some work in that direction but is now abandoned Use exact sweep tests for CharacterBody

With the green light to look in that direction i been told to research and gather any possible valuable information i could find around. I found various alternatives that i want to look, but from a design perspective (And i could be totally wrong) i think it makes sense to use Jolt as reference here, as is meant to be official at some point and we don't really have a good basis in first place.

I want to study more before wasting your or rouwe's time with questions, but i would like to know if you have an idea of where to look. I know Jolt does has proper sweep testing / casting, but i couldn't wrap my head around about how all it works. (I been looking at castshape.h and the different cast methods, but when is used by character virtual none of this methods is called, so i think there is some kind of method which decides which kind of test to do based on the shape).

If you have any idea or opinion about how complex or good / bad of an idea is to try and use jolt as a reference here is.

Please, don't feel pressure. You are more the only person actively working on Godot AND Jolt, so your opinion and feedback would be good to have!

Have a great day!