The physics steps run at a fixed rate (60 updates per second by default). They are therefore not in sync with the frame update (that runs as many times per second as possible).
But a user may want (and sometime have to) run system synchronously with the physics step. Generally either before (when modifying position/velocities) or after the physiscs step (when reading the output).
This PR exposes the following stages:
stage::ROOTschedule stage that runs at a fixed rate (60 updates per second by default)
stage::UPDATE a child (parallel) system stage that runs before the physics step.
It also add the add_physiscs_system extension function on AppBuilder: to make simpler to add systems that should be synchronized with the physics steps.
This is a breaking change: Updating the transforms/velocities or any other physics component of rigid bodies must now be done in the physics update stage. Make sure to add this systems using the new add_physics_system extension function on AppBuilder
The physics steps run at a fixed rate (60 updates per second by default). They are therefore not in sync with the frame update (that runs as many times per second as possible).
But a user may want (and sometime have to) run system synchronously with the physics step. Generally either before (when modifying position/velocities) or after the physiscs step (when reading the output).
This PR exposes the following stages:
stage::ROOTschedule stage that runs at a fixed rate (60 updates per second by default)stage::UPDATEa child (parallel) system stage that runs before the physics step.It also add the
add_physiscs_systemextension function onAppBuilder: to make simpler to add systems that should be synchronized with the physics steps.This is a breaking change: Updating the transforms/velocities or any other physics component of rigid bodies must now be done in the physics update stage. Make sure to add this systems using the new
add_physics_systemextension function onAppBuilder