Avoiding fixed timestep death spiral?

[airstruck]

Right, I get what you mean with the rectangle thing, it's the usual way to do this kind of thing and requires a fixed timestep. I'm not sure how it relates to integrating nth-order derivatives with a polynomial, though.

About computation error, I assumed it could be magnified by constantly passing the result back into the function, but I haven't looked at it in that much detail. I wonder if it might help to have normal timestep calculate things with the same granularity as double timestep somehow, or if lookup tables would be any use. Simulation doesn't need to be perfect but having stability across an adjustable timestep would really be nice.

[ivan]

seemed like the most logical thing to do; i mean, going from the second to the third of my examples, at least.

I like the second option - it's simple, effective and most importantly fixed so you could theoretically expect the same results each time.
As mentioned in the article, you could even use linear interpolation to make rendering 'smoother' although I haven't noticed any difference, in fact I would recommend against it.
If you're making a platformer for example you want your character to jump N number of frames and with interpolation (as with variable time steps) the 'apex' of a jump could happen 'between' frames which just doesn't seem right.
Box2D likes fixed time steps so I doubt that the third option will work very well - the biggest difference would be in the behavior of joints. It might be possible to get it working by tweaking the sub-step/iterations but that's an unnecessary complication IMHO.

[raidho36]

It relates because some of the terms assumed to be constant when they aren't, effectively reducing limit method to rectangle method. In the end it's about what kind of error is acceptable for your application - and here we are, we made a full circle.

Errors accumulate exponentially when you do multiplications, in additions and subtractions they accumulate linearly. Assuming of course there were errors to start with - we're past the age of Pentium 1.99997 where simple straightforward mathematical operations produced any errors.

[airstruck]

It relates because some of the terms assumed to be constant when they aren't, effectively reducing limit method to rectangle method.

I'm not sure that's accurate. The terms really are constant over the course of one tick, and at the end, new constants are calculated for the next tick, each one from its own polynomial. Mathematically, the double-length tick really should arrive at the exact same values as two single length ticks as far as I can tell. I don't think it's the same as the rectangle method. The fact that it can run for hundreds of thousands of iterations without losing any stability at all (under the right conditions) is a big difference from the rectangle thing.

Interestingly, if "jerk" is not a multiple of 3, the two simulations divert right away, probably because a multiple of jerk gets divided by 6, so if it's not a multiple of 3 there's no exact binary representation. If jerk is a multiple of 3, it seems to remain stable "forever" as long as x doesn't get so big or so small that you lose precision when solving the polynomial. That was the cause of the two simulations diverting after running identically for an "hour" or so. Those were the only two sources of instability, I think. The second thing is unlikely to happen in a real scenario, but the first is an issue.

[raidho36]

It is accurate, but that only applies to the terms you hold constant - my mistake. Result is still all the same - output is as if you used rectangle method. In your simulation results don't diverge because you use constant values - as if framerate was fixed to the lowest of the bunch, making higher framerate calculations meaningless. As soon as you start making speed, acceleration or jerk that vary over time you'll see the two framerates diverge. The divergence really depends on frequency and magnitude of the changes relatively to the timestep. I've used simple sine function to produce variable values, with rotation speed of 1/10 revolutions per iteration, and it produced 7% discrepancy. At 1/20 RPI speed it produced 2% discrepancy, and at 1/50 RPI it produced some odd fraction of percent of discrepancy. All of that when jerk was variable over time. In general case, making any particular derivative vary over time sends "pulse" down the derivatives chain, with first few derivatives overshooting a lot, which then asympthotically reaches some value - slowly, over very long chain: using 10th order derivative only improved the 2% discrepancy by 0.2%.

[airstruck]

As soon as you start making speed, acceleration or jerk that vary over time you'll see the two framerates diverge.

Everything but the highest-order derivative already varies over time. Yes, if you start modifying them between frames while the simulation is running, it will cause problems.

I'm not sure how you tried to apply the sine function, but you can't retain stability by doing it in the usual way, like `t.x = t.x sin(t.y) * dt` in between frames. That calculation needs to be part of the polynomial, as something like -cos(y). This is what I meant earlier when I said "I suppose damping or anything else that would affect the outcome would also need to be part of the formula."

[raidho36]

Obviously user input can't be part of the formula. Nor can be collisions and whatnot, pretty obvious.

I've applied sine function by substituting some of the derivatives' fixed value with output of sine function. Everything else was set to 0. Since the difference is usually very large, let alone merely "visible", you can do this in real time with left and right arrow input.

[airstruck]

Obviously user input can't be part of the formula.

Maybe not, but I don't really see an issue with that. In general, input is pretty much assumed to have started at the beginning of the frame and lasted until the end of it. If it's been a long time since the last frame there's not much you can do, you just treat it as if the key's been down the whole time. When the key is down you won't want to modify values incrementally, you can just set velocity/acceleration/jerk to some value and set it back to 0 when the key isn't pressed anymore. If you play it back later, it won't matter that during the actual game the player got a double tick while a key was down. During demo playback you get two single ticks with the key down for both and things remain stable.

Nor can be collisions and whatnot, pretty obvious.

Collisions will be tricky to keep stable, maybe not impossible though.

I've applied sine function by substituting some of the derivatives' fixed value with output of sine function. Everything else was set to 0. Since the difference is usually very large, let alone merely "visible", you can do this in real time with left and right arrow input.

I'm not really sure what the intent was there. If you integrate sin(x) you get -cos(x), if you integrate that you get -sin(x), then cos(x), and then sin(x) again. So there's really not much point in trying to use a sine function as a derivative, just set the final value to sin(x) or cos(x) or whatever.

[raidho36]

And now back to the question if wrong input timing is acceptable in your game. If it isn't, then longer timestep is not an answer.

I know that this is what happens if you pass trigonometric functions into it. The point was to highlight the difference in output between "60" fps and "30" fps scan frequency of some variable that "cannot" be implemented as part of the formula. For the two different update rates, final result is not nearly the same despite using same exact input source.

[airstruck]

And now back to the question if wrong input timing is acceptable in your game. If it isn't, then longer timestep is not an answer.

Input timing is always "wrong," there is no timestamp on input events. The premise of this thread is that sometimes a frame takes longer than expected. By this point you already have "wrong input timing" and there's nothing you can do about it. Processing multiple timesteps at once won't fix it, pretending not that much time elapsed won't fix it, nothing will fix it. Input lasts the whole frame. Input timing is not relevant to the topic of this thread. If you wish to discuss it, please do so elsewhere.

For the two different update rates, final result is not nearly the same despite using same exact input source.

Of course not, you can't take the output of some function and expect integrating that value over time to magically give you the result you'd get from integrating the function over time. If you want to integrate functions rather than values (and then sample their antiderivatives, I guess) you'd need to do it yourself, which should be trivial for a sine function.