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.
9.1. TESTS 113<br />
Figure 9.1: The illustration of the average constraint error at the carousel links. Different ODE<br />
solvers were used to integrate the equations of motion, the values of C i p due to PointToPoint<br />
constraints at the links measured each 0.1 seconds (= the time axis unit) and the average values<br />
plotted.<br />
attached to its construction is chosen to demonstrate the effects, constraint errors at the chain<br />
links measure the integration precision (the precision can be compared visually quite easily —<br />
the chain links either hold or the chain is broken). To stress the precision differences attained by<br />
the solvers, all position-level constraints Cp = 0 are implemented on the acceleration level only3 ,<br />
an integration error creeps into both ˙ Cp and Cp and it is nice to see how well the particular ODE<br />
solver performs to keep Cp and ˙ Cp at zero vectors.<br />
The tests are implemented by TestIntegrationPrecisionEuler, TestIntegrationPrecisionMidpoint<br />
and TestIntegrationPrecisionRungeKutta that use the corresponding ODE<br />
solvers (Euler, Midpoint, Runge-Kutta) to integrate the equations of motion. As can be seen by<br />
running the tests or looking at figure (9.1), Euler solver fails miserably. However when the constraints<br />
are implemented directly on the velocity level (contrary to the other tests), the method<br />
performs quite well — yet it is no wonder, because velocity-level constraints affect the states of<br />
constrained bodies directly, independently on the used integration method. In that case the only<br />
external force integrated by the Euler solver is the force due to gravity and so there is nothing<br />
to mess up. This is demonstrated by TestIntegrationPrecisionEulerVelocityLevel.<br />
Since the maximum time step sizes are currently determined by the upper velocity bounds<br />
of the bodies in the corresponding simulation groups (see page 79), the step sizes are often too<br />
limited, higher-order integration methods can not manifest their potential (the ability to take<br />
relatively large time steps with relatively small integration error) and the extra computational<br />
cost required to take a step is not balanced by the step size. That said, Euler solver is currently<br />
3<br />
By default, these constraints would be maintained on the velocity level at regular states (to stabilize the<br />
velocity level errors) and on the acceleration level otherwise.