so, we have a fast forward button, but where is the rewind, i think i would rather have it reversedi like watching a certain part i cant do so i can perfect how its done, and we dont have rewind so we have to fast forward everytime to that certain part, kind of a pain
Agreed!Originally Posted by 420so, we have a fast forward button, but where is the rewind, i think i would rather have it reversed
OMG yes...I hate thatOriginally Posted by noggleAgreed!Originally Posted by 420so, we have a fast forward button, but where is the rewind, i think i would rather have it reversed
I agree 100% , a rewind button would be real nice
Trials Developer
Rewind is almost impossible to implement as we have complex physics simulation in the game. The physics engine cannot be run at reverse direction. Even if the physics engine would be completely remade to support reverse simulation as well, there would be issues with floating point numeric precision. Backwards and forwards simulation would always result in slightly different results, meaning that the replay system would go out of synch.
It's possible to save all object positions for every frame, and allow a limited rewind that way. But a rewind that allows only 5 seconds is not that useful. Especially if we need to use large amount of memory to support it. I don't think a rewind functionality would be worth the reduced graphics quality (smaller textures), and a more limited level size.
Junior Member
Hey Seb, have you considered implementing keyframes for replays?
Have the physics engine re-creating the replays based on stored user input as it is, but a keyframe every second or so stores the precise state of rider, bike & dynamic objects.
This would not only permit rewinding replays, but would also likely fix the glitchy replay problem where the run isn't re-enacted properly and the rider crashes on a replay of a clean run. The storage requirements for replays would be a bit more than current, but nowhere near as bad as storing a complete dynamic object state every frame.
Trials Developer
A single key frame would be around 8 kilobytes in compressed format. The whole replay currently takes only around 1-2 kilobytes. Keyframe every second would increase the replay file size by 500x (on a 60 second run). Also using compressed keyframes would result in slightly different physics interaction. In worst cases this could mean some triggers not triggering at all (great potential change in world state). Lossless keyframes would take around 30 kilobytes each.Originally Posted by Lestropie
Keyframes would allow proper rewinding, but one keyframe in a second would need us to rewind back and simulate 60 frames of physics (forward) very quickly whenever the user starts to rewind. In physics heavy tracks (physics engine needs full 1/60 seconds to simulate one frame), this would mean a one second pause before we have all the object positions calculated for the previous keyframe (and 60 frames after it to allow smooth animation). However after the rewind has started running, the animation would be smooth, as we can always simulate the next one second backwards at the same time we are replaying the buffered animation.
Member
What about one keyframe per checkpoint, and let us rewind to the last checkpoint... ?
Junior Member
In terms of the rewinding, I was just thinking show only the keyframes when rewinding, and playback occurs only from a keyframe. Trying to rewind frame-by-frame definitely can't be done in real-time in this framework.
But yeah, the storage ratios are bigger than I expected. 1-2 kB for a replay is just crazy.
In that scenario, a keyframe per checkpoint would be more plausible, but the storage is still going to increase by ~50X per replay with compression, so to use the existing server storing the replays, only the top 100 or so replays could be stored, as opposed to the current top 5000 per track. Some people might not be happy with this. And even then, you have to justify the development time in doing it.
Out of curiosity, how did you actually manage to get a fast-forward implemented? I would have thought that, with all six cores essentially maxing out, you wouldn't be able to re-create the run at anything faster than real-time...
ouch I had no idea it would be pretty much impossible 2 rewind....oh well
