Suggestions about collision response.

[yosoyfreeman]

Hi!

Regarding problematic collisions, there are, in my eyes, two clearly identified issues:

• Move and slide will always limit the movement along the cross product of the last wall and the new collided wall. The problem here is that there is no verification that the new plane is totally or nearly identical to the last one, so this cross product can go to zero and stop all motion when the velocity is projected on it (The fact that it assumes the walls are infinite is another issue i would like to focus in another moment).

This points us toward another issue: Ghost collisions. More often than not, we can collide with the same plane two times in a row even if it should not be possible.

Move and slide it's is own thing, so i will focus on the Godot jolt side of things.

The minimum depth threshold has for sure showed useful to alleviate issues, but has introduced the problem of missing collisions.

What i propose is another way of contact validation for _body_motion_collide. Instead of discarding contacts based on their depth, we can get rid of multiple issues by discarding contacts that matches the following rules:

• If the collision normal is parallel (regardless of the orientation) to the motion vector we know its not a valid contact plane, as you could continue the motion parallel to the plane infinitely without ever stopping. This would cause the body to not get stuck because a collision parallel to the movement and reduce the number of times the same plane can be processed two times in move and slide, triggering the stop_all_motion behaviour.

• If the collision plane points towards the motion vector it is not a valid plane, as you can not be stopped by something that is on your back while moving forward. This should allow the body to be released from the wall in the case you overlap slightly, because at the moment there is a velocity pointing outside the wall the wall would stop taking participation on the collision response.

Still with this changes move and slide needs improvements in which i'm trying to work on with mi limited resources, but they should improve the situation while making sure we don't discard any valid collision.

I was going to propose this changes earlier but i wanted to be sure. All the research i did fight this type of problems in this two ways. We can see something very similar here in the excellent Jolt CharacterVirtual:

https://github.com/jrouwe/JoltPhysics/blob/master/Jolt/Physics/Character/CharacterVirtual.cpp#L675-L681

// We don't want parallel or anti-parallel normals as that will cause our cross product below to become zero. Slack is approx 10 degrees.
float dot = other_normal.Dot(plane_normal);
if (dot < 0.984f && dot > -0.984f)
{
highest_penetration = penetration;
other_constraint = *c;
} 

https://github.com/jrouwe/JoltPhysics/blob/master/Jolt/Physics/Character/CharacterVirtual.cpp#L754-L771

// Flag contacts as having a collision if they're close enough but ignore contacts we're moving away from.
// Note that if we did MoveShape before we want to preserve any contacts that it marked as colliding
for (Contact &c : mActiveContacts)
if (!c.mWasDiscarded
	&& !c.mHadCollision
	&& c.mDistance < mCollisionTolerance
	&& (inSkipContactVelocityCheck || c.mSurfaceNormal.Dot(mLinearVelocity - c.mLinearVelocity) <= 1.0e-4f))
{
	if (ValidateContact(c) && !c.mIsSensorB)
		c.mHadCollision = true;
	else
		c.mWasDiscarded = true;
}

https://github.com/jrouwe/JoltPhysics/blob/master/Jolt/Physics/Character/CharacterVirtual.cpp#L177

&& inResult.mPenetrationAxis.Dot(mDisplacement) > 0.0f) // Ignore penetrations that we're moving away from

This would have the side effect of having to move towards a wall to get the information about it. But that is because move and slide mixes the collisions to which it should react with the collisions used to gather information about the environment, but that should be improved by it's own.

PseudoCode:

if hit.normal.dot(motion.normalized) >= 0 : //Discard planes on your back.
    continue

if is_zero_approx(motion.normalized.dot(hit.normal)): //Discard parallel planes.
    continue

PS: I seen that is a recurring pattern using the sweep test to collect information about static collisions in Godot, so may i ask, is there a specific method other than _body_motion_collide to gather collision data? Because it is not possible to satisfy the necessities of a movement check and a collision gathering check with the same rules, and may be one of the issues forcing this constant balancing between correct sliding and correct data gathering.

[mihe]

Thank you for the in-depth suggestions.

Again, I haven't really spent enough time reading up on or implementing character movers that I can speak to the validity of your suggestions, nor the parallels you draw to Jolt's CharacterVirtual, but on the face of it they make sense to me, and from some preliminary/basic testing they do seem to be a decent replacement for the current contact depth threshold hack.

You'll find the implementation in this branch.

It performs ever so slightly worse in the test scene provided in #529, but frankly it's close enough that it's hard to tell if it's just different rather than worse. When ripping out stop_all_motion from the Godot side of things it's close to flawless in terms of not getting stuck, much like the current hack, so I'm assuming it's just about improving things there.

It does fix the performance regression (#626) introduced by the current contact depth threshold, since there's no longer any need for move_and_slide to perform its apply_floor_snap due to being pushed too far away from the floor every single time. I believe this has caused other (unreported) ill effects as well, so this change alone might be reason enough to go with your suggestions.

I am however not seeing a huge difference in its ability to detect walls (#758), although there might be some improvement. I'm assuming this is what you're referring to when you say "having to move towards a wall to get the information about it". This phenomenon is present in Godot Physics as well to some degree, but is (from what I understand) supposed to be alleviated (in a somewhat odd way) by leaving the depenetration ever so slightly short.

I am also seeing a new discrepancy when comparing with Godot Physics, which is that the number of slide iterations actually go down from 2 to 1 when pushing up against a wall. I'll need to look into where that comes from to see whether it's a good or bad thing.

I seen that is a recurring pattern using the sweep test to collect information about static collisions in Godot, so may i ask, is there a specific method other than _body_motion_collide to gather collision data?

I'm not sure what you mean by sweep test in this context. There is no traditional sweep test in Godot, nor in Godot Jolt. Any shape-casting is done using a binary search, by stretching the shape by the cast distance along its support vector a number of times until you've found a spot where you didn't collide and a spot where you did collide, which are the "safe" and "unsafe" fractions. This binary search is (unfortunately) more or less required by any physics implementation in Godot due to needing to output these two fractions.

The only part of body_test_motion in Godot Jolt that uses this shape-casting is _body_motion_cast. The other two steps, meaning _body_motion_recover and _body_motion_collide, just use a regular collision query, much like Godot Physics.

[mihe]

That's awesome! I didn't knew that, it is documented? The only reference on the docs to performing statics checks is using the ShapeCast node, so knowing that motion test will behave accordingly if there is no motion to them would be great.

To clarify, I was referring to this yet-to-be-merged branch. As you can see there the discarding is only done if p_motion.length_squared() > 0, so passing in a motion of zero means nothing will be discarded.

I'm not sure what the ShapeCast3D node would provide you that the regular physics queries in PhysicsDirectSpaceState3D doesn't already. All that ShapeCast3D does is use the same cast_motion and get_rest_info methods that's available in PhysicsDirectSpaceState3D.

I hope my verbosity didn't bothered you

Not at all!

I can not be sure without seeing it, but if you are not applying gravity while moving against the wall, it is probable that the decrease in iterations is due to the floor being correctly ignored even if depenetrating the wall made you touch it or get inside it a little bit. If the body moves against a straight wall in a straight line, in theory all velocity should stop because the projection on the plane is zero, and that should take 1 iteration.

I haven't had time to look into this, but yes, I suspect you might be right about the depenetration causing some collision with the floor.

[yosoyfreeman]

I'm not sure what the ShapeCast3D node would provide you that the regular physics queries in PhysicsDirectSpaceState3D doesn't already. All that ShapeCast3D does is use the same cast_motion and get_rest_info methods that's available in PhysicsDirectSpaceState3D.

I believe there is a difference between what can you do with get_rest_info via gdscript and natively. In GDScript, get_rest_info provides only one collision point and normal and no more. This is also indicated on the documentation, "If there is more than one contact, the closest one will be selected". So i can not use get_rest_info to get all the contact points i have to resolve against in GDScript.

Checks the intersections of a shape, given through a PhysicsShapeQueryParameters3D object, against the space. If it collides with more than one shape, the nearest one is selected. The returned object is a dictionary containing the following fields:

If we take a look at PhysicsShapeQueryParameters3D, we can see that no max collisions parameter is accepted:

So, if i want to get all the contact points, i have to use either move_and_collide with zero motion or a shapecast with zero motion. Hope the problem is clear now.

I haven't had time to look into this, but yes, I suspect you might be right about the depenetration causing some collision with the floor.

Again, thank you so much! I'll be peeking here to see any updates in that regard.

Freeman.

[mihe]

I believe there is a difference between what can you do with get_rest_info via gdscript and natively. In GDScript, get_rest_info provides only one collision point and normal and no more. This is also indicated on the documentation, "If there is more than one contact, the closest one will be selected". So i can not use get_rest_info to get all the contact points i have to resolve against in GDScript.

There is no difference, as far as I'm aware. The way ShapeCast3D uses get_rest_info is by running it multiple times, and each time adding the RID of the body it hit to the exclude list of PhysicsShapeQueryParameters3D, until get_rest_info reports no more collisions, meaning an empty dictionary in the case of GDScript. So you might get multiple contact points from ShapeCast3D, but it'll only ever be one contact point per body.

The code itself is a pretty straight-forward read: https://github.com/godotengine/godot/blob/99ff024f78f65ba0bc54fb409cfeca43ba2008fe/scene/3d/physics/shape_cast_3d.cpp#L424-L433

It's a bit of an odd design, I must say.

[yosoyfreeman]

There is no difference, as far as I'm aware. The way ShapeCast3D uses get_rest_info is by running it multiple times, and each time adding the RID of the body it hit to the exclude list of PhysicsShapeQueryParameters3D, until get_rest_info reports no more collisions, meaning an empty dictionary in the case of GDScript. So you might get multiple contact points from ShapeCast3D, but it'll only ever be one contact point per body.

That is unfortunate and explains why i always got bad results using the ShapeCast node. You know if there is any reason for using rest info for ShapeCast instead of doing it similarly to body motion collide and being able to get all the contact points?

[mihe]

You know if there is any reason for using rest info for ShapeCast instead of doing it similarly to body motion collide and being able to get all the contact points?

Even if it's a scene node exposed by Godot itself it's still a scene node, so it's limited by the generic interface of PhysicsDirectSpaceState3D.

The better question is why the collision checks in PhysicsDirectSpaceState3D are designed/separated in the way they are, with get_rest_info, collide_shape and intersect_shape all providing different and incomplete parts of the collision check. I'm assuming it's for performance and/or legacy reasons.