So how exactly would I go about writing this. I need to figure out where the horizon is relative to the screen position I guess? So I first need to calculate the position of the horizon and then transform that to screen space (I know how to do that second part). Any idea how to do the first?
The artificial horizon is just a matter of finding the "forward" and "up" vectors of your jet. You grok this from it's orientation matrix/quaternion. Then you just draw the correct rung of the ladder to the center of the screen/hud/whatever. So as an example, you find your forward vector is actually pointed straight along the Y axis (assuming Y is UP!), you would just draw the "+90" rung in the middle.
Then, for the flight path marker, just take your velocity vector and normalize it, then basically plot this against your artificial horizon.
Some HUDs I have seen do funny things with offsetting the artificial horizon with respect to yaw and side slip, so beware of that if you are going to a very realistic effect.
So if I understand you correct, I should not add a collision force/impulse to keep the car from the ground. Rather, I should just compress the spring. Next, this will result in the two masses connected to the spring each getting a force directed from each other, which should be equal in magnitude.
Strictly speaking "you" don't do anything explicitly in your code to compress the spring. The motion of the bodies should do this automagically.
Hmm, or perhaps not? The spring can store potential energy (like gravity) so it doesn't completely obey newton's third law. At least on some level of abstraction, if I understand it correct.
You should be worrying about "the equal and opposite" on a per joint basis. IE: Wheel pushes on spring with 10N. Spring pushes on wheel with 10N. Will you get 10N out the other side of the spring? Probably, but not always. What happens if you want to model your spring as having some mass?
You might want to look into the basics of drawing "free-body-diagrams". This might help you understand how forces interact between components.
The wheel will get the most acceleration because it is the lightest of the two bodies, so it will probably collide again. I suspect this will result in jittery motion. Maybe I should do the same calculations several times each frame to reduce this?
This is true of about any spring simulation. Doubly true where you have a maintained collision (resting contact). I would suggest using RK4 integration with a suitably small timestep, and using a damper (shock absorber to us 'mericans) along with your spring. Maybe someone can come along and make suggestions on how to make the collision response more robust.
With the springs having only one freedom of movement, the spring length will in some cases have to become infinitely long to get out of the ground. That is when the car is colliding with a surface perpendicular to the spring axis. What is the best way to deal with this? I am thinking in the lines of having an angular spring as well.
Springs don't work perpendicularly. You need another constraint to handle this. IE: Model a linkage that actually holds your wheel to the car, and then let the spring just worry about springynes. So when your wheel runs into this perpendicular surface, then load goes into this new constraint (and then into the body of the car, probably stopping it abruptly). The spring likely never deflects.
When compressing the spring, this will add energy to it. And since this energy is not based on the mechanical energy of the car, isn't there a danger for unstable and somewhat random motions? Proposed solution: Take the desired absorbed energy of the car, and use the spring constant to calculate the distance based on this energy. Artificially move rest of the car out of the collision area.
You put energy into your car to move it in the first place. Or it had some, as a byproduct of elevation. The spring is just storing some of this temporarily, and will give it back (minus any absorbed by the dampers) to the car body when it extends to original length.
In my opinion you are trying to over think this a bit. Model your components so that they behave individually. Now model constraints to glue them together. The details should sus themselves out.
Friction is a force, so it should not be acting on velocity directly as you have it. (vel /= 1 + f * dt;)? And I don't know what the /= is supposed to accomplish.
Don't check your value against *exactly* zero, rather...
if( abs(Velocity) > 0 )
frictionForce = -Velocity.unit * someScalarValue;
This says, "if my speed (velocity implies direction) is bigger than nothing, then lets add friction"
-Velocity.unit: "Friction will act in the opposite direction of my velocity, to slow us down" (Unit implies a vector of length 1.0)
someScalarValue "Friction is effected by things like materials, temperature, etc"
Sum the value of this friction force along with any other forces. Now multiply this sum by InvertedMass.
Now apply that acceleration to your velocity.
This implementation may still weeble wobble back and forth around zero speed, depending on integrator behavior.
It appears you want to do a (fairly) simple simulation of your car accelerating. This is not too difficult. Things get difficult if you want to add turning and such.
In a summary type fashion, here is what you need to do.
1) Determine forces acting on the car. 2) Integrate the forces to the momentum of the car. 3) Solve for the velocity of the car by taking momentum * invMassOfTheCar 4) Integrate velocity into the position of the car. 5) Display your car. 6) Feed your current speed back into the system. You will use speed*tiresize*gears (roughly) to find engine RPM. This lets you find torque driving the car. This lets you solve for the values you need in step 1. Repeat as necessary.
I suggest you look into the articles on: GafferOnGames This covers the basics of integration and timestep fixation you will need. This is also a good introduction to simulating car physics: MarcoMonster Car Physics