Today I finally met Zeno, Achilles and Tortoise while testing my time machine

[guramarx]

No, I didn’t travel back in time to meet them, no real time machine here unfortunately but Yes, this is game development related of course :eyebrowlift2:

I was testing the idea of rewinding time, but in actual test I was just reanimating and placing them back in the recorded position some time before, however due to some discrepancy in the history frame and playback frame and add in my stupidity, my objects stutter and freezes and teleport… instead of moving smoothly to the interpolated position

Here is where Zeno came along with Achilles and Tor… nvm, problem was due to how I interpolate position each frame, in my head I kept thinking I should increment a frame counter each frame to indicate time passes and lerp the object position closer to the destination, everything sound right logically… except as time and frame increases my object is forever and ever fall behind…

pseudo only

if frame_counter< max_replay_frame:
    frame_counter +=1
else:
    frame_counter = 0 #division by 0 error not handled here
ratio = 1/frame_counter
obj.worldPosition = obj.worldPosition.lerp(destination,ratio)

I struggle with this for awhile but finally think about it, I will only reach my destination if the ratio is 1/1=1(100%), but if the frame_counter increases with time and the ratio goes 1/2=0.5(50%),1/60 =0.016(1.66%), I’ll only move slower and slower and only take infinitely smaller steps as infinitely more time passes if I hadn’t reset the frame_counter to 0 every time it reaches max_replay_frame

I have HEARD about this paradox from documentary and stuff but I never thought to SEE and EXPERIENCE them first hand with my own self, so today I finally ever so faintly grasp the wisdom from Zeno of Elea handed down millenniums ago… it is amazing :yes:

That’s all for today’s amazing encounter, who knows whom I’m gonna meet the next time I venture deeper in time lol

and the solution btw, is to deduct some max_frame with the increasing frame_counter and you should* have smooth interpolation between each frame, at least for me

ratio = 1/(max_Replay_Frame - frame_counter)
obj.worldPosition = obj.worldPosition.lerp(destination,ratio)

[Monster]

Rewind (or reverse time) is not just to interpolate positions.

You need to track back the modifications an object took over time. This sounds simple when an object moves forward with constant speed. In this case you can calculate the steps and create according counter steps. But this is a special case.

More often you will discover results of other events. E.g. the object collided with some other and stopped, or slowed down, and/or changes direction, and/or explodes into other objects, or disappears completely. How do you you want to “rewind” such situations?

You can indeed record such modifying events and back interpolate the modifications between them. This would be a bit more efficient than recording each single frame. This means your idea of calculating backward to the event that caused it, might work.

Here is another “but”, what do you want to do with non-linear modifications? E.g. falling, moving with friction etc…

Overall it is possible, but not easy.

[sdfgeoff]

Nice reference to Godel Escher Bach. Yes, Zeno does have a point sometimes doesn’t he! I’m going to have to reread that at some point…

ratio = 1/(max_Replay_Frame - frame_counter)
obj.worldPosition = obj.worldPosition.lerp(destination,ratio)

I discovered this one the other day as well. I was looking at averaging large sets of numbers in ram limited systems:

float average = 0;
void average_next_number(new_number, num_numbers_so_far)
    float alpha = 1.0/num_numbers_so_far;
    average = ((new_number * alpha) + (average * (1 - alpha)));

While it didn’t any advantage where I wanted it to, it was an interesting exploration.

Perhaps a better solution for trying to adjust time though is to also store the new position. Because then you can go forwards and backwards in time. Using lerp with an asymptotic decay can only go backwards through time…

Final comment from the excellent webcomic xkcd:

Attachments

[CarlJohnson]

I found working exemple that might inspire you years ago, here’s the link:

http://blendercave.tuxfamily.org/?page=categorie&cat=62

[guramarx]

@Monster
Thanks for the insights

Yes, the whole idea is to keep as minimal save points as possible in between because recording at 60 fps will limit the amount of time I can rewind but I might get away with less data needed in between if I interpolate them like how animation keyframing does, my test are more of a proof of concept at the moment so I’ve only accounted linear motion changed over time

I was hoping I can slerp with non linear motion for jumping and falling but the hard part is to determine ‘when’ to save an event, I know calculus will help but then… I remember I can’t even do linear algebra or pre-calculus properly lol it indeed won’t be easy lol

@sdfgeoff
I just googled the reference and allow my shameless assertion, perhaps great minds think alike lol

Perhaps a better solution for trying to adjust time though is to also store the new position. Because then you can go forwards and backwards in time. Using lerp with an asymptotic decay can only go backwards through time…

Thanks for the tips, I did tried to extrapolate my future position in order to determine where I had changed my direction and a keypoint should be saved but it will need more tests before I can be sure it will work as intended

xkcd LOL

@CarlJohnson
Thanks for the resources, rewind/replay examples are quite rare in the bge