Re: [Algorithms] Kinematic Collision

[Jeremiah Z. <jer...@vo...>]

I haven't worked in this area in a long time but I remember numerical
problems were a major problem (along with subtle and difficult to find
bugs). I had to make the character bounce away from the surface a small
amount or else the character would get stuck. And you have to be very
careful and explicit about the bounce away part:

	// Modify the velocity.
	{
		// Normalize the velocity and then project it into the
slide plane.
		float32 const original_magnitude =
vm_VectorNormalize(&velocity);
		if(original_magnitude == 0.0f)
		{
			velocity = Zero_vector;
		}
		
		float32 wall_part = velocity_slide_normal * velocity;
		{
			if(wall_part < 0.0f)
			{
				wall_part = fabsf(wall_part);
				velocity += velocity_slide_normal *
(wall_part + wall_epsilon);
			}
			
			// Fractional velocity in the slide plane due to
the projection.
			velocity *= original_magnitude;
			
			if(velocity_param > 0.0f)
			{
				// Tweak the amount of velocity.
				float32 const projected_magnitude =
vm_VectorNormalize(&velocity);
				if(projected_magnitude == 0.0f)
				{
					velocity = Zero_vector;
				}
				else
				{			
					// Scale the amount of velocity
between the original amount and the projected amount.
					velocity *= projected_magnitude
+ velocity_param * (original_magnitude - projected_magnitude);
				}
			} // end if
		}
	}

Notice how the velocity is normalized before the bounce away epsilon is
added and then scaled back up as opposed to projecting the full velocity
into the plane and adding a small amount to it.

Another problem is sliding up against a wall on a slanted surface. You
need to make sure the resulting velocity is parallel to the surface yet
still sliding against a wall. You can think of this as being constrained
to the direction of a line defined by the intersection of the ground and
wall surface planes. Corners are another problem because you'll get
jitter as you transition back and forth between walls. You need to know
that you are in a corner and are affectively constrained to a point (the
intersection of 3 planes).

One more thing, the swept-test should ignore collisions that are
occurring as you move away from a surface (velocity dot normal > 0) so
that if you are initially penetrating, you can move away from the
surface without getting stuck.

-----Original Message-----
From: Johan Gustafsson [mailto:spi...@gm...] 
Sent: Wednesday, September 02, 2009 1:02 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Kinematic Collision

How can you be sure that interpenetration never occurs then? Floating 
point errors seems to produce small but very relevant
problems for me. As an example, when simply dropping a capsule to the 
floor using the 'inner skin' method without bias the
solved position right before penetration should be 0.0 but the 
calculations will very often produce a number such as -2e-06,
so in my world creating 'a perfectly stable' solver doesn't exist.

Why is using a bias considered a 'hack', isn't it just to avoid this 
kind of problems?

I also run with a bounce of 0, meaning I never apply a position vector 
away from the contact, maybe its not legal to have it
zero?

The code is not very long and if some extremely helpful soul with a 
better math/physics background then me would give it
a look I'd be in heaven.

------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t