Reversing time, immutable timesteps, or serializing simulations

[harrisse]

Hello, I'd like to be able to "undo" calls to Simulation.Timestep and thought of a few ways I could approach this --

1. Is it possible to just pass a negative time into Timestep? I assume that this won't work deterministically for a variety of reasons, but if I don't need exact determinism it could be cool...
2. Is it possible to make an "immutable" call to Simulation.Timestep that returns a new modified simulation but doesn't modify the original simulation? It doesn't seem like this is built-in, so by "is it possible?" I more mean "how impossible is this and should I even bother trying?" I know immutable updates would be a lot slower, but I don't necessarily need every update to be immutable.
3. Can I reliably serialize and deserialize a simulation to disk? If so I could just keep track of each step myself and revert as needed.

Thanks!

[RossNordby]

Is it possible to just pass a negative time into Timestep? I assume that this won't work deterministically for a variety of reasons, but if I don't need exact determinism it could be cool...

Alas, this would break many things. Unlike real physics, the simulation is not time reversible.

Is it possible to make an "immutable" call to Simulation.Timestep that returns a new modified simulation but doesn't modify the original simulation? It doesn't seem like this is built-in, so by "is it possible?" I more mean "how impossible is this and should I even bother trying?" I know immutable updates would be a lot slower, but I don't necessarily need every update to be immutable.

It would be possible, but it would be strictly more tedious than 3, but not by a factor of 10. It would imply a lot more changes to the public API. Given the low relative value I wouldn't recommend this route.

Can I reliably serialize and deserialize a simulation to disk? If so I could just keep track of each step myself and revert as needed.

There's no exposed method to do this, but it is doable and something I've had on the to-do list for a while (#64). Capturing all simulation state to guarantee a perfect deterministic reproduction would be tedious-but-doable, but it would be pretty easy just to store the body poses/velocities.

[harrisse]

Great, I was hoping the pose/velocity approach would be "good enough" and it sounds like that's your experience. That also makes encapsulating side effects a bit easier, thanks for the guidance!

[damian-666]

unfortunely this ideal of reversiblity is quite new and requres a whole new approach. it possible but not practical in todays widespead hardware. we speak in megaflops. but in the future , we might not even use floats.

snapshots are not bad..but in substepping it kind of is, - quite a memory/ perf tradeoff. but on keyframes, if you take snapshots you also get an instant replay feature for free. if you use producer /consumer pattern you can have lockless 60 -120z hz drawing while your physycis threads run at 4000 fps for training bots , runnning CCD, or whatever.. if use setTimerResolution to 1 -4 ms you can have a smooth realitme framerattes as well for gaming whiles sleeping during physics loop.

https://www.josstam.com/reversible i think this is a very underexplored area since this guy publishes a seminal paper , only every 20 years maybe its worth a read since it jsut preprinted. STAM pretty muchsta kicked off started interactive fluid dynamics for games, 1999 stable fluids..

  also julia does have the tyes required but this is for academia not for shipping games.   and ILto-chip vaults are expermienting for n bit as SIMD types for machine learning and oher application like reversible ode solvers that use interbody nodes with learned biases that help to converge interactive solvers faster.   consider a pile of blocks.  if the ssystem learns that bottom body in a house of cards, influences bottom top by X ( its entire height, yet it might have a small mass) , you can apply a bias to the preconditioner on the next solve.    When we use an iterative solver with high mass ratios its takes 20 iteractoins to shake out the constraints pairwise. with a CNN -hybrid approach it take 2 iterations to converge on the second solve .