Discrete volumetric datasets are often modeled as polyhedral meshes where scalar values are associated with the vertices of the mesh. Due to the increasing sizes of volumetric datasets, a multiresolution model is often used, thus creating a hierarchical spatial decomposition on the vertices of the mesh. Decompositions based on nested cubes, known as octrees, are popular for modeling 3D scalar fields as they allow one to focus resources on regions of interest within the dataset, while aggregating the less relevant regions into larger blocks. However, an oc-tree partitioning may introduce cracks into the scalar field representation. Additionally, variable-resolution representations extracted from octrees have limited adaptability in that each cubic block is replaced with eight new cubes. Longest edge bisection (LEB) hierarchies were introduced as a multiresolution modeling scheme over regular grids to increase adaptability while enforcing crack-free, or *conforming*, modifications to the model. However, this adaptability increases the number of modeling primitives at full resolution where each cube is replaced by six tetrahedra. This problem is mitigated by aggregating the set of tetrahedra involved in each modification to the mesh into a modeling primitive called a *diamond*. The regularity of the decomposition and the structure of the mesh enables implicit encodings for both the hierarchical and geometric relationships among the diamonds in the hierarchy.

Here, we propose the *supercube*, a high-level primitive for the edges of an LEB hierarchy. A supercube is a structured set of edges within an LEB hierarchy that captures the intrinsic symmetry of the model. Whereas previous representations contain several congruence classes of tetrahedra or diamonds, each with different geometric alignments, supercubes are all identical (up to scale). Diamonds and supercubes are related by a one-to-one correspondence from the longest edge of a diamond to a supercube edge. Thus, the set of edges in a supercube corresponds to all distinct *types* of diamonds within the hierarchy.

Many operations on LEB hierarchies apply to only a sparse subset of the tetrahedra within the hierarchy. For example, in isosurfacing applications, we are only interested in the subset of tetrahedra that intersect the isosurface. Similarly, large regions of a domain are often oversampled due to the use of a regularly sampled representation. However, implementations of these LEB hierarchies have mostly focused on efficient representations for the entire hierarchy, where the tetrahedra are implicitly indexed. We propose the use of supercubes as containers for data associated with coherent subsets of the elements within an LEB hierarchy. Since this clustering incurs overhead related to the storage of explicit spatial indexes, we consider the number of encoded diamonds with respect to an encoding of the full hierarchy, as well as the number of elements associated with each cluster. We demonstrate the effectiveness of supercubes as a multiresolution model for complete, or sparse volume datasets.

The remainder of this paper is organized as follows. We review related work and the longest edge bisection model in Sections 2 and 3, respectively. In Section 4, we introduce the supercube primitive, while, in Section 5, we discuss efficient encodings for supercubes. In Section 6, we discuss an application of supercubes to the encoding of multiresolution models of 3D scalar fields, while in Section 7 we discuss an efficient encoding of the mesh extracted though selective refinement. We present experimental results in Section 8. Finally, we draw some concluding remarks in Section 9.

Multiresolution tetrahedral models for 3D scalar fields based on longest edge bisection (LEB) were introduced for domain decomposition in finite element analysis [10], [17], [22], and have been applied in several contexts, including scientific visualization [31], [23], [6], [8], [16], [25], surface reconstruction [18] and volume segmentation [12].

The containment hierarchy among the tetrahedra in an LEB mesh induces a natural tree representation, in which the nodes are tetrahedra and the two children of a tetrahedron *τ* are the tetrahedra generated by bisecting *t*. If the tree is encoded using an array, the parents and children of a tetrahedron can be implicitly determined by their array indices. This representation is used in [31], [7], [6], [13], [8], [16].

LEB meshes can be non-conforming and, thus, can generate isosurfaces with cracks. This problem can be avoided by simultaneously subdividing all tetrahedra sharing that edge. This can be performed through neighbor finding algorithms [10], [17], [13] or through a precomputed saturated error which implicitly forces all longest edge neighbors to split [7], [6].

An alternative approach is to directly encode the cluster of tetrahedra sharing a longest edge [2], [8], [9], [26], [28]. Gregorski et al. [8] denote such a primitive as a *diamond*, and propose an implicit representation for the spatial and hierarchical relationships of a diamond based on its level, orientation and position. In our implicit diamond representation, the level and orientation can also be derived from the position of the diamond. The diamond paradigm has been generalized to higher dimensions in connection with adaptive mesh generation [19]. A decomposition of an arbitrary dimensional diamond into a pair of axis-aligned hypercubes is introduced in [28] to yield an implicit representation for diamond-based LEB hierarchies over regular grids.

All the above methods exploit the regularity of the data distribution by encoding the multiresolution model as a regular grid where all vertices are present. They are thus only efficient for representing a complete LEB hierarchy of dimensions (2^{N} +1)^{3}. However, many operations on LEB hierarchies pertain to only a subset of the tetrahedra. To the best of our knowledge, methods to encode an incomplete LEB hierarchy have only been proposed in 2D for terrain modeling [5], [27]. The former representation [5] uses variable-length pointers to encode the number of containment hierarchy nodes that are skipped when a node is not refined. The latter representation [27] uses a similar clustering strategy to the one presented in this paper for encoding an incomplete hierarchy of 2D diamonds at multiple resolutions.

There have been many proposed optimizations to enable interactive visualization of LEB hierarchies including frame-to-frame coherence [3], [8], parallel rendering [7], front-to-back sorting, view-dependent rendering [16], tetrahedral stripping [20], and chunked updates [9], [1]. Since our model is based on the same hierarchies, these optimizations can be easily incorporated into our pipeline.

Octrees are another popular family of spatial data structures used in visualization [29], [4], [21], [11], [24]. The subdivision rule for an octree node *n* with side length ℒ, is to replace *n* by its 8 children, each with side length *ℒ/*2. Since LEB hierarchies extract conforming meshes, they are more closely related to restricted octrees [29], [24] where neighboring nodes can differ by at most one level of resolution.

SECTION 3

## Longest Edge Bisection and Diamond Hierarchies

In this Section, we review hierarchical spatial decompositions of the domain of a 3D scalar field based on the longest edge bisection operation applied to a tetrahedral mesh partitioning the domain.

A mesh in which all cells are defined by the uniform subdivision of a cell into scaled copies is called a *nested mesh*. A special class of nested meshes are those generated by bisecting tetrahedra along their longest edge, which we denote as *Longest Edge Bisection (LEB) meshes*. The *bisection rule* for a tetrahedron τ in such a mesh consists of replacing **t** with the two tetrahedra obtained by splitting τ along the plane defined by the middle point of its longest edge e and the two vertices of **t** not adjacent to **e**. When this rule is applied recursively to an initial decomposition of a cubic domain Ω into six tetrahedra sharing a diagonal of Ω, it generates three congruent *classes* of tetrahedra, each with a single longest edge. We denote the tetrahedra congruent to those sharing a diagonal of the base cube as 0 *-tetrahedra*. Tetrahedra congruent to those obtained by splitting a 0-tetrahedron are denoted as 1 *-tetrahedra* and have a longest edge aligned with a face diagonal of the base cube. Finally, 2 *-tetrahedra* have a longest edge aligned with an edge of the base cube and are congruent to those obtained by splitting a 1-tetrahedron. Tetrahedra obtained by splitting a 2-tetrahedron are congruent to 0-tetrahedra.

Applying the longest edge bisection rule to tetrahedra does not generate conforming meshes. Thus, we consider a clustering of the tetrahedra that need to be subdivided concurrently. Given an LEB mesh Σ, the set of tetrahedra sharing a common longest edge forms a *diamond*, which we denote as *δ* . The longest edge of *δ* is called its *spine*. Since all tetrahedra within a diamond share their spine, they all belong to the same class of tetrahedra. As a consequence, there are three congruence *classes* of diamonds: those with spines aligned with diagonals of an axis-aligned cube (*0-diamonds*), with face diagonals of such a cube (*1-diamonds*) or with edges of such a cube (*2-diamonds*). An *i*-diamond, for *i* ∈ {0, 1, 2} is formed by {6, 4, 8} tetrahedra, and contains {8,6,10} vertices, respectively Figure 1 illustrates the three diamond classes and highlights their spines (black edges), parents (hollow gray vertices) and children (red vertices).

A diamond *δ* is subdivided by bisecting all of its tetrahedra according to the longest edge bisection rule, thus doubling the number of tetrahedra within *δ*. We note that all changes to the LEB mesh Σ due to the subdivision of a diamond *δ* occur within the interior of the domain of *δ* and, thus, the vertices, edges and faces on the boundary of *δ* are unaffected by its subdivision. The local effect of such a subdivision is to remove its spine, to add a vertex at the midpoint of its spine, which we denote as the *central vertex* of the diamond, and to add edges from the central vertex to all other vertices of *δ*.

Let us consider the collection Δ of all the diamonds associated with the longest edges of the tetrahedra *T* arising from longest edge bisection to a cubic domain Ω. The containment relation between the tetrahedra in *T* induces a parent-child dependency relation over the diamonds in Δ. A diamond *δ*_{p} is a *parent* of another diamond *d*_{c} if and only if some tetrahedra in *δ*_{c} are created by the splitting of at least one tetrahedron in *δ*_{p}. If *δ*_{p} is a parent of *δ*_{c}, then *δ*_{c} is called a *child* of *δ*_{p}.

The set Δ with the parent-child dependency relation defined over Δ can be easily shown to define a partial order relation and thus it can be described as a Directed Acyclic Graph (DAG) (see [2] for a proof), whose nodes correspond to diamonds, and whose arcs are defined by the parent-child dependency relation between diamonds. We call the resulting model a *Hierarchy of Diamonds (HD)*. Due to the regularity of the vertex distribution and the subdivision rule, the DAG associated with D has a fixed structure. Thus, with the exception of diamonds whose spines lie on the domain boundary, {0,1, 2} diamonds always have {3, 2, 4} parents and {6, 4, 8} children, respectively.

Since we employ longest edge bisection as the subdivision operation, and diamonds are defined by their spine, it is useful to consider the spatial and hierarchical relationships among the edges of an LEB hierarchy. An analysis of this structure reveals a higher level of symmetry within the hierarchy than that which is apparent at the level of diamonds (see Figure 3). Specifically, each level of resolution is tiled by a repeating pattern of edges arranged in a cubic domain, which we call a *supercube*.

Supercubes can be defined constructively by their set of edges. If we consider an empty cubic domain, the edges of a supercube *σ* are formed by

the edges joining the center of the cube to its eight corners (see Figure 2a),

the edges joining the center of each of the six faces of the cube to each of the four face corners and to the center of the cube (adding thirty additional edges, see Figure 2b), and

the edges joining the midpoint of each of the twelve edges of the cube to the two closest cube corners, the two closest face centers and to the cube's center (adding 60 additional edges, see Figure 2c).

To ensure that each edge in an LEB hierarchy is only associated with a single supercube, we adopt the common convention used for octrees [24] that a supercube uses *half-open* intervals, i.e. it contains all internal edges as well as the edges on its lower boundaries but not the edges on its upper boundaries. Thus, we consider any edge of a supercube *s* whose endpoints are both on an upper boundary of *s* to belong to a neighboring supercube. Of the 98 edges introduced above, a supercube only contains the 56 edges that satisfy the half-open criteria and consists of: 8 cube diagonals, 24 face diagonals and 24 cube edges. This is illustrated (in 2D) in Figure 3 at three consecutive levels of resolution, where the solid lines are supercube edges, while the dashed lines on the upper boundaries indicate edges belonging to neighboring supercubes due to the half-open interval rule.

The one-to-one correspondence between edges of an LEB hierarchy and the spines of diamonds provides a unique association from each diamond to a single supercube. This correspondence enables the use of supercubes to associate information with a coherent subset of the diamonds while minimizing the geometric overhead required to access this information. This is facilitated by an efficient encoding for supercubes, as described in the following Section.

SECTION 5

## Encoding Supercubes

In this Section, we discuss an encoding for supercubes within a hierarchy of diamonds D built on a grid with (2^{
N} + 1)^{3} points. We assume that all vertices of the diamonds in D have integer coordinates in the range of [0 *..*2^{
N}].

### 5.1 Encoding diamonds

Due to the one-to-one correspondence between diamonds and grid points, a diamond *d 2* D can be uniquely indexed by its central vertex. We consider the binary representation of the coordinates *v*_{x} *v*_{y}and *v*_{z} of central vertex v_{c} as
TeX Source
$${\bf{v}}_c = \left[\matrix{ v_x = x_1 x_2 \ldots x_m d_{x_1 } d_{x_2 } 00 \ldots 0 \hfill \cr v_y = y_1 y_2 \ldots y_m d_{y_1 } d_{y2} 00 \ldots 0 \hfill \cr v_z = \underbrace {z_1 z_2 \ldots z_m }_{\rm{\sigma }}\underbrace {d_{z_1 } d_{z_2 } }_{\rm{\tau }}\underbrace {00 \ldots 0}_{\rm{\gamma }} \hfill \cr} \right]$$
The *scale γ* of a diamond *δ* is the minimum of the number of trailing zeros among its three coordinates. Thus, in any diamond *δ* at scale *γ*, the rightmost *g* bits in each of *v*_{x} *v*_{y} and *v*_{z} are zero, but at least one of the bits at position *γ* + 1 (i.e *d*_{x}
_{2} *d*_{y}
_{2} or *d*_{z}
_{2} in Equation (1)) is nonzero. The *level* of a diamond *δ* at scale *γ* is *,* = *N − γ*, and equals the number of *i*-diamond ancestors of *δ* in the DAG, i.e. its depth in the DAG modulo 3.

The two bits at positions *γ* + 1 and *γ* + 2 in each coordinate of **v**
_{c}encode the diamond *type τ*. Since the type *τ* is encoded using 2 bits in each dimension, there are 4^{3} = 64 possible values for *τ*. However, the definition of *γ* precludes the eight cases where *d*_{x}
_{2} *d*_{y}
_{2} and *d*_{z}
_{2} are all zero. Thus, there are 56 valid diamond types, each corresponding to a distinct supercube edge. Finally, the number *i* of zeros at position *γ* + 1 of **v**
_{c} encodes the congruence *class* of *δ*.

The final *m* = *N −* (*γ* + 2) bits in each of the coordinates encode the *origin* of the supercube *σ* containing *δ*, i.e., its lower-left corner. Since there are no restrictions on the values of these bits, the origins of supercubes at a fixed level of resolution *ℒ*,= *m* + 2 are points on a regular 3D grid that have been scaled by a factor of 2^{γ+2}. Note that scale, type and supercube origin can be efficiently extracted from the binary representation of the central vertex of a diamond through bit shifting operations. Supercubes contain all unique *types* of diamonds within an LEB hierarchy, since the type *τ* of a diamond *d* is determined by the supercube edge with which its spine coincides. Thus, a diamond's type *τ* encodes the scaled offset of its central vertex from the supercube origin. i.e **v**_{c} = *σ* + (*τ ! γ*), where '!' indicates a component-wise bit shift operation (see Figure 4).

### 5.2 Internal map of a supercube

Since supercubes are intended to efficiently encode information with a subset of the diamonds of an LEB hierarchy, they require some form of bookkeeping to index the encoded diamonds.

A simple approach would be to encode this data as an array with one entry for each of the 56 possible diamonds in the supercube. The data associated with each diamond is then indexed by its type *τ*, and unencoded diamonds are marked in place as missing. However, this can waste a considerable amount of storage for supercubes with many unencoded diamonds.

A more efficient approach for static representations is to index the encoded diamonds using a bitflag of 56 bits (i.e. 7 bytes) along with a corresponding array with storage only for the encoded diamonds. The data associated with a diamond of type *τ* is indexed in the array by the prefix sum of *τ* in the bitflag. Since prefix sum computations can be performed efficiently in hardware, the processing overhead of this representation compared to that of the simpler encoding above is negligible. Each supercube in this representation incurs a fixed storage overhead, regardless of the number of diamonds encoded. Thus, the overhead of this representation is reduced as the average *concentration* of encoded diamonds per supercube increases.

Since this bitflag representation requires a reorganization of the array data every time a diamond is added or removed, we use the array representation during the initial generation of the data, and convert to the bitflag representation immediately thereafter.

### 5.3 Encoding collections of supercubes

We observe that within a given level of resolution *ℒ*, supercubes can be uniquely indexed by their origin. However, supercubes from different levels can map to the same origin (see Figure 3).

We propose a two step access structure, where supercubes are first indexed by their level of resolution, and then by their origin. This also enables the level ℒ, of a supercube to be implicitly encoded within the access structure.

The encoded supercubes at a given level of resolution *ℒ* belong to a uniform grid that has been scaled by a factor of 2^{
γ}+2. Thus, depending on the data distribution, we have several options for access structures to the supercubes. When the majority of the data within a given level is present, the supercubes can be indexed using a full array. However, most of the time, this will not be the case. An MX-Octree [24] is a hierarchical spatial access structure defined on grids where data is only associated with the leaf nodes of the complete tree, and adjacent unencoded elements can be aggregated to reduce the wasted space. The advantage of such a structure for supercubes is that the higher levels of resolution contain fewer elements, and enable quicker access. A third option is to organize the supercubes in a hash table to provide *O*(1) access.

Thus, the data associated with a diamond *δ* with supercube origin σ, type τ and scale γ can be accessed in three steps. First, the set of supercubes at level ℒ, = *N −* (γ + 2) is located. Next, the supercube *s* within this set is found. Finally, the data at location *τ* within σ is found using the internal map of σ.

### 5.4 Extension to higher dimensions

A closer inspection of Equation (1) reveals that supercubes can be defined in a dimension-independent manner. Thus, the binary representation of the central vertex provides all information for retrieving geometric and hierarchical information as in the 3D case. Consider a regular grid in a *d*-dimensional cubic domain with (2^{
N} + 1)^{
d} vertices. With the exception of the 2^{
d} vertices at the domain corners, each vertex corresponds to the central vertex of a *d*-dimensional diamond.

The *type τ* of a diamond *δ* at scale *g* is thus encoded by the two bits at positions *γ* + 1 and *γ* + 2 in the binary representation of the central vertex of *δ* . There are four possible values for each of the *d* components of *τ*, and thus, 4^{
d} possibilities for *τ*. The values at position *g* + 2 are unrestricted, but the definition of diamond scale invalidates any case where all the bits at position *g* + 1 are zero. Since there are 2^{
d} such cases, there are (4^{
d} − 2^{
d}) valid *d*-dimensional diamond *types*.

Similarly, since the *class* of a diamond is encoded within the diamond type *τ* by the number of zeros in the lower bit of each component, we can determine the number of distinct diamond types in each class in *δ* dimensions. Since there are (_{i}^{d}) combinations of *i* zeros in the *d* lower bits, and 2^{
d} arrangements in the upper bits of *τ*, there are 2^{
d} (_{i}^{d}) distinct types of *i*-diamonds in dimension *d*, for 0 < *i < d*.

SECTION 6

## Diamond-Based Multiresolution Volumes

One of the primary visualization applications of diamond hierarchies has been as a multiresolution model for a volume dataset defined at the vertices of a regularly sampled scalar field *F*. We call this model a **D**iamond-based **M**ultiresolution **V**olume (DMV).

A multiresolution model [2], [15] is a static structure that consists of a coarse base mesh, a set of atomic modifications and a dependency relation on the modifications defining a partial order. In the case of a DMV, the base mesh is a coarse LEB mesh and the modifications correspond to the diamonds. Since each diamond corresponds to its central vertex, the vertices are ordered according to the dependency relation of a hierarchy of diamonds D. Thus, the spatial decomposition and dependency relation of a DMV are obtained from the implicit relationships among the diamonds in D, and only the modifications need to be explicitly encoded.

The minimal information encoded in a diamond *δ* is given by the scalar value *F*(**v**
_{c}), associated with the central vertex **v**
_{c} of *δ* . In addition to encoding *F*(**v**
_{c}), each diamond usually encodes aggregate information about the field values within the domain of *δ*, which can be used to accelerate mesh extraction. The error *∊*(*δ*) associated with diamond *δ* encodes the maximum approximation error for any point within the domain of *δ*, i.e.,
TeX Source
$$\varepsilon \left(\delta \right) = \mathop {Max\left({\varepsilon \left(p \right)} \right),}\limits_{p \in {\rm{\delta }}} $$
where is the absolute difference between the field value at point *p* and the approximated value obtained through barycentric interpolation of the field values at the vertices of *δ* . The range of values within the domain of *δ* is also usually maintained. This is used to cull irrelevant regions during field-based queries [30].

A *full DMV*, which we denote as Δ_{f}, contains diamonds corresponding to all vertices of a scalar field of dimensions (2^{
N} + 1)^{3}. The base mesh of Δ_{f} is a single 0-diamond *δ* covering the entire cubic domain Ω. The eight corner points of Ω (i.e. the vertices of *δ*) are the only points within Δ_{f} that do not correspond to diamonds.

A full DMV Δ_{f} can be encoded as a three-dimensional array whose entries represent the information associated with each diamond and can be indexed using a C-style row major ordering, or a more complicated indexing scheme such as a hierarchical space-filling curve [8].

However, when some of the vertices of a full DMV Δ_{f} are unavailable or irrelevant for an intended application, a *partial DMV*, which we denote as D_{p}, can be much more efficient to encode than Δ_{f} . The base mesh of a partial DMV Δ_{p} is a coarse LEB mesh consisting of diamonds from a corresponding hierarchy of diamonds D, whose vertices are tagged with values from the scalar field *F*. The diamonds in Δ_{p} are a subset of the diamonds of D subject to the *transitive closure* constraint that if a diamond *δ* belongs to Δ_{p} then all ancestors of *δ* belong to Δ_{p} as well. Finally, the dependency relation of Δ_{p} is the dependency relation of Δ restricted to the diamonds in Δ_{p}.

A straightforward representation for Δ_{p} is a diamond-based one, where each encoded diamond must explicitly maintain the coordinates of its central vertex in addition to its encoded data. However, due to the transitive closure constraint of the partial DMV model, the encoded diamonds exhibit both a spatial and a hierarchical coherence which can be exploited by clustering the diamonds into supercubes. Since Δ_{p} is static, and typically sparse with respect to a corresponding full DMV we represent the internal map within supercubes using the bitflags encoding of Section 5.2. The supercubes at each level are indexed by the coordinates of their origin.

SECTION 7

## Encoding An Active Front

*Selective refinement* is the general operation of extracting a variable-resolution mesh from a multiresolution model [15]. It is defined by an application-dependent predicate called the *Level of Detail (LOD) criterion*, which determines the minimum set of modifications necessary to generate a mesh of the required resolution. The LOD criterion can be based on many factors, including approximation error, field-values (e.g. isosurface extraction), location (e.g. view-dependent and region of interest queries) and perception (e.g. screen-space error). Selective refinement is performed by traversing the DAG describing the multiresolution model either in a top-down manner starting from the base mesh or incrementally from an already extracted mesh. The status of the refinement process is described by a cut of the DAG, called the *active front*, which separates the set of modifications that have been applied from those that have not.

When selective refinement is performed on a DMV, the active front describes a conforming tetrahedral mesh Σ, that we call the *current mesh*, which can be used to visualize an approximation of the dataset, e.g. to extract an isosurface or for direct volume rendering. In general, a diamond in a current mesh S will not contain all of its tetrahedra, and thus diamonds need to track which of their tetrahedra are present in Σ (see Figure 5a for an example in 2D, where, e.g., the blue diamonds contain only one of their two triangles). A diamond in the active front cannot be subdivided until all of its parents have been subdivided and, thus, all of its tetrahedra are present in Σ.

We have observed [26] that in a hierarchy of diamonds, a diamond with *k* parents has 2 *k* tetrahedra, and that, upon subdivision, each parent of a diamond *δ* contributes a pair of tetrahedra to *δ* . Thus, since *0-diamonds* have three parents *1-diamonds* have two parents and *2-diamonds* have four parents, bitflags with three, two and four bits, respectively, are sufficient to track the subdivided parents of diamonds as well as their tetrahedra in Σ. Since a diamond cannot be subdivided until all of its parents have been subdivided, the former property can be used to accelerate the extraction process, while the latter property can be used to visualize the extracted mesh Σ.

A straightforward representation for encoding an active front utilizes a hash table of diamonds. Each diamond *δ* is indexed by its central vertex **v**
_{c}, and contains a set of bitflags tracking its subdivided parents as well as any additional information that must be encoded for the diamond. This representation requires 7 bytes of overhead for each encoded diamond: 6 bytes for the coordinates of its central vertex and one additional byte of bookkeeping.

However, there is a considerable amount of coherence among the tetrahedra in Σ that a diamond-based representation of an active front cannot exploit. Due to the LEB subdivision rule, neighboring tetrahedra in Σ can differ by at most one level of refinement, so the presence in Σ of a tetrahedron from diamond *δ* often indicates the presence of tetrahedra from neighboring diamonds in the hierarchy. We therefore propose a supercube-based representation for active fronts extracted from a DMV. Recall that a supercube indexes 56 diamonds, of which

8 are 0-diamonds, each with 6 tetrahedra,

24 are 1-diamonds, each with 4 tetrahedra and

24 are 2-diamonds, each with 8 tetrahedra.

Thus, each supercube indexes up to 336 tetrahedra. Note, however, that these tetrahedra overlap (see Figure 5c), but tetrahedra in a conforming mesh cannot overlap. Due to the containment relation among the tetrahedra in the hierarchy, the presence of a tetrahedron **t** in Σ precludes the presence of its parent tetrahedron and both of its children tetrahedra from Σ. Thus, in practice, a supercube in Σ contains significantly fewer than the 336 possible tetrahedra (see Figure 5b).

Since tetrahedra contribute to diamonds of Σ in pairs, we can track the tetrahedra due to a single supercube in the active front Σ using (336 *ℒ/*2) bits = 21 bytes. Our proposed supercube-based representation for an active front therefore requires 27 bytes of overhead per supercube: 6 bytes to index its origin and 21 bytes of bookkeeping.

In this Section, we evaluate the effectiveness of supercubes as a partial DMV representation and as an active front representation across a testbed of volume datasets of resolution up to 512^{3}. All experiments were run on a 2 GHz Intel Core 2 Duo laptop with 4 GB of RAM.

We first consider when it is appropriate to represent a dataset using a partial diamond hierarchy. This is measured in terms of the *density* of the dataset, i.e. the percentage of samples from a full hierarchy that are retained in the partial representation. Next, we analyze when supercube-based representations of a partial hierarchy are appropriate. For this, we consider the *concentration* of the clustering, that is, the average number of diamonds encoded per supercube. A supercube-based representation for a partial hierarchy of diamonds provides the maximum benefit when the desired dataset is sparse with respect to the full dataset and concentrated with respect to the supercube clustering.

Clustered representations typically incur some computational overhead related to the extra level of indirection required to index the data. We thus compare the runtime performance of the DMV representations during selective refinement queries. Since the efficiency of a selective refinement query depends on the representation of its associated active front, we conclude by comparing the supercube-based and diamond-based active front representations of Section 7 in terms of performance and storage costs.

We begin by introducing some notation. Let Δ_{f} denote the full DMV, containing *n*_{f} = (2^{
N} + 1)^{3} diamonds and let Δ_{p} denote the desired partial DMV, containing *n*_{p} diamonds. Δ_{p} can be encoded using a diamond-based partial DMV Δ_{d} or a supercube-based representation Δ_{s}, whose *n*_{p} diamonds are clustered into *n*_{s} supercubes. Finally, let *b*_{δ} denote the number of bytes required to encode the data associated with each diamond *b*_{v} the number of bytes required to encode the coordinates of the central vertex of each diamond and *b*_{σ} the number of bytes required to encode the indexing and bookkeeping information associated with each supercube.

We compare the costs of these representations in Table 1 with respect to an ideal representation Δ_{p}, which only represents the *n*
_{p} diamonds. This representation is not practical since it has no way of indexing the encoded diamonds, but we use it to compare the remaining representations. Δ_{f} must encode all *n*
_{f} samples but the indexing of its elements is implicit. However, it encodes *n*_{f} − n
_{p} extraneous diamonds. In contrast, Δ_{d} encodes only the *n*
_{p} diamonds but must also explicitly encode the spatial coordinates of each diamond. Finally, the overhead in Δ_{s} can be attributed entirely to the *n*
_{s} supercubes.

Using this notation, we define the *density $* = *n*_{p}/n_{f} of the dataset as the ratio of retained diamonds in Δ_{p} compared to Δ_{f} . Also, we define the *concentration #* = *n*_{p}/n_{s} of the dataset as the average number of diamonds per supercube. We note that *#* ∈ [1],56] since we only encode supercubes that contain at least one diamond.

By rearranging the equations in Table 1 and substituting terms for *$* and *#*, we can compare the representations. Δ_{s} is more compact than Δ_{f} when
TeX Source
$$ < {{b\delta } \over {b\delta + (b\sigma +)}},$$
Δ is more compact than Δ_{f} when
TeX Source
$$ < {{b\delta } \over {b\delta + b_v }},$$
and Δ_{s} is more compact than Δ_{d} when *# > b*_{σ} /b_{v}. However, since all representations must encode the *n*_{p} diamonds, a more relevant measure of the effectiveness of each representation is related to its overhead with respect to Δ_{p} (third column of Table 1). While Δ_{d} has a constant overhead of *b*_{v} bytes per diamond, the overhead in Δ_{s} is related to *#* as (*b*_{s} /#) bytes per diamond.

As a concrete example, let the size of each refinement be *b*_{δ} = 4 bytes as in [8]. Further, assume vertices are encoded in 6 bytes as three unsigned shorts, then *b*_{v} = 6 bytes. Finally, let *b*_{s} = 17 bytes consisting of: the origin of the supercube (6 bytes), bitflags to indicate the encoded diamonds (7 bytes) and a pointer to an array containing the data (4 bytes). Then, in terms of density and concentration, Δ_{s} is more compact than Δ *f* and Δ_{d}, respectively, when , and when *# >* 17 *ℒ/*6. The gray curves in Figures 6 and 7 separate the half-spaces in which D_{s} is more compact than Δ_{f} by the constant to its right. For example, when *#* = 17 and *$* = *.*2, Δ_{f} requires four times as much space to encode as Δ_{s}.

As a first application, consider a partial DMV Δ_{p} generated from a full DMV Δ_{f} by retaining all diamonds whose error is greater than a given threshold *∊*. Since Δ_{p} corresponds to a partial hierarchy of diamonds, it must also retain all ancestors of the retained diamonds. This ensures the transitive closure of the diamond dependency relation (as described in Section 6). When *∊* = 0, this generates a lossless encoding of Δ_{f}, i.e. Δ_{f} can be reconstructed from Δ_{p} without any error.

Table 2 lists the number of elements, and storage costs in a zero-error partial DMV Δ_{p} for various datasets as well as their density *$* and concentration *#*. These datasets are plotted on Figure 6 for *∊* = 0% and *∊* = 1%. We observe that some datasets, such as Fuel and Aneurism are extremely sparse, and achieve a 12.2 times and 17.3 times reduction in storage requirements, respectively, compared to Δ_{f} . In contrast, other datasets such as Plasma and Buckyball are quite dense, and thus, a partial representation does not yield a significant savings compared to Δ_{f} . However, even for these datasets, the size of Δ_{s} is close to that of Δ
_{f} (requiring 4% more and 19% less space, respectively), whereas Δ_{d} is much larger (requiring 2.4 times and 1.9 times more space, respectively). Most of the remaining datasets achieve around three times savings for Δ_{s} compared to Δ_{f} (see last column in Table 2).

Since *b*_{v} (6 bytes) is 1.5 times as large as *b*_{δ} (4 bytes), the overhead associated with Δ_{d} compared to the ideal representation Δ_{p} is 150%. In contrast, the overhead of D_{s} is related to the concentration of the supercube clustering, and averages around 12% across all datasets. Thus, the 2.25 times savings achieved by Δ_{s} compared to Δ_{d} is entirely due to the difference in storage overhead.

Partial hierarchies can also be used to reduce the storage requirements and mesh extraction times required for isosurface extraction when the (set of) isovalue(s) can be determined in advance. In iso-surfacing applications, the *active* cells, i.e. those that intersect the iso-surface, typically occupy a sparse but spatially widespread subset of the domain. Since isosurfaces are continuous, there is a great deal of spatial and hierarchical coherence among the active cells.

We can thus generate an isovalue-based partial DMV Δ_{p} from Δ_{f}, where all diamonds whose range intersects the predetermined isovalue(s) are retained, while those not intersecting the isovalue(s) are only retained if they are ancestors of the required diamonds. Δ_{p} can then be queried using selective refinement to extract adaptive tetrahedral meshes and isosurfaces. This model thus trades fidelity in regions away from the desired isosurface for storage and extraction efficiency of the desired isosurface(s).

Table 3 lists the number of elements and the storage requirements for the three DMV representations for each isovalue-based dataset (the values of *N* and *n*_{f} can be found in Table 2). The density and concentration of these datasets are plotted in Figure 7. We observe that these extracted partial DMVs are indeed sparse with respect toΔ *f*, averaging around 5% of the samples and often much less. They are also quite concentrated with respect to the supercube clustering, with an average concentration of 26 out of a possible 56 diamonds per supercube. Thus, supercube-based partial DMVs of these datasets require an average of 25 times less storage than their corresponding full DMVs. In fact, the largest dataset Xmas_{{868}} (orange square in Figure 7) requires only 1.3% of the samples of Δ *f* and is over 65 times more compact.

As in the error-based partial DMVs, the supercube-based encodings are approximately 2.3 times smaller than a corresponding diamond-based DMV, and have very low overhead (around 13%) compared to the ideal representation Δ_{p}.

We note that, when more than one isovalue is desired (as in the set of Engine datasets on the bottom of Table 3, and the corresponding colored rhombuses in Figure 7), there is also a significant amount of coherence among the active cells of distant isovalues (e.g. 58 and 170). Thus, the supercube-based representation for Engine_{{58, 100 }} requires only 15% more storage space than either of the individual datasets Engine_{{58}} or Engine_{{100}}, and has a higher concentration than either of them. This advantage is increased in Engine_{{58, 100, 170}} as the samples from a third isovalue are added, where the density only increases by 3% and the supercube concentration increases by .8.

We now compare the runtime performance of the three DMV representations, Δ_{f}, Δ_{d} and Δ_{s}, by comparing the rates at which they can process diamonds during selective refinement queries. Since an active front facilitates selective refinement, we evaluate the performance of the two active front representations introduced in Section 7. Recall that the active front of a selective refinement query on a diamond hierarchy corresponds to a tetrahedral mesh called the *current mesh* Σ. This mesh can be represented using a diamond-based representation, which we denote as Σ_{d}, or through a supercube-based representation which we denote as Σ_{s}.

Since selective refinement queries depend on the specific LOD criterion used, we evaluate the performance of each structure in terms of the number of diamonds visited by the selective refinement query per second. In Table 4, we present the aggregate results over our testbed of datasets for an error-based isosurface extraction query and note that we observed the same trends when using different queries, such as region of interest and approximation error queries. The LOD criterion for this query selects all diamonds with approximation error greater than some threshold *e* and containing a particular isovalue *k*. As a partial DMV for this query, we use the datasets generated in Table 3.

For these experiments, we implemented Δ_{d} using a hash table from the central vertex of each diamond in Δ_{d} to the data associated with it. This incurs a storage overhead inversely proportional to the *load factor* of the hash table, i.e., the ratio of diamonds in Δ_{d} to buckets in the hash table. Across all datasets tested, we found the load factor to average 73.5% (with a standard deviation of 16%). Thus, the hash-indexed Δ_{d} requires an average memory overhead of 36% compared to the values listed in Table 3. Similarly, for Δ_{s}, we used a separate hash table for each level of supercubes, and indexed the data associated with each supercube by its origin (as described in Section 5.3). We found the load factor to average 75% (with a standard devaiation of 11%) across the datasets, thus, requiring an average memory overhead of 33% compared to the values listed in Table 3.

We evaluate the performance of the DMV representations (i.e. the rows of Table 4) by comparing the average number of diamonds processed per second. Recall that due to the query type and the transitive closure of Δ_{d} and D_{s}, all three representations process the same set of diamonds and yield the same result. We first observe that all three representations yield similar performance results of about 300,000 diamonds per second. Δ_{f} is the fastest DMV representation, since it can directly access its diamonds using the array location of their central vertices. Δ_{d} is approximately 5-6% slower than Δ_{f}, due to its use of indirect hashing, while Δ_{s} is around 7.5% slower than Δ_{f} . Thus, despite its required extra processing, such as extracting the supercube origin and diamond type and the prefix sum calculation, supercube-based Δ_{s}'s performance is within 2% that of diamond-based Δ_{d}.

Next, we evaluate the relative performance of the two active front representations Σ_{s} and Σ_{d} by comparing columns 4 and 7 (AVERAGE) of Table 4. Thus, the supercube-based active front representation Σ_{s} is, on average, 1-2% more efficient than the diamond-based active front representation Σ_{d}. Although this is not a significant difference, we note that the addition (removal) of any diamond to (from) Σ_{d} incurs a memory allocation (deallocation), whereas, due to the supercube clustering, such allocations (deallocations) are rarer for Σ_{s}.

Finally, we evaluate the sizes of the two active front representations. Recall that the supercube-based active front representation Σ_{s} requires 27 bytes overhead per supercube. Over the entire test, Σ_{s} averaged 26.5 tetrahedra per supercube (with a standard deviation of 3.1). Thus, the supercube-based active front Σ_{s} incurs an overhead of around 1 byte per tetrahedron in the active front. In contrast, the diamond-based active front representation Σ_{d} requires 7 bytes overhead per diamond. Over the entire test, Σ_{d} averaged 3.3 tetrahedra per diamond (with a standard deviation of .55). Thus, the diamond-based active front incurs an overhead of around 2.16 bytes per tetrahedron in the active front.

We implemented both Σ_{s} and Σ_{d} using hash tables, (analogously to our indexing of the partial DMVs above). Across all datasets, we achieved an average load factor of 74% for Σ_{d} (with a standard deviation of 15%), and thus the hash-indexed Σ_{d} incured a memory overhead of around 36%. The average load factor for Σ_{s} was 72% (with a standard deviation of 11%), requiring an average overhead of 39%. Thus, a supercube-based active front representation Σ_{s} can be used to extract an equivalent mesh from a DMV as a diamond-based representation Σ_{d} in slightly less time and using less than half the storage.

Figure 8 illustrates the clustering of tetrahedra in a supercube-based active front by the color of their isosurface triangles.

SECTION 9

## Concluding Remarks

We have proposed the *supercube* as a high-level primitive for compactly encoding nested tetrahedral meshes generated through longest edge bisection. Supercubes represent the basic unit of symmetry within the hierarchy of diamonds model, and encode all distinct types of diamonds within the hierarchy (up to scaling factors). Supercube clustering provides an efficient means of associating information with a subset of the diamonds within an LEB hierarchy by exploiting the spatial and hierarchical coherence within the dataset.

We have demonstrated that several visualization datasets are over-sampled by a factor of three or more while at the same time the retained elements have a high degree of coherence with respect to super-cube clustering. Thus, a supercube-based partial DMV is an effective multiresolution representation that efficiently supports selective refinement queries with very little geometric or computational overhead. We have also demonstrated that a supercube-based active front representation can accelerate selective refinement while requiring less than half the storage of a diamond-based active front data structure.

Here, we have focused on the implementation of the internal map between supercubes and their associated data. However, since our indexing structure for the supercubes at each level utilizes a hash table (see the end of Section 8), our partial DMV representations can be inflated by as much as 40%. This can reduce the benefits of a supercube-based DMV Δ_{s} to a full DMV Δ_{f}, when their relative differences are less pronounced. However, when the relatives sizes are more signifi-cant, a hash-indexed Δ_{s} still provides a significant advantage over Δ_{f} . Additionally, we have demonstrated that hash-indexed DMVs and active front representations based on diamonds suffer from similar or worse overhead than their supercube-based counterparts.

In future work, we intend to focus on the indexing structure for diamonds and supercubes in a partial hierarchy. As mentioned in Section 5.3, since the set of supercubes at a given level of resolution tile the plane, an MX-octree is a promising representation for the spatial access structure. Specifically, a pointerless MX-octree [24] should achieve the storage goals of Tables 2 and 3. Alternatively, since Δ_{d} and Δ_{s} contain static spatial data, a perfect spatial hash [14] can be generated to yield significantly lower overhead than a standard hash table.

We are also currently looking into modifications of the supercube representation for higher dimensional datasets such as time-varying volume data where the internal map of each supercube must reflect the increased number of diamonds.

### Acknowledgments

We would like to thank the anonymous reviewers for their many helpful suggestions. This work has been partially supported by the National Science Foundation under grant CCF-0541032 and by the MIUR-FIRB project SHALOM under contract number RBIN-04HWR8. The Buckyball model is courtesy of AVS Inc. The Plasma model is courtesy of Visual Computing Group, National Research Council, Pisa, Italy. All other datasets are courtesy of volvis.org.