search

pachocanadian / sole

SOLE - Simulator Of Lifts and Elevators
GNU General Public License v3.0
1 stars 0 forks source link

Review tick() logic with respect to scaling against real world units and frame rate #7

Open pachocanadian opened 5 years ago

pachocanadian commented 5 years ago

The underlying unit within SOLE is a tick which is an integer unit. We will not use floats or decimal time units for the tick.

If we start rendering at 60 fps will this cause issue?

If we're expressing things like gravity acceleration or velocity limits in ticks, how does affect things if we say there are 100 ticks per real world second or 1000?

Ideally I'd want to express limits in real world terms. The simulator should be able to abstract them back. But plan this out because I can see it causing us grief long term.

Stemist commented 5 years ago

Using ticks being equal to a real unit of measurement might be our best bet. We could have 1 tick = 1 millisecond (ms), which should give us enough leeway for fps upgrades.

Where: (1000 tick/s) / (60 frame/s) = 17 tick / frame

If we chose 1 tick = 10 ms we could instead have 1.7 tick / frame, assuming 60 fps.

Depending on how the simulation performs one of these options might be optimal.

pachocanadian commented 5 years ago

My thought is that ticks might need to be variable. If we disconnect the GUI component and we're simulating 10k sessions per iteration then I'd want them to run significantly faster.

Putting all this a different way, I'm thinking that the velocity/acceleration units need to be in real world terms (e.g. 9.8 m/s^2) and then ticks can scale to whatever makes sense. So if we were running 100 ticks per real world second then those units internally would scale to 9.8E-4 m/tick^2. I then don't want to record constants in tick terms then but in real world terms and let the tick math calculate as needed.

It also reveals that we'll need to look at what level of precision Python uses for calculations, e.g. floats vs doubles, as on arbitrary small units it might start rounding out to zero.

Stemist commented 5 years ago

That sounds like a good idea.

From a quick research in the Python docs it seems that Python floats have 15 sig figs (https://docs.python.org/3.7/library/sys.html#sys.float_info). It looks like Python doesn't have doubles, and uses floats with 15 sig figs in place of them.