RE: [Algorithms] Integrating acceleration in 3D
Brought to you by:
vexxed72
Menu
▾
▴
RE: [Algorithms] Integrating acceleration in 3D
|
From: Stephane E. <set...@hi...> - 2006-04-14 17:46:45
|
> Yes and no; it turns out that even if you won't overshoot if > you don't start braking at the start of the frame, at the end > of the frame you might be going too fast and end up > overshooting anyway. Yes, this is why I said you need to figure out how long it will take you to stop AFTER applying your acceleration. If you overshoot, you clearly can't apply full acceleration.=20 > > The 3D problem isn't any more complex than the 1D problem. You > > can treat all axes independently. > > The problem is that the axes aren't independent. The > acceleration vector is dependent on the move vector, both of > which are rotating through the course of the frame. You don't need to worry about the fact that the move vector and the acceleration are rotated. It simply is a side effect irrelevant to the problem at hand. Because your coordinate is orthogonal, axes do are independent. > > Also, if your dt is not constant, there simply is no solution > > to your problem. > > That's what integrating solves. I.e. that's why you compute > > curPos +=3D (curVel * dt) + (accel * dt * dt / 2) > curVel +=3D accel * dt > > instead of > > curVel +=3D accel * dt > curPos +=3D curVel * dt Nope it does not. The dt transforms your continuous problem into a discrete problem. As long as your dt is constant, it's ok. If your dt is not constant, there simply is no good solution. Just picture what would happen if you planned on reaching your target in an expected 2 timesteps. If your first dt is too long (e.g. > 2 expected timesteps), you missed your target because you overshot. If you have not transformed your problem into a constant dt, I recommend that you do that right now. Things will look a lot better already. > The math is fairly straight forward for an instant in time.=20 > The problem I'm having is in integrating the solution for > continuous behavior. This is a red herring as using a dt discretize your problem. > > In practice, if your time step is small enough not doing > > anything in case 3 will probably work just fine. > > Haven't done much work on PSP games lately, eh Stephane? :)=20 > In practice, though, I think #3 wouldn't be terribly hard to > solve, but again you need to figure out if you'll be able to > stop on-target after you process this frame's motion. No PSP for me, that's for sure. But trust me on this one, just try it by applying 0 acceleration if after applying acceleration you will overshoot. Don't forget to check if you will overshoot by testing the situation at the next time step. Even if you apply no acceleration at this time step, you may overshoot at the next time step. If this is the case, then you need to start decelerating. -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Plunket Sent: Thursday, April 13, 2006 11:27 PM To: gda...@li... Subject: RE: [Algorithms] Integrating acceleration in 3D > You need to account for your current velocity and how long it > will take you to stop, otherwise you will overshoot. Yep, that's why I compute the "desired acceleration" from the difference between the target point and the point where I'd stop if I were at maximum braking. > When you overshot in 1D, this is probably what happened. Yes and no; it turns out that even if you won't overshoot if you don't start braking at the start of the frame, at the end of the frame you might be going too fast and end up overshooting anyway. I.e. even if distance-to-stop might be larger than distance-to-target, you still need to make sure that after this timestep that fact still holds (and if it doesn't, you need to back up a bit). Incidentally, I'm trying a variation on this in 3D right now but it's tedious just because I have to recompute a bunch of stuff twice... ...perhaps I could compute the fact that I will overshoot earlier though, but I'll have to ponder it. > The 3D problem isn't any more complex than the 1D problem. You > can treat all axes independently. The problem is that the axes aren't independent. The acceleration vector is dependent on the move vector, both of which are rotating through the course of the frame. > In conclusion, you need to the following: > > 1 - If after applying acceleration, I can still stop and not > overshoot, then apply maximum acceleration. > 2 - If without applying acceleration I will still overshoot, > decelerate as much as possible to minimize overshooting. > 3 - If none of the above, you can apply some amount of > acceleration. The math is fairly straight forward for an instant in time.=20 The problem I'm having is in integrating the solution for continuous behavior. > You could lerp from 0 to maxAccel as a function of how much > you would be overshooting if you applied full acceleration. I may go for an extra layer of continuity at some point, but I don't think I need to. > Since the equation for acceleration is not linear, your alpha > for your lerp needs to account for that. Linear acceleration is actually fine but not the battle I'm fighting at this time. > In practice, if your time step is small enough not doing > anything in case 3 will probably work just fine. Haven't done much work on PSP games lately, eh Stephane? :)=20 In practice, though, I think #3 wouldn't be terribly hard to solve, but again you need to figure out if you'll be able to stop on-target after you process this frame's motion. > Also, if your dt is not constant, there simply is no solution > to your problem. That's what integrating solves. I.e. that's why you compute curPos +=3D (curVel * dt) + (accel * dt * dt / 2) curVel +=3D accel * dt instead of curVel +=3D accel * dt curPos +=3D curVel * dt -tom! ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D= 121642 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |