Analysis of Collision Detection Algorithmsin Haptic Environments

Cody Narber and Zoran DuricDepartment of Computer Science

George Mason UniversityFairfax, VA 22030

Email: {cnarber, zduric}@gmu.edu

Abstract—The goal of this paper is to determine the appli-cability of collision detection packages for performing efficientcollision calculations in haptic simulations. In this work we focuson boolean collision detection algorithms, which returns true ifthere is a collision or false if there are no collisions. We considerseveral scenarios which differ in the number of objects per sceneand the number of vertices per object. We use graphical andstatistical techniques to analyze the performance of each packageand determine their usefulness in haptic simulations.

I. INTRODUCTION

Haptic devices generate vibration, force, or movement toprovide either proprioceptive or kinesthetic feedback to theuser [1]. Haptics provide the user with the sensation of touch-ing a virtual object by synchronizing the movement of thecursor on screen with the movement of the haptic end-effector.The end-effector is moved in real space by a robotic armthat is controlled through a series of motors [2]. To achievethe kinesthetic sensation, haptic force must be calculated andsubmitted to the device every millisecond [2,3].

Haptic devices have been used in virtual surgery applica-tions to simulate the sensation of cutting and touching differenttypes of human tissue [4] and to automate stroke rehabilita-tion [5]. They are used to augment virtual environments inwhich the patient must complete simple tasks. Typical hapticapplications are focused on point-object interaction, i.e. theend-effector is represented as a point in the virtual environ-ment that interacts with the virtual objects defined within thescene. Touching, grabbing, writing, and surgical scalpel cuttingapplications can utilize this approach effectively. However,point-object simulations limit the type of kinesthetic feedbackavailable, and are reminiscent of holding a pen and proddingall objects in the world; very little spatial information can becommunicated.

Point-object interactions are not sufficient for simulatingcomplex object interactivity where the contact area betweenobjects is large. Disassembly and assembly tasks are examplesdemonstrating the need for collision response calculations (seeFig. 1(b)). To simulate pushing of pins or locking of gears it isnecessary to find the colliding surfaces in order to generate theappropriate forces. Tool use is another area in which surfacecollision calculation is required. To properly simulate hittinga nail with a hammer, collision must be detected between thehammer’s head and nail’s head in order to generate accurate

(a) Hammer-Nail (b) M4 Field Stripping

Fig. 1. Examples of haptic simulations that require the use of collisiondetection packages

reactive forces and nail movement (see Fig. 1(a)).

II. BACKGROUND

Utilizing existing collision packages in haptic simulationdevelopment would provide a robust way to model object inter-actions. Several packages/libraries for collision detection havebeen published and made publicly available (SWIFT++[6],PQP[7], SOLID[8], DEEP[9]). Each of these packages canbe used to test for boolean collisions; however they each havedifferent characteristics (see Table I). Penetration depth (PD)and proximity are two examples of the queries that can bemade. Penetration depth query checks for collision, and willcompute the shortest distance vector needed for one object tomove so that the two objects will no longer be intersecting. Aproximity query will compute the minimal distance betweentwo objects that are not colliding. Using both Hooke’s Lawand PD, force effects can be generated; however, PD queriescan be very time consuming. When there are a lot of queriesbetween objects, the total time required may exceed the timeneeded for realistic haptic force responses (<1ms [2]).

The queries can be managed by the programmer explicitlyby directly querying two objects. The queries can also bemanaged by a scene that checks for any collisions betweenany objecst within the scene. Typically queries can either bedone on convex objects or objects represented as polygonsoups. A polygon soup is a collection of polygons that arenot represented as a coherent mesh, rather they are organizedinto some other data structure like a tree. Polygon soups canprovide fast calculations due to the reordering, however sinceit does not retain information about the overall object, thecollision can only be detected if the polygons are intersecting

978-1-4244-6509-5/10/$26.00 ©2010 IEEE

TABLE IDIFFERENCES AMONG COLLISION LIBRARIES

Query Query Type Object Type

DEEP Both Scene Convex

SWIFT++ Proximity Scene Convex

SOLID Both Both Convex

PQP Proximity Pairwise Polygon-Soup

(e.g. if one object is contained within another, the polygonswill not intersect, but the objects do; this would not beconsidered a collision using only polygon soups).

We tested performance of SWIFT++, PQP, and SOLIDin our haptic framework. DEEP was not tested since it isan extension of SWIFT++. A brief discussion of the testedcollision packages follows.

A. SWIFT++

SWIFT++ supports multiple types of collision queries in-cluding intersection detection, tolerance verification, exactminimum distance, approximate minimum distance, and dis-joint contact determination. In our experiments we only useintersection determination. SWIFT++ performs collision de-tection on convex shapes. In order to enable the use of non-convex shapes, SWIFT++ provides functions for decomposingarbitrary objects into convex components.

B. SOLID

SOLID requires convex objects for collision calculations.It does not provide support for object decomposition, andtherefore the programmer must explicitly provide convex parts.SOLID can either check for collisions in a scene, or it cancheck for collisions between pairs of objects. For our exper-iment, we are using pairwise queries. When scene checkingis used, object placement recall is available, which allows forfaster queries on objects that have not been modified sincelast check. SOLID makes use of multithreading, which can bebeneficial in multiple core systems.

C. PQP

PQP uses a polygon soups to represent objects. Objects inPQP are created as a set of triangles and oriented boundingboxes (OBB) for use in collision queries. PQP does not providea scene structure for object maintenance; therefore, all queriesmust be performed directly on pairs of objects.

III. EXPERIMENTAL DESIGN

We have designed a framework for haptic simulations thatintegrates the OpenHaptics Toolkit, OpenGL, and Qt GUIAPI. The three collision packages were integrated into thisframework for the experiment.

(a) Colliding State (b) Non-Colliding State

Fig. 2. Screen captures of the haptic program used in our experiments

A. Haptic Scene

Our haptic scene manages the objects, trajectories for forcecontrol, and haptic devices. Our scene provides the controlfor OpenGL and OpenHaptics rendering of all objects andcollision object/scene updating. The scene provides functionsfor querying various collision packages.

B. Collision Checking Scenarios

For this experiment, all static objects in the scene wereplaced equidistantly between the near and far cut-off planesalong the z-axis with random deviations in the XY plane. Anadditional object was added to the scene as the tool/primaryobject (PO, i.e. the object which the haptic is hold-ing/manipulating); every graphic update the PO would advancea finite distance along the z-axis so that in 1000 updates itwould reach the far plane and end the trial. The PO wasalways moved along the z-axis and as it moved along itspath it was randomly assigned some rotation. These settingswere used in all experiments. There were two free variables:the number of static objects in the scene and the numberof vertices per object. As the number of objects increased,the spacing between them shrank so that all objects could bevisible within the view frustrum. The number of vertices wasthe same in all objects including the PO.

The scene was integrated into a Qt widget, which was placedin the Qt window that allowed the user to set parameters beforebeginning the scenario (see Fig. 2). The user could set whichcollision package to check (PQP, SWIFT, SOLID), the numberof objects (5, 10, 20, 50), the number of vertices (8, 12, 36,324, 2916), the number of trials, and/or a pseudorandom seed(used for generating the displacement of static objects).

C. Experiment Trials

Once the user had chosen the testing parameters, the frame-work would create the convex objects and the scene, and startthe trial. In each step, it would then flush the Qt widget fordisplay, progress the PO, and call the appropriate proximityfunction to check for collisions. If a collision had occurred,the PO would be set to a new color to simulate a response,if no contact was detected, the color would be set back todefault. As soon as the collision response had completed, atimer would be started to begin the process again after amillisecond had elapsed. The process would repeat until all

TABLE IIMEAN RESPONSE TIMES FOR 20 SAMPLES/RUNS/TRIALS (MS), WITH 8

VERTICES EACH

Num Objects: 5 10 20 50

PQP 74.3 138.65 272.25 619.25

SWIFT 140.55 312.2 986.15 178.25

SOLID 35.15 48.45 57.1 139.7

TABLE IIISTANDARD DEVIATION OF RESPONSE TIMES FOR 20

SAMPLES/RUNS/TRIALS (MS), WITH 8 VERTICES EACH

Num Objects: 5 10 20 50

PQP 24.11 41.14 69.8 135.7

SWIFT 44.17 58.46 93.48 165.27

SOLID 26.48 26.34 35.92 36.64

TABLE IVMEAN RESPONSE TIMES FOR 20 SAMPLES/RUNS/TRIALS (MS), WITH 5

OBJECTS IN THE SCENE EACH

Num Vertices: 8 12 36 324 2916

PQP 74.3 131.4 261.45 270.6 724.1

SWIFT 140.55 160.55 125.3 NA NA

SOLID 35.15 46 55.4 74.8 138

TABLE VSTANDARD DEVIATION OF RESPONSE TIMES FOR 20

SAMPLES/RUNS/TRIALS (MS), WITH 5 OBJECTS IN THE SCENE EACH

Num Vertices: 8 12 36 324 2916

PQP 24.11 67.28 111.86 114.24 322.1

SWIFT 44.17 38.76 38.46 NA NA

SOLID 26.48 23.96 43.3 34.98 47.74

1000 updates had occurred, signifying the end of the run/trial.The next trial would begin with a new random placement ofthe static objects.

The time taken for haptic rendering, Qt rendering, andopenGL context switching is much larger than the time takenfor collision detection; therefore, time is captured at thebeginning and at the end of each collision query. The timetaken by the function was summed for all 1000 updates, whichconstitutes the response time of the trial. For each set ofparameters trials were repeated 20 times with varying objectplacement.

IV. RESULTS AND DISCUSSION

We analyzed the data to compare package performance andto determine statistical significance of the results.

In order to compare the performance of the three packages,both the means and standard deviations of running times arecollected. By inspecting the mean response times (see Tables IIand IV), it appears that SOLID is the best performing packageto use under any circumstances. The standard deviations areshown in Tables III and V. Note that SOLID uses multithread-ing and that the tests were done using a dual-core computer.SWIFT++ crashed the program when the number of vertices

Fig. 3. Normal Q-Q Plot sample: SOLID Test with 8 vertices per object, 50Objects

tested was 324. This error surfaced each time the test was run.It was run three separate times with three different randomseeds. SWIFT++ consistently crashed with higher number ofvertices as well. The cause is unknown and requires furtherinvestigation.

SWIFT++ had an interesting mean response time when thenumber of objects reached 50; Its computation time droppeddrastically from the 20 object scenario. Upon further review,the cause of the drop is most likely due to the PO’s collidingvs. non-colliding state change. In the 20 object scenario thePO was fluctuating very frequently between colliding and notcolliding, and in the 50 object scenario the PO was primarilycolliding. Since SWIFT++ is managed by a scene that recallsall object’s prior states; scenarios where the objects are notconstantly changing state will perform better. It is observedthat the 5 object and 50 object scenarios had similar numberof collision state changes and as such have similar responsetimes.

In order to determine if the data was statistically significant,95% confidence intervals were found. QQPlots were visuallyexamined to determine if the data was Gaussian [10]. TheQQPlots appear to be linear and thus distributions can beassumed to be Gaussian (see Fig. 3). Therefore, we can nowuse the t-statistic to compute the confidence interval:

[c1, c2] = µ± t[1−α/2,df ]s√n

By comparing the computed intervals we can conclude with95% confidence that SOLID performs better than all otherpackages in all cases but one. During the 50 object scenario,SOLID and SWIFT++ confidence intervals overlap (see Fig.4). Though SOLID performs better on average in this case,SWIFT++ outperforms SOLID on occasion depending on therandom placement of the objects.

To examine whether or not the differences between collisionpackage response times are due to errors in the experiment oractual differences between packages, one-factor ANOVA isemployed [10]. In order to use ANOVA the data distribution

Fig. 4. 95% Confidence Interval Sample: Test with 8 vertices per object, 50Objects, 1) PQP: square, 2) SWIFT++: diamond, 3) SOLID: triangle

must be Gaussian, and rather than relying on visual assessmentof QQPlots, the Pearson’s Chi-Squared Test will be employed.Twenty data points is too small for running the Chi-Squaredtest, so a single scenario is chosen and run 50 times for eachcollision package (10 objects with 8 vertices). Pearson’s Chi-squared Test uses counts in bins and relies on the central limittheorem. To determine the number of initial bins Sturges’Formula was applied: k = dlog2n + 1e, where k is thenumber of bins to use, and n is the number of samples. Ifa bin contained less than five samples, it was merged with theneighboring bin that had fewer samples in it. With the binsnow satisfying the central limit theorem, Chi-Squared Test canby applied to extract χ2. The results of Pearson’s Chi-squaredare shown in Table VI. The computed value is compared to thechi-squared distribution, if χ2 is greater than the chi-statisticthen the null hypothesis (that the data is normally distributed)is rejected. So in order for the data to be Gaussian χ2 shouldbe less than the chi-value.

Since χ2 is less than the chi-square statistic, the nullhypothesis will not be rejected. Thus all data distributions areGaussian and since each trial has no impact on the others,the data is independent. Thus, ANOVA can now be usedto compare the three packages. The results of running one-factor ANOVA on the 50 sampled data points are shown inTable VII. By dividing SSA by SST, we estimate that thepercentage of total variation that is due to the differencesamong packages is 80.78% and dividing SSE by SST, weestimate that the percentage of total variation that is due tonoise in measurements is 19.22%. The computed F-value islarger than the tabulated F-value which shows that the variationdue to real differences is statistically greater than the variationdue to errors. Therefore, SOLID’s performance is better dueto differences among the packages.

V. CONCLUSION

We tested three different boolean collision packages inour haptic framework: SOLID, SWIFT++, PQP. We have

TABLE VIRESULTS OF THE PEARSON’S CHI-SQUARED TEST

PQP SWIFT SOLID

Computed χ2 4.832456 1.336456 3.816604

Chi-squared statistic 5.991465 5.991465 5.991465

TABLE VIIANOVA COMPUTATIONS

Mean Square sa2 = 896439.7 se2 = 2902.397

Computed F sa2/se2 = 308.8618

Tabulated F F [0.95; 2, 147] = 3.057621

performed several experimental trials under various settings,and visually and statistically examined the collected data. Wehave shown that SOLID is the best performing package. This ispossibly due to SOLID’s implementation being multi-threaded,and our tests being performed on a dual-core system. The othertwo packages could be implemented using multi-threading,which may improve their performance. Note that SOLID andSWIFT only operate on convex parts, whereas PQP does notimpose any restrictions on object convexity. In future work,we will consider testing the packages on concave shapes. It ispossible that an adaptive algorithm that would switch amongcollision algorithms would provide the best performance.

VI. ACKNOWLEDGEMENT

This material is based upon work supported by the NationalScience Foundation under Grant No. CNS-0722575. Any opin-ions, findings, and conclusions or recommendations expressedin this material are those of the author(s) and do not necessarilyreflect the views of the National Science Foundation.

REFERENCES

[1] F. P. Brooks, Jr., M. Ouh-Young, J. J. Batter, and P. J. Kilpatrick. ProjectGROPE - Haptic Displays for Scientific Visualization. In Proc. ACMSIGGRAPH, pp. 177–185, 1990.

[2] B. Itkowitz, J. Handley, and W. Zhu. The OpenHaptics Toolkit: A Libraryfor Adding 3D Touch Navigation and Haptics to Graphics Applications.In Proc. First Joint Eurohaptics Conference and Symposium on HapticInterfaces for Virtual Environment and Teleoperator Systems (WHC’05),pages 590–591, 2005.

[3] K. J. Kuchenbecker, J. Fiene, and G. Niemeyer. Improving contact realismthrough event-based haptic feedback. IEEE Trans. on Visualization andComputer Graphics, 12:219–230, 2005.

[4] A. M. Okamura, C. Simone, and M. D. O’Leary. Force modeling forneedle insertion into soft tissue. IEEE Trans. Biomed. Eng., 10:1707–1716, 2004.

[5] Maureen K. Holden. Virtual environments for motor rehabilitation - Areview. CyberPsychology and Behavior, June 2005, 8:187–211.

[6] S. Ehmann, and M. C. Lin. Accurate and fast proximity queries betweenpolyhedra using convex surface decomposition. Computer Graphics Fo-rum (Proc. of Eurographics’2001), 20:500–510. 2001.

[7] E. Larsen, S. Gottschalk, M. Lin, and D. Manocha. Fast proximity querieswith swept sphere volumes. Tech. Report TR99-018, Department ofComputer Science, Univ. of North Carolina, Chapel Hill, 1999.

[8] G. van de Bergen. Collision Detection in Interactive 3D Environments.Morgan Kaufmann, San Francisco. 2004.

[9] Y. J. Kim, M. C. Lin, and D. Manocha. Incremental penetration depthestimation between convex politopes using dual-space expansion. IEEETrans. on Visualization and Computer Graphics, 10:152-163, 2004.

[10] G.W. Snedecor and W.G. Cochran. Statistical Methods. Iowa StateUniversity Press, 1989.