coordinates and the vertex elevations. For each trian-
gle t, we encode the indexes of the three vertices of t
(Triangle-Vertex (TV) relation), and the indexes of the
three triangles adjacent to t along an edge (Triangle-
Triangle (TT) relation), ordered consistently with the
information in TV relation. For each vertex v, we en-
code the index in the triangle array of one of its inci-
dent triangles (partial Vertex-Triangle (VT) relation).
This is sufficient to retrieve all the triangles incident
in a vertex v, in time linear in their number.
For encoding the structure of the spatial index,
we do not explicitly represent the quaternary tree that
describes the PM2T-quadtree through all nodes and
their parent-child pointers, but we encode only the
leaf nodes and their location codes. The location code
(Gargantini, 1982) of a leaf n describes the position
of n in the tree by means of the root-to-leaf path tra-
versed to reach it. Thus, for every leaf node, we store
its location code and an integer number, which al-
lows distinguishing among different types of leaves,
as well as retrieving the information (vertex and tri-
angles) possibly associated with such leaf. We have
the following types of leaves:
• An empty leaf is identified by the value −1.
• For a leaf block intersected by three or more tri-
angles, sharing a vertex v (that can be internal or
external to the block), we store the index of v. Tri-
angles are not explicitly stored since they are re-
trieved by using topological relations.
• For a leaf containing one triangle t, we store
a negative even integer content = −2(t + 1),
from which we can retrieve the index of t as
−(content/2) −1.
• For a leaf containing two triangles t
1
and t
2
, we
store a negative odd integer content = −2(t
1
+
1) + 1, if this quantity is different from −1 (al-
ready denoting an empty leaf); otherwise, it is
equal to the result of the same expression with t
2
instead of t
1
. The two triangles can be retrieved
one as ((1−content)/2) −1, and the other one as
its adjacent triangle which intersects the leaf.
We denote with N the number of vertices of the
triangle mesh, with T the number of its triangles
and with L
N
the number of leaf nodes in the PM2T-
quadtree. We consider every base type element (in-
tegers and pointers) to have a unit cost. The cost of
encoding the vertex coordinates and elevation values,
and the partial VT relation is equal to 4N, while the
cost of encoding the triangle array, i.e., the TV and
TT relations is equal to 6T . Finally the cost of encod-
ing the tree structure is equal to 2L
N
. This leads to
4N + 6T +2L
N
stored information items.
Note that 4N + 6T is the space required for rep-
resenting just the triangle mesh in a triangle-based
data structure, while 2L
N
expresses the overhead of
the spatial index. From Euler formula, T ' 2N. From
our experiments, L
N
is about 6N on average for syn-
thetic data, and about 5N for real data (see Section
4). Thus, the additional memory needed by the spa-
tial index is from 63% to 75% the memory required
for storing the triangle mesh itself.
4 ANALYSIS
We compare the PM2T-quadtree with other two spa-
tial indexes: the PM2-quadtree (Samet, 2006) for
polygonal maps, which can be used for a triangle
mesh as well, and an extension of the PR-quadtree
to triangle meshes.
We evaluate the space subdivision generated by
the different spatial indexes, the storage costs of
the data structures, and the performance on spatial
queries. The main requirement for a spatial in-
dex is to perform spatial queries efficiently, while
a low overhead of the data structure is desirable as
an additional requirement. Experiments show that
the PM2T-quadtree outperforms the other considered
spatial indexes in queries, and the proposed data stuc-
ture makes it compact enough.
We present results on synthetic data (De-
launay triangle meshes built on randomly gen-
erated point sets) and on triangulated mod-
els from the AIM@SHAPE shape repository
(http://shapes.aim-at-shape.net/): City of
Rome (957,456 vertices, 1,914,867 triangles), and
Dolomites mountains (810,000 vertices, 1,619,963
triangles).
4.1 Other Spatial Indexes
The PM2-quadtree belongs to the class of PM-
quadtrees (Samet, 2006) developed for polygonal
maps. In a PM2-quadtree, a leaf block contains at
most one vertex. If a leaf block contains a vertex,
it may intersect only edges incident in such vertex.
If a leaf block contains no vertex, it may intersect
only edges that meet a common vertex exterior to the
block. Each leaf has a list of edges intersecting it.
A PM2-quadtree, applied to a triangle mesh, rep-
resents the edges and not the triangles. The data struc-
ture we have implemented for the PM2-quadtree is
slightly different from the one described in (Samet,
2006). The vertices and edges of the map are stored
in a vertex array and an edge array, respectively. For
each vertex, we store its coordinates and elevation
value, and, for each edge, we store the indexes of its
GRAPP 2008 - International Conference on Computer Graphics Theory and Applications
88