ure 1. The first point cloud, Chalmers, is a scan
of the Chalmers University of Technology in Swe-
den and contains 534 million points. The next point
cloud, Lab, is a scan of the production laboratory at
the Chalmers University of Technology and contains
100 million points. Both of these scans were made
using a FARO Focus 3D 120. The Chalmers scan
was put together from 21 separate scans from differ-
ent positions, and the Lab scan was put together from
11 scans. A fly-through of the Chalmers point cloud
is available on the web
2
.
The next point cloud is the publicly available
Tower data set by Borrmann et al. (2011), which
contains 152 million points. The remaining three
point clouds were created by extracting the vertices
from triangle meshes from the Digital Michelan-
gelo Project Archive (Stanford Graphics Laboratory,
2015). These three meshes—David, St. Matthew, and
Atlas—contain 28 million, 187 million, and 255 mil-
lion vertices, respectively. Each point cloud was pre-
processed into the binary xyz format to ensure consis-
tent access times over all cases.
The results from our experiments are shown in
Figure 2. Two plots are included for each input set,
the top one showing the average number of I/O trans-
actions performed per block for different memory
sizes, and the bottom one showing the resulting ex-
ecution times. The values of M are sampled start-
ing at 2
18
= B, and then increased by a factor of 2 in
each step until M ≥ n. This means that at the lowest
value of M, only a single block fits in memory, and at
the largest value, the whole point set fits in memory
(which leads to the plots converging at an I/O/block
of 1). Each plot includes Miniball, Algorithm 1, and
Algorithm 1 incorporating heuristics 1 and 2 (based
on conditions (2) and (3) from Section 3.3, respec-
tively).
4.1 Discussion of Results
Perhaps the most important statistic to consider is
the number of I/O operations performed by the al-
gorithms, as this is independent of the type of hard
drive used. For almost any value of M our algo-
rithm reduces I/O considerably over Miniball, up to
three times without the heuristics and up to six times
with the heuristics enabled. Furthermore, by using the
heuristics we achieve close to the optimal I/O of only
one read per block across all values of M. Miniball
requires fewer I/O operations as the memory size in-
creases, because more blocks can be cached between
passes in internal memory (as discussed above). Nev-
2
https://vimeo.com/117913688
ertheless, only at M ≈ n/2 does Miniball start to ex-
hibit competitive I/O and performance.
The basic version of Algorithm 1 performs be-
tween two and four I/O operations per block, indepen-
dently of the number of points. This is in accordance
with our speculation in Section 3.4 that the number
of visits of each block is within a constant factor of
d, and ultimately that the algorithm has a linear time
complexity in n for fixed dimension.
The better I/O performance almost directly trans-
lates one-to-one into faster algorithms. For example,
in the Tower and Chalmers cases, four times better I/O
results in roughly three times better runtimes. The
largest performance gains are seen for St. Matthew,
where the fastest heuristic is up to four times faster
than the Miniball algorithm. As the two heuristics ex-
hibit similar effect on I/O in general, we can see that
the first heuristic has a slightly larger overhead than
the second one. This stems from the relatively high
cost of invoking an additional full MEB computation
for each chunk.
5 CONCLUSION
In this paper we developed an algorithm aimed at effi-
cient out-of-core MEB computations. The presented
algorithm and additional heuristics were able to re-
duce the number of I/O operations by almost an order
of magnitude over a na
¨
ıve out-of-core implementa-
tion of (G
¨
artner, 1999). For our hardware setup this
resulted in up to four times better performance. Most
importantly, this could be achieved with only a few
megabytes of internal memory, which is beneficial for
memory-limited systems such as mobile phones, em-
bedded systems, etc.
In the first version of our algorithm, only the can-
didate support set is carried over between chunks
(apart from the candidate ball, which can be computed
from the support points), and this is arguably the min-
imum amount of information necessary to compute
an exact MEB. However, one can easily imagine diffi-
cult input cases, such as point sets having many points
close to the boundary of the MEB, for which this
strategy would be insufficient and would incur many
passes over the input. It is an interesting direction
for further studies to develop more sophisticated rep-
resentations that can handle such difficult cases ef-
fectively by keeping more information about visited
chunks in a memory-efficient way. Although compact
representations have been proposed for the computa-
tion of approximate MEBs (Agarwal and Sharathku-
mar, 2010), it is not clear that these can benefit exact
MEB computations.
An External Memory Algorithm for the Minimum Enclosing Ball Problem
89