# Flaw in collider?

Hello

I was reading through collider.ts and some odd things crossed to my mind.
As described in the Fauerby’s paper, the collision detection is happening on ellipsoid space.
In the code there are some scalars that represents distances, such as _nearestDistance and _nearestDistanceSquared.
These distances are calculated in ellipsoid space, and as far as I can see, the ellipsoid shape of collider is not taken account when calculating these distances.

Now what is a distance? Distance is a scalar that measure how far apart two object are from each other. In normal situation, distance of one meter tells that two object are one meter apart from each other.

Now think the same in ellipsoid space. If you are in ellipsoid space created from ellipsoid of 1 unit wide and two units as height then travelling two meters horizontally, is same as travelling one meter vertically.

If you have measured a vertical distance, you can not compare it with a distance that has been measured horizontally. But as far as I can see, that is what collider code in babylonjs is doing, its comparing all kinds of distances measured in ellipsoid space without correction to non ellipsoid space.

Same flaw is with epsilon used on collision response on line Babylon.js/collider.ts at master · BabylonJS/Babylon.js · GitHub
because _slidePlaneNormal is on ellipsoid space, the epsilon should be vector created with someting like:

const epsilon=0.001;
const epsilonVector=new Vector3();

With current scalar epsilon, the collision response wont be stable, the distance between collided object varies as _displacementVector is not length of epsilon in non ellipsoid space.

Would love to get @Cedric’s thoughts

I think it only uses spheres, could be wrong

Yes, at the end of calculation, it only uses sphere.
If an ellipsoid is 2 unit high and 0.5 unit wide, then the world is scaled to (1./0.5,1/2,1/0.5) and collision is done with a sphere of unit 1.

Yes, and in that scaled world, epsilon of 0.01 would be vector of { x: 0.01/0.5, y: 0.01/2, z: 0.01/0.5 }, not a single scalar like now.

So the this._epsilon variable should be dynamically calculated to be correct? Out of curiously, what would be an example game scenario that would be affected?

Hmm. If i understand correctly, the worldspace would have to be dynamic to cause problems then right? something like a growing black hole adding gravity each frame or maybe a space shooter approaching a planet, idk lol. What i really mean is, even if the math is wrong, but consistent , thats pretty much ok for games usually. This just made me think though, wouldnt varying rates of acceleration and deceleration have the same effect?

If so, that seems more plausible to manifest in gameplay. For instance, calculating a different contact point of a car’s bumper when colliding with a non 90 degree wall depending on how much the player is using the car’s breaks.

No, the distance between green wall and ellipsoid has shrink because of transform from normal world into a ellipsoid world. In order to transform the ellipsoid into a sphere, the transformation will need to modify only the Y-axis. Because the transform modifies only the Y-axis, the distance between red wall and ellipsoid does not change at all as that distance is on horizontal axis.

I accidentally deleted the post with explanation.
Here is the screenshot from deleted post

The collision response is iterative and the number of iteration is a parameter Mesh | Babylon.js Documentation
so, it doesn’t really matter which triangle will colide first, a number of iteration will limit penetration.
The more complex the scene, it might be needed to increase that number.

It’s also a big part of the resolution. It can’t find a perfect solution with 1 try.

1 Like

I found another flaw and this is very easy to demonstrate in playground.

As described in Faursby paper, the sliding distance is calculated by using angle of intersection

The angle is calculated on ellipsoid space, so it is not reflecting the real angle in non-ellipsoid space.

Here is a playground with slope and ellipsoid collider that is a sphere in “normal world”, having ellipsoid vector of {1,1,1}

This is a same scene with ellipsoid vector {0.1,1,0.1}

when you move on the sliding plane, you can notice that on first playground the player is sliding down from gravity pull when you are moving the player. On second playground, player is not sliding at all, it has very good grip on the ground.

In the playground try to change the ellipsoid height on line 40 and see how it is affecting how camera is sliding down.

Imagine a racing game where one player has a car that is one meter tall and another player that has car 2 meter tall. The shorter car is sliding down hills much faster than taller car, which does not make any sense. Also for game developer it would be very difficult to set speed and acceleration for cars in different shapes so that in game the speed and acceleration is what the developer wanted.

To make things correct, the angle of intersection and sliding distance should not be calculated in ellipsoid space, or ellipsoid ratio should be taken account when doing calculations.

1 Like

I would be interested to see a PR about it because that code runs since forever (I created for the engine I wrote BEFORE babylon :))

Here is some videos recorded from the playground I provided on last post.

In this video collider ellipsoid is {1,5,1}. Camera is moved with left and right arrow buttons horizontally on the slope. You can see that it does not slide downhill nearly at all.

This is very same playground, but ellipsoid is set to {1,1,1}. Moving horizontally is almost impossible because gravity pulls the camera downhill and finally it will fall from the plane.

To put those colliders in a real world usage, imagine the collider in first video being a motorcycle (ratio {1,5,1} means its five times taller than wide)
and the collider in the second video being a car, as tall as wide.
The motorcycle could drive on that slope easily but the car would fall off.

1 Like

that makes total sense! wanna do a PR?

I would if I had a working solution, but does not have one yet.
The problem is most likely in this line:

Great explanation, thank you! It’s exceptional you were able to find and articulate the problem so well

cc @Cedric to see if he has a few cycles to check

I’ll see what I can do in the coming weeks.

2 Likes