thesis - Computer Graphics Group - Charles University - Univerzita ...
thesis - Computer Graphics Group - Charles University - Univerzita ...
thesis - Computer Graphics Group - Charles University - Univerzita ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 7<br />
Simulator<br />
This chapter is devoted to a brief description of concept abstractions in the simulator and an<br />
overview of the simulator implementation — the goal is to provide the reader with a global view<br />
of the simulator but not to pursue the implementation details. The details are nicely documented<br />
in the Reference Guide, that comes with this <strong>thesis</strong>. We will also attempt to avoid the repetition<br />
of various topics already discussed in the previous chapters where appropriate (such as notes on<br />
computational/numerical issues), because the discussions can be found there, as well as in the<br />
Reference Guide.<br />
The simulator implementation is more or less based on the notes from the previous chapters,<br />
but as one could expect, many concepts have to be implemented in a more sophisticated way<br />
and smart algorithms have to be used in order to achieve an interactive performance (yet the<br />
notes should be sufficient to implement a functional simulator). Although these aspects can be<br />
characterized as “implementation details”, insignificant from the point of the rigid body dynamics<br />
theory, this is what makes the implementation quite involved and distinguishes a practical<br />
simulator from a toy. Certain implementation tricks were adopted from [22].<br />
For example, conditions on λ multipliers due to constraints were formulated in terms of dense<br />
matrix A from equation (6.8), but equation (6.9) needs be exploited in the practice. As another<br />
example, all bodies were simulated in terms of a single equation of motion, but it might be<br />
desirable to partition bodies to distinct simulation groups so that each group could be handled<br />
separately (so that when a particular group was being advanced the other groups could remain<br />
idle and would not have to be updated). For example, its ODE might be integrated with a<br />
different time step, using a different integration method or precision. If all bodies in the group<br />
are “at rest”, the simulation group could be skipped while advancing the simulation state, which<br />
could significantly decrease the processing time when handling complex scenes, etc.<br />
We will now present the main simulator components, outline the way the components collaborate<br />
and describe the improvements over the notes from previous chapters, noting that details<br />
can be found in the Reference Guide.<br />
7.1 Overview<br />
The rigid body simulation is represented by Simulator class that maintains a list of registered<br />
bodies, their separation to disjoint simulation groups simulated in terms of their own equations of<br />
motion and a list of force objects representing explicit interactions among bodies. The idea is to<br />
keep bodies that might influence each other in a common simulation group while bodies that can<br />
not influence each other in distinct groups so that the groups could be simulated independently<br />
89