Visualising one simulation step at a time

[ptheywood]

For visually debugging models, it would be useful to be able to run simulations a single step at a time, as in FLAME GPU 1.

Unfortuantely this is much more complex in FLAMEGPU 2 thanks to our simulation-rate independent visuasliation / multirthreading.

I.e. on pressing n (or some other character) or an associated controller binding, if the simulation is paused, run a single simulation step.

This would allow fast simulation upto an interesting state, then single stepping at the desired time.

---

It might also be nice to be able to say "pause on step 200" as well (mostly via the CLI?)

[Robadob]

Using the new blocking atomic, may be possible to re-enable that to block again. But will be a little arkward.

…

On Mon, 13 Mar 2023, 14:20 Peter Heywood, ***@***.***> wrote: For visually debugging models, it would be useful to be able to run simulations a single step at a time, as in FLAME GPU 1. Unfortuantely this is much more complex in FLAMEGPU 2 thanks to our simulation-rate independent visuasliation / multirthreading. I.e. on pressing n (or some other character) or an associated controller binding, if the simulation is paused, run a single simulation step. This would allow fast simulation upto an interesting state, then single stepping at the desired time. ------------------------------ It might also be nice to be able to say "pause on step 200" as well (mostly via the CLI?) — Reply to this email directly, view it on GitHub <#124>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVGCUHRMBHWFG5IIZFPXTW34ULRANCNFSM6AAAAAAVZER5RE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Robadob]

It might also be nice to be able to say "pause on step 200" as well (mostly via the CLI?)

This would be relatively simple to implement, it merely needs the simulation to lock the pause mutex, and store the lock in the visualiser at the appropriate time. Possibly not thread safe, but likely harmless.

I had a quick attempt at doing the same inside the render loop, but it easily misses exact steps when the simulation is small/running fast. Hence, the need for the sim to block itself.