Thread: gravity: jittery camera.

Iv'e added a gravity function to start off my physics engine, however it produces a result that nicely simulates an earthquake.

Code:

vector3d generic::gravity(vector3d pos, vector3d dir, vector3d v)
{	
	if(_ceCollision->checkcollision(pos)==false)
	{
		speed = sqrt(v.x*v.x + v.y*v.y + v.z*v.z);
		v.x += (((dir.x*(9.81))/233.3333333)-(glbAirRes*v.x*speed))*dt;
		v.y += (((dir.y*(9.81))/233.3333333)-(glbAirRes*v.y*speed))*dt;
		v.z += (((dir.z*(9.81))/233.3333333)-(glbAirRes*v.z*speed))*dt;
		
		pos = v;
	}
	else
	{
		speed = sqrt(v.x*v.x + v.y*v.y + v.z*v.z);
		v.x += (((dir.x*(9.81))/233.3333333)-(glbAirRes*v.x*speed))*dt;
		v.y += (((dir.y*(9.81))/233.3333333)-(glbAirRes*v.y*speed))*dt;
		v.z += (((dir.z*(9.81))/233.3333333)-(glbAirRes*v.z*speed))*dt;

		pos.x = -v.x;
		pos.y = -v.y;
		pos.z = -v.z;
	}
	
	return pos;
}

The jittering is caused by the code in bold I believe; that is, the pushing back of the position on a collision. The problem is, I don't know how to fix it.

thanx
-psychopath

I don't know . . . but a double has more presicion than this: 233.3333333.

What the hell are you trying to do in your code?

Well. Its quite clear to me now that I need a book on game physics more than I thought at first.
>>Don't push back after a collision, predict a collision before it happens.<<
&
>>you don't want to just push back, you want to push back by the pentration depth of the collision. That's not the same as negating v.<<
I'm not even going to ask you to explain how to do these things. I'm just gonna get a book .

>>I don't know . . . but a double has more presicion than this: 233.3333333.<<
233.3333333 is a number I came up with to keep things at a reasonable speed. Don't ask me how I got it. I can't remember.

Your code is very confusing. I see what you are trying to do (I've implemented the same thing before) but I'm willing to bet money there are bugs, on top of you not being familiar with the algorithm.

In general, it's best to test for a ray/plane intersection to predict the point of collision before penetrating the surface. Once you've got the general idea implemented you will have to work around floating point inaccuracies, else you'll fall through the world with code that appears to have been implemented correctly.

To give you a start, here is some code I wrote to determine if a point lies inside a triangle. It hasn't been rigourously tested yet. Basic idea on how to do this:

1_ Compute your start point and endpoint for the frame (where you currently are and where you'd like to go). I like to extrapolate the length of the move a little bit.

2_ For every item you wish to collide against (in this case a polygon soup of triangles) determine where the ray formed by the start point and end point intersects the current plane (if it doesn't, continue to the next polygon).

3_ Determine whether or not the plane intersection lies inside the current triangle. If the time that you collided with this polygon is less than the currently stored time of intersection, replace the time of intersection with the current one.

I left out a LOT of details.

Code:

//Fixme: investigate to see how vector length plays into uncertainty here
//Normal x DiffVector = InwardVector
//InwardVector Dot Point >= 0 or >= -.0001
BOOL	CCWPointInTri(float	P1X,float	P1Y,float	P1Z,
					  float	P2X,float	P2Y,float	P2Z,
					  float	P3X,float	P3Y,float	P3Z,
					  float	NormalX,float	NormalY,float	NormalZ,
					  float	PointX,float PointY,float	PointZ)
{
	Vector3	Point1(P1X,P1Y,P1Z);	Vector3	Point2(P2X,P2Y,P2Z);	Vector3	Point3(P3X,P3Y,P3Z);
	Vector3	Normal(NormalX,NormalY,NormalZ);
	Vector3 Point(PointX,PointY,PointZ);
	Point -= Point1;	//Translates to local coordinates

	Vector3	DiffVector	=	Point2 - Point1;
	Vector3	InwardVector(0,0,0);
	InwardVector	=	CrossProduct(&Normal,&DiffVector);

	if(DotProduct(&InwardVector,&Point)< -.0001)
		return	FALSE;

	DiffVector	=	Point3 - Point2;
	InwardVector	=	CrossProduct(&Normal,&DiffVector);
	if(DotProduct(&InwardVector,&Point)< -.0001)
		return	FALSE;

	DiffVector	=	Point1 - Point3;
	InwardVector	=	CrossProduct(&Normal,&DiffVector);
	if(DotProduct(&InwardVector,&Point)< -.0001)
		return	FALSE;

	return	TRUE;
}

Just to give you a very basic idea of how that code is supposed to work, here's a picture. The red lines are the unnormalied inward facing vectors (they need not be normalized). If a point that is on the same plane as the triangle is in front of each of these inward facing vectors (the dotproduct between the point and the inward facing vector is greater than 0) then the point in question is inside the triangle.

hmm, I think I get it...but probably not. Could something similar to this work?

Code:

vector3d nextpos;
vector3d currentpos;
vector3d nextpoint;
vector3d v = 0;

calculatevelocity(vector3d lastv, vector3d dir)
{
   speed = sqrt(lastv.x*lastv.x + lastv.y*v.y + lastv.z*v.z);
   v.x += (((dir.x*(9.81))/233.3333333)-(glbAirRes*v.x*speed))*dt;
   v.y += (((dir.y*(9.81))/233.3333333)-(glbAirRes*v.y*speed))*dt;
   v.z += (((dir.z*(9.81))/233.3333333)-(glbAirRes*v.z*speed))*dt;

   return v;
}

gravity(vector3d dir)
{
   v = calculatevelocity(v, dir);
   vector3d nextpos = currentpos+v;
   if(_ceCollision->check(nextpos))
   {
       nextpoint = _ceCollision->collisionpoint(nextpos, false);
       pos = nextpoint-v;
   }
   return pos;
}

-psychopath

Just to give you a very basic idea of how that code is supposed to work, here's a picture. The red lines are the unnormalied inward facing vectors (they need not be normalized). If a point that is on the same plane as the triangle is in front of each of these inward facing vectors (the dotproduct between the point and the inward facing vector is greater than 0) then the point in question is inside the triangle.

Just because the dot product works out does NOT mean the point in question is inside of the triangle. What it does mean is that you know which side of the triangle the point is on, but this does NOT mean the point lies in the same plane as the triangle.

The actual process of computing whether or not the point in question is inside of the triangle involves computing the barycentric coords of the point in relation to the triangle. What the dot product will tell you quickly is whether or not the point is colliding or will collide with the triangle - given the current velocity vector and position of the triangle in question. However, much more is needed to actually compute whether or not the point is inside of the triangle.

Sometime back I posted a huge thread which contained source code to compute the point of intersection between a ray and a triangle. Now even though you are not testing a ray and triangle there is a portion of the code which computes the barycentric position of the point at which the ray intersects the triangle. This code can be converted to discard the ray and simply compute whether or not the point lies inside of the triangle.

Perhaps I'm mistaken here, but more is needed than just the dot product.

And on a side note using any old floating point value to get the frames per second to work out is tying your program to one specific platform and one specific clock speed. This code would fail miserably on another machine with different clock speeds. Instead of using constants what you need to do is base all of your movements and physics off of time - in other words a computer running at 1GHz and one runnning at 3GHz would produce the same animation speed or the same simulation speed - to a certain point. The 3GHz computer will process the information more quickly, but the game will run just about identical on both machines. I'm talking about actual game mechanics and not just frame rates or rendering speeds. If a car moves 100ft in 1 second on super slow computer A then it had better do the same on super computer B and vice versa.

EDIT: I re-read your post, and it seems you don't even understand that the math involved in the code I posted produces vectors that point towards the middle of the triangle. I originally assumed you understood at least that much and your only complaint was that I glossed over the actual calculation of how the ray intersects the triangle plane (the easiest and most intuitive part of the algorithm)....maybe you are confused because there is no plane distance value? The reason for that is that everything becomes centered around the origin. I really just don't know where in the hell you are coming from.
/EDIT

Bubba you are 100% mistaken and it is because you are too quick to try to correct me without reading what I said. I admitted to leaving a lot out, but I specifically mentioned calculating where the ray intersects the triangle plane. My method works, I've used it before, and for triangle intersections nothing else is faster* (only uses vector multiplies, no trig or sqrting).

2_ For every item you wish to collide against (in this case a polygon soup of triangles) determine where the ray formed by the start point and end point intersects the current plane (if it doesn't, continue to the next polygon).

3_ Determine whether or not the plane intersection lies inside the current triangle.

The basic idea behind plane surfing:

You take the dotproduct between the start point and the end point with respect to the plane normal, minus the plane distance, store it in (startdist and enddist)**. If this is a polygon collision test, the start point must be in front (positive) and the end point must be behind (negative). If they both have the same sign (another place to write in numerical tolerances!) you can continue to the next polygon.

To get the intersection point, compute a value between 0 and 1 used as an interpolator. This is the ratio of the absolute values of abs(startdist) and (abs(startdist) + abs(enddist))...this is also the time variable I mentioned above.

Code:

float i_total_dist = 1/(fabs(startdist) + fabs(enddist)); //start should be positive but i throw in fabs just for uniformity here
float collision_frac = fabs(startdist) * i_total_dist; //for speed and ease of readability for me

Vector CollisionPoint = StartPoint + ((EndPoint - StartPoint) * collision_frac);

That is the basic idea of how to get the point where the ray intersects the triangle's plane. Then, you perform the test using the code I posted above to determine whether or not it actually resides inside the triangle. Iteratre through all of the polygons in the soup of possible collision hulls, storing the closest time of collision.

In a practical implementation you also need to throw in an epsilon, and check to make sure that the collision_frac is clamped between 0 and 1:

Code:

float i_total_dist = 1/(fabs(startdist) + fabs(enddist)); //start should be positive but i throw in fabs just for uniformity here
float collision_frac = (fabs(startdist) - EPSILON) * i_total_dist; //for speed and ease of readability for me

Vector CollisionPoint = StartPoint + ((EndPoint - StartPoint) * collision_frac);

.03125 (1/32) is a good epsilon
*this isn't entirely true, because you can precompute the inward facing plane normals: speed for an increased memory footprint...but it is still ultimately using the same method.

**If it's a sphere, then you do:
startdist = dotproduct(Plane.normal,StartPos) - PlaneDist - SphereRadius.

If it's a bounding box you find the vectors which go most against the plane normal:

Code:

		Vector3	VecEff;
		
		Vector3	maxs = mBSPColInfo.mfCurrMaxs;
		Vector3	mins = mBSPColInfo.mfCurrMins;

		if(plane->vNormal.x < 0)
			VecEff.x = maxs.x;
		else
			VecEff.x = mins.x;

		if(plane->vNormal.y < 0)
			VecEff.y = maxs.y;
		else	
			VecEff.y = mins.y;

		if(plane->vNormal.z < 0)
			VecEff.z = maxs.z;
		else
			VecEff.z = mins.z;
		
		//You can safely add offset, because the effective vector goes AGAINST the plane normal and will
		//subsequently always be negative
		float	offset = DotProduct(&plane->vNormal, &VecEff);
		
		float	sd	=	DotProduct(&plane->vNormal, &mBSPColInfo.BSPStart) - plane->d + offset;// b;
		float	ed	=	DotProduct(&plane->vNormal, &mBSPColInfo.BSPEnd) - plane->d + offset;// b;

hmm, so It would look like this?

Code:

   v = calculatevelocity(v, dir);
   vector3d nextpos = currentpos+v;
   if(_ceCollision->check(currentpos))
   {
       nextpoint = _ceCollision->collisionpoint(?, false);
       pos = nextpoint-2.0f;
   }

where I put the bolded ?, would that be the nextpos or currentpos? (function returns the collision point for the given argument)

-psychopath