Physics, and how it applies to vehicles
Posted: 2008-08-14, 05:19
So, after going through the physics implementation for a little bit, there are a few questions I had, and things I wanted to discuss. I noticed a few assumptions you made; most seem benign, like assuming the wind resistance, constant acceleration from gravity, etc. However, there were a few that would need to be addressed for vehicles.
First off, friction. The friction is model is fairly simple, which is perfectly fine for human movement. You define it,
Then implement it,
AirFriction, or air resistance isn't really a big deal, even for aircraft unless you writing a simulation. No big deal there, but ground friction for vehicles is a big deal. Most importantly, it varies greatly with the characteristics of the two materials (Coefficient of Friction). A check could be done here to the contacting brush below. For instance, roads could be attached to entities having a flag for road, or dirt, etc. Anything else (so the entire map doesn't need to be flagged) could be assumed to be dirt (or any defined material, preferably by the map, not hardcoded). Secondly, friction depends greatly on the mass of the object. This is easily dealt with by a new variable in the vehicle's entity. Friction is also dependant on a number of other factors, but these are more or less negligable to mass (normal force), and the coeffecient of friction between the two surfaces. I suppose one could also take rolling friction into consideration also, not sure how that would compare with kinetic friction though.
Next, a random bit of code I didn't quite understand.
Wasn't really sure whats going on here.
Probably my biggest question is this. It seems as though when the player makes a movement command, he is really setting the WishVelocity, saying I want to move in this direction at this speed. Which is fine for humans, but for vehicles it's a little backwards. Vehicles think more along the lines of, I want to apply this much torque, or this large of an impulse. Code wise, is there a way to change this? The only way I can see right now would be something like this;
If a player is in a vehicle, he has a flag saying so.
If the flag is up, ApplyAcceleration() catches it, and rather then using predetermined values, calculates what the acceleration *should* be. It then simply applies this acceleration to the current velocity (after accounting for air resistance, friction, etc) , ignoring WishVelocity.
Which brings up another question.
This seems to be creating a sort of asymptote towards terminal velocity at 500. (note: 500 what? I saw earlier gravitation acceleration being 9810.0, so 500 is 0.5 meters per second?) This would certainly need to be removed (at least in the XY plane) for aircraft. Seems a little low for terminal velocity also. To fully solve this equation we would need to consider a few things. First, the mass. easy. Second the projected surface area of the falling object. This could be easy. Seeing as all the objects already have a bounding box, we might be able to quickly calculate the surface area. Coefficient of drag. This depends on so many things, its not even worth trying to find. Easiest just to set it to one. Lastly density of the fluid (air). Technically, this varies with altitude, but unless someone is making a high altitude sky diving simulation, I think we could safely assume this to be constant. Its about 1.2.
So, we started with this equation;
v = sqrt(2mg / ?AC) (latex would be nice on these boards
now we have this:
v = sqrt(19.6m/ 1.2A)
substitute in the above code:
Note I created a new function in the entity to calculate the XY plane area of the bounding box:
Really not sure if that will work or not, but it shows finding a *rough* projected area isn't terribly difficult.
However, it could also be used to implement a simplified drag equation, Fd = 0.5 ? v^2 Cd A, again assuming Cd to be 1 and ? (density of air) to be 1.
Well I think thats quite a bit of rambling for one night. More or less just some thoughts on how to make the physics model more inclusive without over complicating things. I'm going to do a little bit more thinking, and post my ideas on steering. Scratch that, a lot more thinking, thats a tough subject
First off, friction. The friction is model is fairly simple, which is perfectly fine for human movement. You define it,
Code: Select all
const double GroundFriction=4.0;
const double AirFriction =0.2;
Code: Select all
switch (PosCat)
{
case InAir : Drop=CurrentSpeed*AirFriction*FrameTime; // This is a very rough approximation.
break; // We might need a new models for deceleration due to air resistance (aircraft)
case OnSolid: double Control=CurrentSpeed<StopSpeed ? StopSpeed : CurrentSpeed;
Drop =Control*GroundFriction*FrameTime; // Again, a rough approximation.
// Friction increase with velocity, also depends on both surfaces. need new model
// To do: if the leading edge of the BB is over a dropoff, increase friction
break;
}
Next, a random bit of code I didn't quite understand.
Code: Select all
// Permittivity of free space? Not really.. If the WishSpeed is that small, why not just set it to 0?
if (WishSpeed>0.001 /*Epsilon*/) WishDir=scale(WishVelocity, 1.0/WishSpeed);
Probably my biggest question is this. It seems as though when the player makes a movement command, he is really setting the WishVelocity, saying I want to move in this direction at this speed. Which is fine for humans, but for vehicles it's a little backwards. Vehicles think more along the lines of, I want to apply this much torque, or this large of an impulse. Code wise, is there a way to change this? The only way I can see right now would be something like this;
If a player is in a vehicle, he has a flag saying so.
If the flag is up, ApplyAcceleration() catches it, and rather then using predetermined values, calculates what the acceleration *should* be. It then simply applies this acceleration to the current velocity (after accounting for air resistance, friction, etc) , ignoring WishVelocity.
Which brings up another question.
Code: Select all
switch (PosCat)
{
case InAir : // airborn, so little effect on velocity - Will change for aircraft
Acceleration=AirAcceleration;
AddSpeed=WishSpeed>500.0 ? 500.0-CurrentSpeed : WishSpeed-CurrentSpeed;
So, we started with this equation;
v = sqrt(2mg / ?AC) (latex would be nice on these boards
now we have this:
v = sqrt(19.6m/ 1.2A)
substitute in the above code:
Code: Select all
TerminalSpeed = sqrt( (19.6 * GameWorld->GetBaseEntityByID(EntityId).Mass) / (1.2 * GameWorld->GetBaseEntityByID(EntityId).GetXYArea() ) )
AddSpeed = WishSpeed > TerminalSpeed ? TerminalSpeed - CurrentSpeed : WishSpeed-CurrentSpeed;
Code: Select all
Vector3T<float> *Corners[8];
Vector3T<float> *Plane[4];
Vector3T<float> *a, *b;
float ret;
State.Dimensions.GetCornerVertices(Corners); // Not Sure how these will be ordered.
Plane[0] = Corners[0]; // Start us off
for (int i = 1; i < 8; i++;) { // We will find the 4 lowest corners
for (int j = 0; j < 4; j++;) if (Corners[i].z < Plane[j]) Plane[j] = Corners[i];
}
a = Plane[0]; // Use this corner as a starting points
for (int h = 1; h < 4; h++) {
if (Plane[i].x != a.x && Plane[i].y != a.y) b = Plane[i]; // this should give us two opposite corners
ret = abs(a.x - b.x) * abs(a.y - b.y);
return ret;
However, it could also be used to implement a simplified drag equation, Fd = 0.5 ? v^2 Cd A, again assuming Cd to be 1 and ? (density of air) to be 1.
Well I think thats quite a bit of rambling for one night. More or less just some thoughts on how to make the physics model more inclusive without over complicating things. I'm going to do a little bit more thinking, and post my ideas on steering. Scratch that, a lot more thinking, thats a tough subject