[WMCoolmon]

Given:
Distance to travel (units)
The time to take for acceleration, also for deceleration, so to get the total accel/decel time you would multiply this by 2 (seconds)
The total time for the trip (seconds)

Wanted:
Acceleration speed (units/s/s)
Coasting speed (units/s)
Time to reach point of deceleration from start of trip, including acceleration (seconds)

This is for the camera code, I've been trying to figure it out without much success. It's frustratingly simple and tantalyzingly out of reach.

[an0n]

http://en.wikipedia.org/wiki/Equation_of_motion

[Liberator]

From a pure mathematical and space travel pov, you would accelerate right up to the point you need to start decelerating, preferably at or around 1g to simulate gravity.

[StratComm]

Can't be done.  You've got to cap either acceleration or camera speed for this to be calculated.

Acceleration speed (units/s/s) : [2*(distance covered in acceleration)]/(acceleration time)^2
Coasting speed (units/s)[(total distance) - 2*(distance covered in acceleration)]/[(total time)-2*(acceleration time)]
Time to reach point of deceleration from start of trip, including acceleration (seconds) (total time)-(acceleration time)

if you, for example, gave acceleration time and distance, it'd be trivial.  Similarly a percentage of distance times the percentage of time could be used to calculate this (it'd be code-fixed, if you wanted to go that route) but you either need to know what acceleration is, have some pre-defined distance for it to happen over, or have a fixed internal calculation to extrapolate that data.

[WMCoolmon]

As long as x distance is moved in y amount of seconds and it takes z seconds to accelerate/decelerate, I don't really care what it takes - as long as it's a direct path.

The equation I got from an0n's link was

Code: [Select]


u = initial velocity
v = final velocity
At = acceleration time
T = total time
Td = total distance
Td = 2(((u+v)/2)*At) + (((u+v)/2)*(T-At))
or
v = (Td/At-u)/T

I'm guessing the problem is that I combined the two equations (plus sign in the middle) for the total distance, but u is different for each (For the first it's the speed of the camera at first, for the next it's identical to v - the coasting part). The result has been the camera whirls around a few times at high speed before decelerating properly in a random position.

[phatosealpha]

Hold on.  I'm gonna solve this for you.

[phatosealpha]

Assuming constant Acceleration and initial and final camera velocities of zero:

Acceleration = Total distance / ((Total Time * Acceleration Time) - (Acceleration Time ^ 2))

Coasting Speed = Acceleration * Acceleration Time

Time to reach point of Deceleration = Total Time - Acceleration Time



Do you need the core mathematics, or are the formulas all you need?

[StratComm]

EDIT: I'm retarded.  Yes, it works.

Say, 10 meters, 10 seconds with 2 seconds acceleration/deceleration:
acc. = 10/(10*2-2^2) = 0.625/s/s
coasting speed = 0.833*2 = 1.25m/s
time to point of deceleration = 10-2 = 8s

Distance traversed = 1/2*0.625*2^2 + 1.25*6+(1.25*2+1/2*-0.625*2^2) = 1.25+ 7.5+ 1.25 = 10.  Duh.

[phatosealpha]

Edit :  Grin.  Ok then.

[StratComm]

nevermind

I love editing  Everyone will look at this tomorrow and have no idea what's going on.

[WMCoolmon]

Well, that still causes the camera to spin 'round in circles, and it doesn't end up in the same spot each time. (In fact, it can be significantly different. )

My code:

Code: [Select]

float frametime, rot_frametime, trans_frametime;

rot_frametime = trans_frametime = in_frametime;

do
{
frametime = rot_frametime;
if(rotation_rate_delta_time_left || rotation_rate_decel_time_til > 0.0f)
{
if(frametime > rotation_rate_delta_time_left && rotation_rate_delta_time_left)
frametime = rotation_rate_delta_time_left;
if(frametime > rotation_rate_decel_time_til && rotation_rate_decel_time_til > 0.0f)
frametime = rotation_rate_decel_time_til;

if(rotation_rate_delta_time_left)
{
rotation_rate.p += (rotation_rate_delta.p) * frametime;
rotation_rate.b += (rotation_rate_delta.b) * frametime;
rotation_rate.h += (rotation_rate_delta.h) * frametime;
}

if(rotation_rate_delta_time_left)
{
rotation_rate_delta_time_left -= frametime;
}
if(rotation_rate_decel_time_til > 0.0f)
{
rotation_rate_decel_time_til -= frametime;
if(rotation_rate_decel_time_til == 0.0f)
{
rotation_rate_delta.p *= -1.0f;
rotation_rate_delta.b *= -1.0f;
rotation_rate_delta.h *= -1.0f;

rotation_rate_delta_time_left = rotation_rate_delta_time;
rotation_rate_decel_time_til = -1.0f;
}
}
}
rot_frametime -= frametime;
} while(rot_frametime);

Volition's code to apply physics. I have no clue what 'damping' is though, so I haven't used it.

Code: [Select]

//==========================================================================
// apply_physics - This does correct physics independent of frame rate.
//
// Given:
//    damping = damping factor.  Setting this to zero make the object instantly
//              go to the target velocity.  Increasing it makes the object ramp
//              up or down to the target velocity.
//    desired_vel = the target velocity
//    initial_vel = velocity at last call
//    t = elapsed time since last call
//
// Returns:
//    new_vel = current velocity
//    delta_pos = delta position (framevec)
// You can extend this to 3d by calling it 3 times, once for each x,y,z component.

void apply_physics( float damping, float desired_vel, float initial_vel, float t, float * new_vel, float * delta_pos )
{
if ( damping < 0.0001f ) {
if ( delta_pos )
*delta_pos = desired_vel*t;
if ( new_vel )
*new_vel = desired_vel;
} else {
float dv, e;
dv = initial_vel - desired_vel;
e = (float)exp( -t/damping );
if ( delta_pos )
*delta_pos = (1.0f - e)*dv*damping + desired_vel*t;
if ( new_vel )
*new_vel = dv*e + desired_vel;
}
}

The function the AI uses to try and point itself towards a target (I'm liking this one):

Code: [Select]

// ---------------------------------------------------------------------------------------------
//
// inputs: goal_f => goal forward vector
// orient => current orientation matrix (with current forward vector)
// w_in => current input angular velocity
// delta_t => time to move toward goal
// delta_bank => desired change in bank in degrees
// next_orient => the orientation matrix at time delta_t (with current forward vector)
// NOTE: this does not include any rotation about z (bank)
// w_out => the angular velocity of the ship at delta_t
// vel_limit => maximum rotational speed
// acc_limit => maximum rotational speed
//
// function moves the forward vector toward the goal forward vector taking account of anglular
// momentum (velocity)  Attempt to try to move bank by goal delta_bank.  Rotational velocity
// on x/y is rotated with bank, giving smoother motion.
void vm_forward_interpolate(vector *goal_f, matrix *orient, vector *w_in, float delta_t, float delta_bank,
matrix *next_orient, vector *w_out, vector *vel_limit, vector *acc_limit, int no_overshoot)

[phatosealpha]

Hm.  I should probably note you'll lose any signage, just in case.  Ie, if you're using coordinates, and the distance is negative, it will still return a positive acceleration even thought you'd want a negative acceleration. You'd have to check the to see if the sign of acceleration matches the sign of distance.  I don't know much C, but let me look over this code, just in case.

[StratComm]

This is vector based, velocity should always be positive.  I think the problem here is in the rotation, not translation; unless this is for a pan command and you're doing something with angular velocity.

Is checking a float for trueness safe?

[phatosealpha]

Allright.  Well, this is the only shot I'm gonna give this, since I don't understand too much C++ at all.



if(rotation_rate_delta_time_left || rotation_rate_decel_time_til > 0.0f)

If I'm reading this right, you want to adjust the velocity only if it's in the acceleration or deceleration stages.  So, if rotation_delta_time_left > 0 you're still in acceleration.  But, rotation_rate_decel_time_til sounds like it's the amount of time til you begin deceleration.  From the check though, it's doing it if there is still time before you should start deceleration, and if you're in the deceleration phrase, you'd want there not to be time left until deceleration.  Maybe this should be

if(rotation_rate_delta_time_left || (rotation_rate_decel_time_til < 0.0f))

So you've got , if there is still acceleration time left, or the time till deceleration is negative, do the acceleration.



And if I've just wasted a bunch of time, apoligies.  My first C++ course was tonight, heh.

[WMCoolmon]

You're close.

What that controls is whether or not the time is incremented for both of those variables, if either one exists they need to be worked on, otherwise the code can just skip that and go onto calculating the translation acceleration/decceleration stuff.

I'm still having some trouble, but I think my problem now is just that the angles p,b,h don't match up with x,y,z in that order; the vm_matrix_interpolate function (not shown above) does nothing rather than crashing, so I think that the max accel/velocity isn't being set right.

[StratComm]

aren't p, b, h pitch, bank, and heading, respectively?  So it'd be (to freespace) z, x, y in that order (assuming x is forward, y is up, and z is to the side).

[WMCoolmon]

Edit: Ignore me. Stratcomm's a genius.

[Bobboau]

take a look at some of the animation code I made (some of it is in CVS), I solved some stuff very similar to this.

[StratComm]

The only reason I even recognized those variables is that's what they are called in the background editor in Fred.  But for three rotational axes, it only makes perfect sense.

[WMCoolmon]

Well, I kept thinking h = hypotenuse, and you can count the number of times I've opened the background editor dialog in FRED on one hand. (Danger: I have never done the walkthrough.)

Bobb: Thanks, I still have to do the translation code.