Problem with convex cast against compound collision

[fractile]

I'm working on a platformer type of game with level build as a compound collision (currently 20-50 boxes). I have been trying to switch my character controller to find the ground using convex cast instead of ray cast, but the cast returns unexpected contacts.

After days of debugging I finally got the problem narrowed down to compound collisions. Everything works as expected, when the level consists of only one box (created using NewtonCreateBox()). If a add another box (resulting in a compound collision for the level body) the convex cast starts returning contacts with normals pointing in opposite direction and contact points nowhere near the ground. The casted collision is a sphere (ellipsoid).

Ray casts work as expected with the exact same level geometry.

Any help will be appreciated as I'm running out of ideas..

[fractile]

I forgot to mention that i'm using Newton v2.18.

I noticed one interesting thing when comparing the convex cast results on one-box -level and two-boxes -level with the player at exact same spot standing on a box that is identical in both levels. While the normal and contact point are different, the "hitParam" value set by NewtonWorldConvexCast() is the same (and looks right).

[Julio Jerez]

I never tested convex cast with compound collisions I simple assumed it will work.

can you give me a test for debugging?

[fractile]

I quickly hacked up minimal code that seems to cause similar behavior. Hopefully I didn't make any stupid mistake in it. I really need to get some sleep now

[Julio Jerez]

This is the result with one Box.

contact 0 at 0.000000 -8.998047 0.000000, normal -0.000000 1.000000 -0.000000
param 0.610000

this is the result with the coumpound

contact 0 at 0.000000 -5.948047 0.000000, normal -0.000000 -1.000000 -0.000000
param 0.610000

I see teh look very wroung, I will debugg it.

[Julio Jerez]

Wow this is Huge bug,

Basically when I calculate compound contact for the Geometry point of View it does no matters if you are moving for A to B or for B to A,
but physically if does make a Big difference, since contacts will be on different location.

I wonder if this also happens when regular continue collision is on,
Anyway I will fix it and Make sure if no part of a larger problems.

It will take me a day or two to figure out I need to go over some function to see the base place to make the corrections without affecting the rest of the engine.

[Julio Jerez]

I fix it, these are the result now,

// compound collision
contact 0 at 0.000000 -9.001953 0.000000, normal -0.000000 -1.000000 -0.000000
param 0.610000

//with simple box
contact 0 at 0.000000 -8.998047 0.000000, normal -0.000000 1.000000 -0.000000
param 0.610000

The differences you see in position are the float error that creeps in when calculation is
from A to B or from B to A
the normal also point in different direction but this is because in one case the contact goes from ellipse to Box, and in the other goes from Box to ellipse.

Those are the error we must accept because calculation contact carry significant large float error,
since must of the calculation are volumetric and the lose lot of significant bit when done in floating point precision, in fact this is one of the biggest challenge of a collision system,
how to get accuracy with large number and small number at the same time using 32 bit floats.

wait about one hour and download the lastest version.

[fractile]

Thank you for the really quick fix. I checked the download page, but there's only windows SDK download link for the new version. I need 32-bit linux SDK too, since I'm doing my development mostly on linux.

[Julio Jerez]

Ok I will do it this saturday then.

[fractile]

I don't mean to rush, but what's the status of the linux SDK update?

[Julio Jerez]

Ok you can download 2.19 linux now

[fractile]

I downloaded the new SDK and the contact point problems are now gone on both windows and linux. There's still few things I don't quite understand with the normals though:

1. The m_normal -field in NewtonWorldConvexCastReturnInfo often returns reversed normals. I understood that this is caused by different contact directions as Julio explained in the previous reply:

the normal also point in different direction but this is because in one case the contact goes from ellipse to Box, and in the other goes from Box to ellipse.

So, how do I know which direction the contact goes? Eventually I need contact normals from the compound collision to the ellipse collision I use in convex cast, but I don't know when to reverse the returned normals.

2. The m_normalOnHitPoint -field mostly behaves as expected and I'm currently using this to detect player's ground contact. However, when the player walks over a box edge, this too momentarily returns normals pointing down, even though the contact point seems to be on top of the box. I'm assuming this too is caused by different contact directions.

[Julio Jerez]

It is diffcult to know how when to flip normals,
for collision normal direction are irrelevant,
But maybe in convex cast case I can use the input information to decide when to flip teh normal afte they are generated.
Is still have teh test you sent me, these are the results I am getting know

// using the Box
contact 0 at 0.000000 -8.998047 0.000000, normal -0.000000 1.000000 -0.000000

// using the compound
contact 0 at 0.000000 -9.001953 0.000000, normal -0.000000 -1.000000 -0.000000

so let me see what I can do about. I also wonder if these is the reason why some time teh player controller fail collision.


on this:

2. The m_normalOnHitPoint -field mostly behaves as expected and I'm currently using this to detect player's ground contact. However, when the player walks over a box edge, this too momentarily returns normals pointing down, even though the contact point seems to be on top of the box. I'm assuming this too is caused by different contact directions.

are you saying that the normals flips even if the player is walking on the same shape?
for example whne the player is over box face, the normal point away from the face, but when it hit the edge of teh same bot the normal point into the face?
That should not happens and it will be a very catatrofic bug if it did.

[fractile]

are you saying that the normals flips even if the player is walking on the same shape?
for example whne the player is over box face, the normal point away from the face, but when it hit the edge of teh same bot the normal point into the face?
That should not happens and it will be a very catatrofic bug if it did.

I'm not exactly sure. I attached a modified version of the previous sample code that shows my problem. Convex cast downwards towards the top face of box (in a compound collision) returns normal pointing up, but same cast just beyond the box edge returns normal pointing down.

[Julio Jerez]

First I will see if I can make teh casting with compound consistent with teh casting on oteh shapes.
Then I will try the secund test.