BasicThread idling

[Julien Lenoir]

Hi OSS users,

I recently had to pause my own version of the PhysicsManager (deriving
from BasicThread) to control the advancement of the simulation, but we
do not have such fine grain control over each thread. We can stop the
simulation in the runtime so far, which controls all threads.
Therefore, nothing is running anymore (no behaviors, no graphics, so
no keyboard as well...). So having a behavior that wait for a key to
resume the simulation does not work.
I did a quick fix where I added a feature in BasicThread to
"idle"/pause the thread. The thread state per-se does not change (no
wait, no barrier, no sleep), but a simple flag is raised to ask the
thread to not update itself anymore. So the update method simply check
the flag and skip any update if the thread is supposed to idle.
This feature allow me to stop the physics loop, while the behaviors
and graphics still run, so i can move the camera, observe a given time
step of the simulation from any angle and resume it whenever is
convenient.

It seems like a nice feature to have in the master, available to everybody.
Any thoughts on the feature itself ? Or any other solutions to achieve
the same results ?

Thanks !
Julien

[Paul Novotny]

Could you achieve the same result on the component level? ie, by setting
the physics representation to inactive? That would keep all the
behaviors and graphics still running too. If you needed to pause all the
physics components instead of just one, I think you could query the
physics manager for it's components, and set them all inactive.

-Paul

[Julien Lenoir]

The goal is to freeze the physics, so that would be deactivating all
physics components.

Setting the components to inactive is not a solution right now because
some physics simulation parts would stop computing (free motion, push
mlcp result) but some others don't check on inactive/deactive
components right now (DCD calculation) plus all the computations that
are not relying on the components themselves but the physics manager
state would keep running (constraints generations, buildMLCP,
solveMLCP, pushMLCPResult).

Even if all Physics::Computation were ready to handle this properly,
setting all components to inactive needs to happen all at the same
time in the physics loop and at the right moment, so it has to be in
the physics manager, any other way could cause lots of damage in the
physics simulation.
Also, I think we want to get away from behaviors that access the
physics manager, and focus on behaviors that communicate at the
component level (representation). Right now, we are developing the
management of non-contact constraints this way (permanent bilateral 3d
constraints for example). These constraints will be triggered by a
behavior, registering them not on the PhysicsManager but on the
Representations themselves. In our case, it would require many
instantiation of a behavior that would be connected to only one
physics representation at a time.

-- Julien

> --
> You received this message because you are subscribed to the Google Groups "openSurgSim" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to opensurgsim...@simquest.com.
> To post to this group, send email to opens...@simquest.com.
> Visit this group at http://groups.google.com/a/simquest.com/group/opensurgsim/.

[Paul Novotny]

On Thu, 2014-03-06 at 09:42 -0300, Julien Lenoir wrote:
> The goal is to freeze the physics, so that would be deactivating all
> physics components.
>
> Setting the components to inactive is not a solution right now because
> some physics simulation parts would stop computing (free motion, push
> mlcp result) but some others don't check on inactive/deactive
> components right now (DCD calculation) plus all the computations that
> are not relying on the components themselves but the physics manager
> state would keep running (constraints generations, buildMLCP,
> solveMLCP, pushMLCPResult).

That sounds like a bug. If you set the a physics component to inActive
(we have the interface right now) and it continues to run, that is a
bug. So we should fix this.

> Even if all Physics::Computation were ready to handle this properly,
> setting all components to inactive needs to happen all at the same
> time in the physics loop and at the right moment, so it has to be in
> the physics manager, any other way could cause lots of damage in the
> physics simulation.

If it is a physics behavior it occurs at the beginning of the Physics
Manager update. (processBehaviors). So it will occur at the right time.

> Also, I think we want to get away from behaviors that access the
> physics manager, and focus on behaviors that communicate at the
> component level (representation). Right now, we are developing the
> management of non-contact constraints this way (permanent bilateral 3d
> constraints for example). These constraints will be triggered by a
> behavior, registering them not on the PhysicsManager but on the
> Representations themselves. In our case, it would require many
> instantiation of a behavior that would be connected to only one
> physics representation at a time.

I am not quite following this. Are you against a behavior connected to a
manager?

-Paul