[Adonthell-devel] Re: Precision issue? Getting closer ...

[Kai Sterker]

On Sun, Oct 5, 2008 at 6:22 PM, Kai Sterker <address@hidden> wrote:

I do believe that I have found the issue with the collision stuff. In
debugging deeper, I got the following:

(gdb) print planeIntersectionPoint
$15 = {
  X = 9.25, Y = 16, Z = 0
}
i(gdb) print eTriangle
$36 = {
  A = {
    X = 9, Y = 11.1999998, Z = 0
  },
  B = {
    X = 12,Y = 16, Z = 0
  },
  C = {
    X = 9, Y = 16, Z = 0
  }

The two objects represent the character position and one of the
triangles the tile we're on is composed of. If you look at it, you'll
find the character rests exactly on the edge (B,C).

In running through the collision code with that numbers, all it
produced was a collision against point A at t = 0.25 when instead it
should detect a collision at t = 0. The question that remains is when
it should have detected the collision. Either when we check against
the triangle face or at least when we check against the triangle
edges.

Instead of assuming A.Y = 11.2 (as it should be) and doing the math
myself, I got a bit lazy and changed the final line in
triangle::contains from

    return (u > 0.0f) && (v > 0.0f) && (u + v < 1.0f);

to

    return (u >= 0.0f) && (v >= 0.0f) && (u + v <= 1.0f);

That already stopped the character from falling through the ground.
(My assumption would be that the equals case means that we're not
inside the triangle but on the edge, as is the case here.

What I probably should do is at least run the same test with the
working version and see which collision test really fires here as that
would indicate where the real error is located.
But I thought I'd share the good news before I go on (also because I
am not sure how far I'll get today.)

Cheers,

Kai


> While debugging worldtest some more, I came across the following:
>
> Breakpoint 1, world::moving::update_position (this=0x371ce0) at
> ../../../adonthell/src/world/moving.cc:247
> 247         vector3<float> finalPosition = execute_move
> (&collisionData);
> (gdb) print eRadius
> $1 = {
>  X = 20,
>  Y = 12.5,
>  Z = 40
> }
> Current language:  auto; currently c++
> (gdb) print eSpacePosition
> $2 = {
>  X = 9,
>  Y = 12.8000002,
>  Z = 1.125
> }
>
> Instead of of being 12.8, eSpacePosition end up being 12.8 and a wee
> bit more. While this doesn't seem like a big thing, it could corrupt
> the character location in the long run.
>
> Another thing, after adding some more debugging output to see
> character location, the tiles being checked for collision and the
> point where collisions occur, the following was the result:
>
> // first iteration: no collision as character is not moving
>    pos [185.000, 200.000, 40.000]
>   area [165, 188, 0] - [205, 213, 80]
>  shape [120, 140, -5] - [180, 200, 0]
>  shape [180, 140, -5] - [240, 200, 0]
>  shape [120, 200, -5] - [180, 260, 0]
>  shape [180, 200, -5] - [240, 260, 0]
> // second iteration: gravity
>    pos [185.000, 200.000, 40.000] <-- center of the character sprite
>   area [165, 188, 0] - [205, 213, 80] <-- area checked for collision
>  shape [120, 140, -5] - [180, 200, 0] <-- 1st tile
>    col [180.000, 200.000, 0.000] dist 0.03175
>    col [180.000, 200.000, 0.000] dist 0.03175
>  shape [180, 140, -5] - [240, 200, 0] <-- 2nd tile
>  shape [120, 200, -5] - [180, 260, 0] <-- 3rd tile
>  shape [180, 200, -5] - [240, 260, 0] <-- 4th tile
>    col [181.404, 201.404, 0.000] dist 0.02273
>    col [181.404, 201.404, 0.000] dist 0.02273
>    col [184.167, 200.000, -0.347] dist 0.00955 <-- closest collision
> on 4th tile
>
> What I had expected would be a collision at [185, 200, 0] with
> distance 0 as that is the point the character rests on. It would be
> interesting to see the same figures for the working alpha-2 code for
> comparison, so here they are:
>
>    pos [25.000, 0.500, 40.000]
>   area [165, 188, 0] - [245, 253, 80]
>  shape [180, 140, -5] - [240, 200, 0]
>  shape [120, 140, -5] - [180, 200, 0]
>  shape [180, 200, -5] - [240, 260, 0]
>  shape [120, 200, -5] - [180, 260, 0]
>  shape [180, 140, -5] - [240, 200, 0]
>  shape [180, 200, -5] - [240, 260, 0]
>    pos [25.000, 0.500, 40.000]
>   area [165, 188, 0] - [245, 253, 80]
>  shape [180, 140, -5] - [240, 200, 0]
>    col [25.000, 0.000, 0.000] dist 0.00080
>    col [25.000, 0.000, 0.000] dist 0.00080
>  shape [120, 140, -5] - [180, 200, 0]
>  shape [180, 200, -5] - [240, 260, 0]
>    col [25.000, 0.500, 0.000] dist -0.00000 <-- center of character
> resting on ground
>  shape [120, 200, -5] - [180, 260, 0]
>  shape [180, 140, -5] - [240, 200, 0]
>  shape [180, 200, -5] - [240, 260, 0]
>
> While they are not completely comparable (relative vs. absolute
> values), you'll see at least the the collision(s) occur where they are
> expected. Directly at the center of the character with a distance of
> 0.
>
> Makes one wonder if it is just a precision issue after all. I'll keep
> on debugging.
>
> Kai
>
>
> P.S.: Attached is a patch to get the output above with the current CVS
> code, in case that helps.
>