thesis - Computer Graphics Group - Charles University - Univerzita ...

96 CHAPTER 7. SIMULATOR
Simulation groups are advanced in contexts of chained transactions, where each transaction
advances a corresponding simulation group to a desired time. If we have n simulation
groups denoted G1, . . . , Gn then there are n chained transactions, where the i-th transaction
advances Gi, the first transaction is triggered by the simulator and the j-th transaction
(j ≥ 2) by the (j − 1)-th transaction.
The chaining of transactions works as follows. The simulator triggers the first transaction
to advance G1 (while advancing G1 the other simulation groups are not updated). If G1
reaches the desired time, then the second transaction is triggered to advance G2 and the
first transaction waits for the second transaction to complete. If the second transaction
commits then the first transaction must commit too and if the second transaction aborts
then the first transaction must abort. The same rule applies to the i-th and the (i + 1)-th
transactions (the (i + 1)-th transaction is triggered by the i-th transaction when Gi reaches
the desired time, the i-th transaction commits or aborts depending on the completion status
of the (i + 1)-th transaction). As a result, either all transactions 1, . . . , n commit if all Gi
reach the desired time or transactions 1 ≤ j ≤ i abort if Gi fails to advance.
The transactional processing is required in order to ensure consistency and do proper individual
rollbacks when certain ODE solver (due to Gi) can not advance to the desired time. It remains
to show why transaction i can ever fail (besides the obvious reasons, such as numerical problems
when penetration can not be avoided, for example). The reason is the need for simulation group
merging. Although force object targets can not change while advancing the simulation, new
geometry hull overlaps (and contacts) might emerge which requires the simulator to simulate the
corresponding bodies within a common group in order to produce consistent results.
To illustrate the problem, let us assume that we have two bodies A and B, so that the first
body belongs to G1 and the second body to G2 and the corresponding geometry hulls do not
overlap at time t. Now let us advance the simulation state. G1 is advanced first and while
advancing G1, it can happen that the geometry hull of A will overlap the hull of B. The trouble
is that when the overlap is detected, at time tcur = t, the geometry hull of A is valid with respect
to time tcur but the geometry hull of B is valid with respect to t, because G2 was not updated
yet. Even if we could merge the corresponding simulation groups straight in the middle of the
transaction so that we could handle the overlap (which we can not), potential contacts would
be inconsistent because they would be computed with respect to geometry states at different
times — hence the inconsistency. The (chained) transaction is thus aborted, the simulation state
restored to the state at time t, bodies merged to a common simulation group and the transaction
rerun.
Advancing Simulation Group
Simulation groups maintain lists of rigid bodies and force objects assigned to them so that
they could build the ODE that determines the evolution of the group in time and compute the
equation right-hand side (evaluate ODE state derivative) upon the request of the ODE solver
that is specific to the simulation group. A particular simulation group is then advanced in terms
of its ODE. We will now outline the steps taken by evaluate derivative,
• Collision detection is performed
Higher-level collision detection runs and the list of overlapping geometry hulls is updated.
New geometry hull overlaps among bodies from different simulation groups indicate that
the transaction should abort and bodies involved in the overlaps merged to common groups
(the evaluation of the ODE state derivative ends with a request to abort the transaction).