Open giulioforesto opened 10 years ago
A suitable solution would be to store (only) in the Processing variable all the masses at each data frame.
Another more economic and equally suitable solution would be to store (in an array or whatever data structure suits you) all the masses, but only at the times of change (i.e. time of the changes => future masses) when the input data is read. Then if one needs to rewind (or rather jump backwards, unless you want to implement a time-reverse play function (that would be cool ! you would then also need the past masses)), a search would be performed in this array in order to :
In a nutshell :
t(j)
, search the closest previous t(p)
time t(p) < t(j)
[edit: where the mass is known]t(j)
are the same as those at t(p)
PS : zivacomptutlapetaparlerenanglais
Partially fixed: For jump backwards feature the data reader restarts from the beginning so it gets all the history until the selected instant.
The issues is still open for the case of the frame-by-frame backwards feature. The same solution could be chosen but it could cause problems if frame-by-framing backwards too quickly, because at each frame the reader would browse all the frames from the beginning to the displayed one. This case is to be tested.
In the current situation masses and colors should be got back when jumping backwards or rewinding frame by frame, because in the output file two planets colliding generate a new planet with a new id (incremental generation). So ids are not re-used. TODO Check the preservation of masses and colors.
For the rewind feature, how can we get the past situation at the given time if we don't store mass data but only its changes? If coordinates presence/absence can determine the planet's presence/absence, we don't know anything about the mass.