Construction of Voronoi Diagrams

David Pritchard

April 9, 2002

1 Introduction

Voronoi diagrams have been extensively studied ina number of domains. Recent advances in graph-ics hardware have made construction of these dia-grams relatively cheap, for a limited set of appli-cations. In this paper, we discuss the implementa-tion of two Voronoi diagram construction algorithms.The first uses an algorithm introduced in [HKL+99],which finds a Voronoi diagram using standard poly-gon rasterization hardware. The second algorithm isthe classic O(n log n) sweepline approach introducedby Fortune. We restrict the problem to only considerpoint sites, not arbitrary line or polygonal sites. Thegoal is to compare construction times and implemen-tation issues for these two techniques.

2 Hoff’s Algorithm

Implementation of the hardware-accelerated algo-rithm from [HKL+99] proved quite straightforward.The approach is every bit as simple as the paper de-scribes, and required only about two hours to imple-ment. The algorithm was written in C++ using theOpenGL graphics library, and runs on Linux-basedPCs. The core algorithm required 300 lines of code.

As described in the paper, the graphics hardwareis set up with an orthographic projection where theviewer is at z = −∞ looking in the positive z direc-tion. Each site is rendered as a right cone, with thetip positioned in the z = 0 plane, and the circularbase in the z = 1 plane. Each cone is shaded uni-formly with a unique colour. The graphics hardwareuses a depth buffer to determine which cone is clos-est to the viewer at each pixel, leaving a discretized

Figure 1: An example of the mosaic effect.

representation of the Voronoi diagram in the frame-buffer. For a more complete description of this inter-pretation of the Voronoi diagram, refer to [GS87].

From there, it is easy to perform point-in-site tests,which can be done in O(1) time, although typicalgraphics hardware often has a high cost associatedwith framebuffer readback. Other operations whichare amenable to solution with graphics hardware canalso be done with reasonable efficiency—for example,the mosaic technique described by [HKL+99]. Anexample of this is shown in Figure 1.

For some applications of Voronoi diagrams, how-ever, this discrete representation is clearly unsuit-able. For example, if site connectivity informationis needed, then the discrete plot must be scannedusing image analysis techniques to obtain a conven-tional planar subdivision data structure. The timerequired for such an operation is much larger thanthe construction of the discrete diagram. It would be

1

interesting to see how such an approach would com-pare to a pure software algorithm, but this is beyondthe scope of this project.

As observed by [HKL+99], graphics fillrate is usu-ally the bottleneck in the performance of this algo-rithm. In situations where an upper bound on thedistance between points is known, the radius of thecone base can be reduced, which consequently re-duces the number of pixels that the graphics cardmust fill for each site. For example, if the sites arechosen from a uniform random distribution, then themaximum distance between points is likely to be rea-sonably small, saving substantial time. From my ob-servations, this is the single largest parameter affect-ing the algorithm’s speed. For a nonuniform ran-dom distribution of points, it could be valuable toadjust the cone size according to the probability den-sity function.

3 Fortune’s Algorithm

The software implementation of the Voronoi diagramproved much more challenging than anticipated. Thealgorithm follows the procedure given in [dBvKOS00]chapter 7, which provides a high-level overview of thenecessary work. Implementation was done in C++on a Linux-based PC. Approximately fifty hours werespent implementing and debugging the software im-plementation. The code directly related to the For-tune’s algorithm totalled 1600 lines.

3.1 Data Structures

The C++ Standard Template Library provides anumber of standard containers for structures such aslinked lists, arrays, sorted lists and heaps. It alsoprovides a few tree structures targeted at specific ap-plications, such as the set and associative array struc-tures. Some of these could be adapted for use in thisproject, but many new data structure classes neededto be written to accomodate my needs. The pla-nar subdivision representing the Voronoi digram wasstored in a doubly-connected edge list, as described in[dBvKOS00] chapter 2. In a postprocessing step, theinfinite edges of the Voronoi diagram were truncated

using a surrounding box.The beach line was stored in a binary tree, as de-

scribed by [dBvKOS00]. Since both internal nodesand leaves need to hold data, the STL map struc-ture (built upon a red-black tree) was not a feasiblechoice. Instead, a new binary tree structure had tobe written from scratch. At present, this has not yetbeen move over to a balanced binary tree format, sothe algorithm runs in O(n2) time, and not the desiredO(n log n) time.

The priority queue must be stored in a data struc-ture allowing efficient extraction of the minimum, butalso efficient insertion and deletion. The STL setstructure was chosen for this, since it supports thenecessary operations in O(log n) time.

3.2 Numerical Methods

A few numerical routines were also needed by the al-gorithm. Circle events require the determination ofthe position and size of the circle containing threepoints. This fit operation was performed by takingthe intersection of two bisectors, which proved ade-quate for the needs of the algorithm.

Calculation of the breakpoint between arcs re-quired a quadratic root solver. This is not difficult inprinciple, but numeric stability proved a little moreinvolved than anticipated.

3.3 Breakpoint Convergence

The algorithm presented by [dBvKOS00] is straight-forward, except for a few steps. The authors glossover the details of detecting whether or not twobreakpoints converge. For any triple of sites, thereare many different ways in which a circle event couldpotentially be added to the event queue. For exam-ple, suppose that the leaves of the beach front are< a, b, c, b, a > after site c is inserted. Then, two dif-ferent triples involving the same three sites are con-sidered for insertion into the event queue: < a, b, c >and < c, b, a >. If both are inserted, then both maylater be extracted from the queue and a duplicatevertex could be inserted into the planar subdivision,causing a breakdown in the algorithm.

2

In fact, one triple corresponds to the convergingbreakpoints, and the other triple corresponds to di-verging breakpoints. This convergence must be de-tected at insertion time, so that diverging break-points are rejected. Several different approaches wereattempted to detect convergence.

• Comparing breakpoint positions at the currentsweepline and a lower sweepline position. Specif-ically, a sweepline at the circle base was used.However, in situations where the middle site ofa triple is at the base of the circle, this approachfailed. It also seemed to have numerical prob-lems.

• Testing breakpoint and circle positions relativeto the sites’ positions. This approach took ad-vantage of the fact that a converging breakpointwill lie either to the right or the left of both ofits sites, and will be on the same side of the sitesas the circle centre. This also fails in situationswhere the middle site of a triple is at the baseof the circle. It seemed to have other sporadicproblems as well.

• Testing order of sites. For a triple < a, b, c >,test the two breakpoints < a, b > and < b, c >.For < a, b >, if site a is lower than site b, thenthe circle centre should lie to the right of a; if b islower than a, then the circle centre should lie tothe left of b. If this test fails, then the breakpointis divergent. This approach proved the most ro-bust, but has difficulty with the degenerate situ-ation where the sites are on a common horizontalline.

The final solution chosen is still not perfect. Formany larger diagrams with more than 50 sites, theapproach breaks down. It is not clear if the problemis numerical or algorithmic.

For more information, [GS87] was consulted, butdid not provide any further details. Fortune’s originalimplementation might prove useful for resolving thisproblem.

3.4 Planar Subdivision Construction

When a circle event occurs, two edges must be joined,and a third edge constructed. However, there are twodifferent ways in which the edges could be connected,and it was not clear how to choose between the twotypes. Again, several attempts were made before ar-riving at an acceptable solution.

• Constructing a line from the middle site to theleft site, and testing to see which side of the linethe circle centre lies on. This approach provedincorrect.

• Similar construction, but testing with the rightsite instead of the circle centre. This also provedincorrect.

• Testing breakpoint movement direction with adescending sweepline: either away from or to-wards the circle centre. The breakpoint move-ment corresponds to the opposite of the edge’sorientation. This technique is correct, but it isnumerically problematic to find two locations onthe line swept out by the breakpoint, especiallywhen a site is at the bottom of the circle.

• Examining order of sites in angular sweep aboutcircle centre, starting at middle site. If left site isfound first, choose one configuration; if right siteis found first, choose the other. This is correctand appears numerically sound.

The final choice of approach appears to work quitesuccessfully. With large numbers of sites, there aresometimes topological errors in the current imple-mentation, but this may be a problem with the break-point convergence test.

3.5 Degeneracies

The algorithm fails in many degenerate situations.Surprisingly, without substantial effort, it can handlemany degeneracies, including some situations wherethe highest two sites are on the same horizontal line,and the case where three sites are collinear. How-ever, many degeneracies cause still result in programfailure.

3

3.6 Final results

To test robustness, the program was fed a set of sites,each of which oscillated back and forth between twonearby positions at different rates. The program stillfails in a large fraction of such tests, due to remainingdegeneracy bugs, and problems in the convergencetest. For static site collections, the program worksquite reliably for small data sets, but bugs in theconvergence test make it less reliable as the numberof input sites grows. Given more time, these issuescould be resolved.

4 Comparison

Comparing the overall performance of the two ap-proaches is difficult. The hardware algorithm can ob-viously perform closest-site queries in O(1) time, butwould take a substantial hit for many other typesof queries. The software algorithm, on the otherhand, may need a relatively long O(n) time to per-form closest-site queries, but it can provide rich infor-mation about neighbouring sites. Furthermore, thesoftware Voronoi algorithm could be combined witha planar subdivision search data structure to provideO(log n) query time for closest-site queries.

A comparison of queries using either of these twoapproaches is like comparing apples and oranges.However, there is some value in comparing construc-tion times using each approach. This can at leastshow a lower-bound on the cost of either approach.For certain applications, particularly those runningat interactive rates, construction time is the bottle-neck, since relatively few queries are performed.

The comparison is a little biased, since the soft-ware implementation did not incorporate a balancedbinary tree. Consequently, the software implemen-tation runs in O(n2) time instead of the desiredO(n log n) time. However, we can get an optimisticestimate of the speed using a balanced tree by divid-ing the actual time by logn. This estimate is includedin the results table as the Software’ column.

The hardware implementation was set to a 512 ×512 grid with a maximum error of half a pixel and thelargest cones possible, making no assumptions about

Sites Hardware Software Software’10 4.3 ms 2.7 ms 1.2 ms10 4.3 ms 2.7 ms 1.2 ms25 9.9 ms 10.8 ms 3.4 ms25 9.9 ms 12.6 ms 3.9 ms50 19.1 ms 35.1 ms 9.0 ms50 19.2 ms 36.5 ms 9.3 ms75 28.5 ms 67.4 ms 15.6 ms75 28.6 ms 59.7 ms 13.8 ms

Table 1: Comparison of hardware and software imple-mentations, and an optimistic estimate of the speedof the software implementation using a balanced bi-nary tree.

the input data. Since the software implementationonly works correctly for a selected set of inputs, eightsets of working input sites were chosen and given toeach implementation. Since the operation of the al-gorithm is fairly fast, testing was done with 100 repe-titions of the data, then normalised to determine theaverage speed of each repetition.

The tests were run on a fast new machine, a Pen-tium 4 1.6 GHz processor with a GeForce3 graph-ics card. Results are shown in Table 1. For com-parison, on an older AMD K6-2 300 MHz computerwith a Matrox G400 graphics card, software speedwas about 15 times slower and hardware speed wasabout 4 times slower.

Note that this is a pessimistic conclusion for thehardware algorithm, since the cone sizes are pes-simistically large. As noted earlier, a substantialspeedup can be achieved by assuming uniform ran-dom distribution of sites and reducing the cone size.By using half the cone size, which is still pessimistic,speedups of about 35% were recorded. Likewise, byusing a grid size of 256×256, speedups of 140% wererecorded.

It is interesting to observe that the software algo-rithm is comparable to the hardware algorithm forup to 25 sites. Once the algorithm is modified to usea balanced binary tree, it may even be comparablein speed for up to 100 sites. For small numbers ofsites, the software algorithm is faster. Clearly, as thenumber of sites rises, the hardware algorithm will be

4

able to construct its representation of the Voronoidiagram faster, since it operators in O(n) time whileFortune’s algorithm is O(n log n).

In terms of accuracy, Hoff’s algorithm has a maxi-mum error of 2−9 in the location of the Voronoi ver-tices by the choice of rendering resolution. The ex-act error of Fortune’s algorithm is harder to quantify,but is at least as good as Hoff’s using single-precisionfloating point. A comparison of the output of the twoalgorithms confirmed this error analysis.

5 Conclusions

Using current hardware, Fortune’s algorithm can out-perform the Hoff’s discrete Voronoi diagram for situ-ations where there are less than 25 sites. In situationswhere the number of sites is low and speed is critical,Fortune’s algorithm is the best choice. However, thiscomes at substantial implementation cost: at least5 times as much code, and much more programmereffort. For situations where speed is not critical orwhere a large number of sites are needed, Hoff’s al-gorithm may be preferable.

References

[dBvKOS00] Mark de Berg, Marc van Kreveld, MarkOvermars, and Otfried Schwarzkopf.Computational Geometry: Algorithmsand Applications. Springer-Verlag,2000.

[GS87] Leonidas J. Guibas and Jorge Stolfi.Ruler, compass and computer: The de-sign and analysis of geometric algo-rithms. In Proc. the NATO AdvancedScience Institute, series F, vol. 40:Theoretical Foundations of ComputerGraphics and CAD, pages 111–165,Lucca (Italy), July 1987. Springer-Verlag. Invited paper.

[HKL+99] Kenneth E. Hoff III, John Keyser, MingLin, Dinesh Manocha, and Tim Cul-ver. Fast computation of generalized

Voronoi diagrams using graphics hard-ware. Computer Graphics, 33(AnnualConference Series):277–286, 1999.

5