There’s something I’ve always been curious about interpolating between the two different states. If say sprite animations were based off specific update states, how is that handle when the states are interpolated? For example, a player is at rest at the last state but now moving in the current state. When the player moves in the current frame, an animation is triggered. If alpha = 0.5, what do you do with the animation? If it is played, then the time passed for the animation will be a negative number. If I had to guess, I’d say to start the animation and if the time elapsed for the anim is less than 0, just display the first frame and if the time is positive, then the animation time is the actual program time minus a fixed step time. Can you clarify if this makes any sense? Thanks!

great article! I find your interpolation technique interesting. Is this something that is commonly done in games? Somewhere above, you say that it does not create (visual) penetration. I don’t see why not. Every inexpensive (relative to the actual physics computation) interpolation technique can create state that is physically not valid. If you take your example of a V-shaped bounce, interpolation could create a position that lies somewhere in white space, e.g., between the top corners of the “V”. If there is another small object at that location that won’t actually be hit, you will get visual penetration, don’t you? Or am I missing something?

Cheers

As others said, you have a knack for teaching – explaining what needs to be said in a manner that is easy to understand quickly. I’m looking forward to reading the rest of your posts.

My concern is that rendering is always rendering (0,1] timestep behind. It will never be up-to-date.

My proposed solution follows the change from “previous/current” state mindset to one of “current/next”. We always solve up to the “nextState” and then interpolate from current to next. This shouldn’t be an issue under the concept that a single-simulation-iteration should take far less time than rendering. We also end out loop with a negative value accumulator (meaning how much time we must “wait” before we arrive at the “nextState”).

Code changes:

Current state = Next state (Purely for readability)
Previous state = Current state (Purely for readability)
Inner while-loop would read: “while (accumulator >= 0)”
Assigning of alpha value would read: “const double alpha = – accumulator / dt;”

Any reasoning that this wouldn’t work that you can see, and if not, then any reason that it would not work better? (Takes away the concept of always being 1 step behind.)

The only thing that comes to mind would be interactions (or any event) that would alter the way the state will integrate from the rendered state to the “next state” that has been stored. Easy work around here is to define that such non-determinstic events are to be applied after the time has been spent to reach the “next state”… which should be hardly noticeable I would think.

Looking forward to your response, and I apologize if someone else mentioned this and I misread.

cheers

my code here is:

static double TIMEINTEVERAL = 1.0f/60.0f;
static double MAX_CYCLE_NUM = 5;
static double timeAccumulator = 0;

timeAccumulator += timeStep;
if (timeAccumulator > MAX_CYCLE_NUM * TIMEINTEVERAL) {
timeAccumulator = TIMEINTEVERAL;
}
while (timeAccumulator > TIMEINTEVERAL) {

timeAccumulator -= TIMEINTEVERAL;
world ->Step(TIMEINTEVERAL,
velocityIterations,
positionIterations);

}

if (timeAccumulator > 0) {
const double alpha = timeAccumulator / TIMEINTEVERAL;

world -> Step(timeAccumulator, velocityIterations, ); // here i dont know how to do ???
}

hopefully ,my expression is clearly