Vector math for anti-grav with direction
by Chris Cain · in Torque Game Engine · 01/06/2009 (11:51 am) · 23 replies
I sure hope I don't fudge up with the explanation of my problem...
First of all, I'd like to say that I think this would probably be better placed in the Mathematics section, but I put it here in case I need to post C++ source to diagnose problems.
Alright, I'm making a booster that resists gravity, then propels a player into the direction they are pointing. The catch is that there is a maximum force that the booster can propel, and it won't exceed that force... so I'm trying to figure out how to do this.
I wouldn't mind being pointed in the right direction instead of having my hand held ;) ... just keep in mind, I don't have a great grasp on vectors just yet.
So, here's a couple of images to help illustrate what I'm trying to do (and how I've pictured it in my head on how I might be able to solve it.)
In this picture, gravity is defined as -20, the force the booster can output is 90. The vector marked as "x" is the direction that the player is facing. I figured I could just use vector projection at this point...
But...
This is an image that shows when a player aims a bit up. Vector projection wouldn't provide the correct vector then. Also, this vector is overall shorter compared to the other one (which makes sense, if you're pointing up, it should provide less net-acceleration because you're fighting gravity). So, I figured if I found out the x and z values necessary, then that'd work. But, that wouldn't translate very well into 3d. So in the end, I really just need an algorithm to figure out the scale needed for a vector... then all I'd need to do is take the eye vector from the player and scale it appropriately.
I'm coding all of this into updateMove, just for your information.
Thanks for any help you can give me.
First of all, I'd like to say that I think this would probably be better placed in the Mathematics section, but I put it here in case I need to post C++ source to diagnose problems.
Alright, I'm making a booster that resists gravity, then propels a player into the direction they are pointing. The catch is that there is a maximum force that the booster can propel, and it won't exceed that force... so I'm trying to figure out how to do this.
I wouldn't mind being pointed in the right direction instead of having my hand held ;) ... just keep in mind, I don't have a great grasp on vectors just yet.
So, here's a couple of images to help illustrate what I'm trying to do (and how I've pictured it in my head on how I might be able to solve it.)
In this picture, gravity is defined as -20, the force the booster can output is 90. The vector marked as "x" is the direction that the player is facing. I figured I could just use vector projection at this point...
But...
This is an image that shows when a player aims a bit up. Vector projection wouldn't provide the correct vector then. Also, this vector is overall shorter compared to the other one (which makes sense, if you're pointing up, it should provide less net-acceleration because you're fighting gravity). So, I figured if I found out the x and z values necessary, then that'd work. But, that wouldn't translate very well into 3d. So in the end, I really just need an algorithm to figure out the scale needed for a vector... then all I'd need to do is take the eye vector from the player and scale it appropriately.
I'm coding all of this into updateMove, just for your information.
Thanks for any help you can give me.
#22
true,
but that note that K * (Desired - Current) already approaches zero as Current approaches Desired.
the bottom line is really how it feels to the pilot.
it might feel better without the dot, it might feel better with it. it might feel best with dot^2 or something. it's all about trying different stuff.
01/09/2009 (3:03 pm)
Quote:I would have k very with the dot product of the desired direction and the velocity direction. That way, when your velocity is pointing 90 degrees or so to your desired direction, you get a large correction, and when they're basically aligned, you get a very small correction.
true,
but that note that K * (Desired - Current) already approaches zero as Current approaches Desired.
the bottom line is really how it feels to the pilot.
it might feel better without the dot, it might feel better with it. it might feel best with dot^2 or something. it's all about trying different stuff.
#23
01/10/2009 (12:58 am)
Oh right. Sorry about that ;) 
Torque Owner Daniel Buckmaster
T3D Steering Committee
Orion - I agree, but I would have k very with the dot product of the desired direction and the velocity direction. That way, when your velocity is pointing 90 degrees or so to your desired direction, you get a large correction, and when they're basically aligned, you get a very small correction.
Dot product: if two vectors are parallel and same direction, = 1
If perpendicular, = 0
If parallel and opposite, = -1
So I would say...
k = 1 - dot(desired, velocity)
That means k will range from 0 (desired and velocity are the same) to 2 (they are exactly opposite). You could divide that by 2 so you get a range 0-1.