An Evaluation of Open Source Physics Engines for Use in Virtual Reality Assembly Simulations

An Evaluation of Open Source Physics Engines for Use in Virtual Reality Assembly Simulations Johannes Hummel1, Robin Wolff1, Tobias Stein2, Andreas Gerndt1, and Torsten Kuhlen3 1 German Aerospace Center (DLR), Germany {Johannes.Hummel,Robin.Wolff,Andreas.Gerndt}@dlr.de 2 Otto-von-Guericke University, Germany [email protected] 3 Virtual Reality Group, RWTH Aachen University, Germany [email protected] Abstract. We present a comparison of five freely available physics engines with specific focus on robotic assembly simulation in virtual reality (VR) environments. The aim was to evaluate the engines with generic settings and minimum parameter tweaking. Our benchmarks con- sider the minimum collision detection time for a large number of objects, restitution characteristics, as well as constraint reliability and body inter- penetration. A further benchmark tests the simulation of a screw and nut mechanism made of rigid-bodies only, without any analytic approxima- tion. Our results show large deviations across the tested engines and reveal benefits and disadvantages that help in selecting the appropriate physics engine for assembly simulations in VR. 1 Introduction The simulation of the kinematic and dynamic behavior of multi body systems is an important aspect in many interactive simulation and training applications. In recent years, a large number of frameworks have evolved that intend to bundle the algorithms and data structures required for computing the physics effects in a library so that they can be reused in several projects. Such physics engines stem from academic, commercial and hobbyist efforts. Some try to provide a set of common features to support a wide range of applications, such as games and animation, while others specialize on very specific application areas, such as deformable tissue simulation in surgical training applications. Often, this comes with a trade-off between number of supported features, performance and accuracy. The large number of available physics engines makes it difficult for an application developer to select an engine that suits best for a given project. The work presented in this paper was mainly driven by an ongoing project called VR-OOS (Virtual Reality for On-Orbit Servicing)[1]. Its goal is to develop an interactive application for the planning, training and analysis of on-orbit servicing tasks within a haptic enabled virtual reality environment used to train G. Bebis et al. (Eds.): ISVC 2012, Part II, LNCS 7432, pp. 346–357, 2012. c Springer-Verlag Berlin Heidelberg 2012 An Evaluation of Open Source Physics Engines 347 astronauts but also robot control. A fundamental feature is the real-time simulation of the realistic dynamic and kinematic behavior of satellite (and robot) components in various on-orbit servicing tasks. These include, for example, the removal of the protection foil (MLI - multi-layer insulation) from the satellite, operating lever switches, removing and inserting module boards using a bayo- net handle, and handling connectors and locking mechanisms. As opposed to games, where it is usually sufficient that results look plausible, for this training simulator high accuracy at interactive frame rates is crucial. The VR-OOS project currently uses Bullet Physics1 as the physics engine. Bullet was chosen due to its popularity in related projects and its open source license. During preliminary evaluations of the integrated simulation environment, however, there have been observations that the results of the physics engine tend to get unstable in certain scenarios. For example, a switch vibrated during and long after moving the switch, or rigid modules occasionally penetrated their shaft when pushing them in. Such effects are undesired, as they make the simulation environment appear unrealistic and may influence the training effect. Tweaking the engine’s parameters did lead to some improvements. However, it influenced stability in other scenarios. Consequently, we had to spend a considerable amount of time tweaking the parameters for every single mechanism for each occurring scenario. As scenarios are modified or combined to simulate a variety of assembly scenarios supporting various on-orbit servicing tasks this reduced the convenient utility of our simulation environment. Hence, we started an investigation to see whether there was an alternative physics engine that would fulfill our needs with generic parameters without scenario based, fine grained tweaking and set up a number of benchmarks specifically designed to test particular aspects of our application scenarios. 2 Related Work Seugling et al. [2] evaluated three physics engines (Open Dynamics Engine, AGEIA NovodeX, Newton Game Dynamics) and created nine benchmarks to test the energy preservation, constraint handling and collision detection of the engines. Their energy preservation test consisted of two parts, pushing a sphere slightly into a box and measuring the resulting forces, and shooting a sphere against a box and measuring the resulting velocity and direction. They used a fixed restitution coefficient of 1.0, which resembles a perfect rebound of the objects. Constraint handling was tested by monitoring how a constraint set up as pendulum was reacting on increased weight, and whether the engines could handle more than 20 chained constraints combined to a long pendulum. How- ever, it was not explored whether there was a correlation between these two tests. In order to investigate the scalability of collision contacts, they stacked up to 20 boxes on top of each other and measured the impact on computation performance of each engine. In practice, however, for an assembly simulation the physics engine usually has to handle more than 50 and more objects. Thus a 1 Bullet Physics Engine: http://bulletphysics.org 348 J. Hummel et al. scalability test should have been realized with at least 100 objects to challenge the collision detection of the physics engines. A similar work by Boeing et al. [3] presented a qualitative evaluation of freely available physics engines. With seven physics engines (Open Dynamics Engine, AGEIA NovodeX, Newton Game Dynamics, Tokamak, True Axis, Bullet Physics and JigLib) they ran several tests measuring the integrator performance, the material properties, the constraint stability and the performance of collision detection. Integrator performance was measured based on accuracy only. The speed was not measured. For measuring the stability of the constraints they used a chain of spheres connected to each other. They mounted both sides of the chain to fixed points. They also varied the number of the spheres in the chain. The behavior of the engines with different weights of the spheres was not tested. Collision detection performance was measured by stacking about 20 boxes, too. Both papers provided valuable information on the generic performance of the then popular physics engines. Nevertheless, we needed an evaluation of up-to- date engines and with more focus on our specific requirements. 3Benchmarks Our overall requirements on the physics engine could be divided into five aspects. Firstly, the physics engine had to be able to detect collisions between objects of relatively large numbers (approx. 250 to 500 objects). The detection of collisions is a fundamental part of physics simulation. This had to be performed at interactive frame rates - with today’s common display refresh rates of 60Hz, this means within approx. 16ms, which even goes to 1kHz or 1ms respectively when integrating haptic feedback. Secondly, the computed responses of dynamic objects to collisions had to result in realistic behavior. For example, a rigid object colliding with a hard surface should bounce back with high velocity, while when colliding with a soft surface should bounce with little velocity only. Thirdly, constraints, which limit the degree of freedom of movement of an object with regard to another object, should obey their defined limits and not diverge from them. For example, a switch should only rotate around its single rotation axis and not any other axis. Neither should it move along any translational axis when pushed from the side. Furthermore, rigid bodies should not inter-penetrate each other. When a satellite module is pushed into its module shaft, for example, it should only move along the contact plane within the shaft, but not move through the walls or get pushed through the end. Finally, we needed the physics engine to support the realistic simulation of a screw mechanism. This required the stable computation of both collision and friction for complex geometric objects. This section outlines the design of a number of benchmarks intended to test the five requirements mentioned above. The first three are broadly based on benchmarks in related work and test the performance and accuracy of more generic features. The benchmarks four to six were designed to test particular features that are specific to our on-orbit servicing simulation and training application. An Evaluation of Open Source Physics Engines 349 3.1 Collision Computation Performance The first benchmark was designed to test the performance and scalability of collision detection with a large number of rigid objects. It was closely based on those tests in related work and consisted of a simple physics scene with a specified amount of equal objects (1 to 2500) placed in a three-dimensional grid along x, y, z axes floating above the ground, see Fig. 1. In contrast to related work, we used spheres instead of boxes, as these are the simplest three-dimensional

Load more