RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies

Transcription

1 RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies TaeJoon Kim (a) St. Matthew scene BoChang Moon DukSu Kim KAIST (b) Iso-surface model Sung-eui Yoon (c) Lucy and CAD turbine models Figure 1: Left and middle images are results of ray tracing using our random-accessible compressed bounding volume hierarchies (RACBVHs) of St. Matthew model consisting of 128M triangles and an iso-surface model consisting of 102M triangles. Right image shows a frame during a rigid-body simulation using collision detection between two models including the Lucy model consisting of 28M triangles. By using our RACBVHs, we are able to reduce the storage requirement by more than 10:1 factor and, even, improve the performance of ray tracing and collision detection by up to a factor of two. Abstract boxes (AABBs) and, oriented bounding boxes (OBBs). We present a novel bounding volume hierarchy (BVH) compression and decompression method transparently supporting random access on the compressed BVHs. To support random access on the compressed BVHs, we decompose a BVH into a set of clusters, each of which contains consecutive bounding volume (BV) nodes in the original layout of the BVH. Then, each cluster is compressed separately from other clusters and serves as an access point to the compressed BVH. Our compression method preserves the original layout of a BVH. If BVHs are provided with cache-efficient layouts, we can maintain high cache utilization during random access or hierarchical access on the compressed BVH. We provide the general BVH access API to transparently access the compressed BVHs. At runtime, our decompression framework guarantees to provide correct BV nodes requested by applications without loading and decompressing the whole BVHs. To highlight the benefits of our approach, we apply our method to two different applications: ray tracing and collision detection. We are able to observe more than 10:1 compression ratio and up to 2:1 runtime performance improvement compared to using uncompressed original BVHs. This runtime performance improvement is due to the reduced I/O time by selectively fetching and decompressing small regions of the compressed BVHs requested by applications. A major problem of using BVHs is that BVHs can have high storage requirements. For example, each OBB node takes 64 bytes. Therefore, for massive models consisting of hundreds of millions of triangles, BVHs of those models can take tens of gigabytes of space. Moreover, the typical data access pattern on BVHs cannot be predetermined at preprocessing time and is random at runtime. Therefore, accessing BVHs at runtime can have low I/O efficiency and cache utilization. Keywords: Hierarchy and BVH compression, random access, cache-coherent layouts, ray tracing, collision detection 1 Introduction Bounding volume hierarchies (BVHs) are widely used to accelerate the performance of various geometric and graphics applications. Example applications include ray tracing, collision detection, visibility queries, dynamic simulation, and motion planning. These applications typically precompute BVHs of input models and traverse the BVHs at runtime in order to perform intersection or culling tests. There are many different types of bounding volume (BV) representations including spheres, axis-aligned bounding An aggravating trend is that the growth rate of the data access speed is significantly slower than that of the processing speed [Patterson et al. 1997]. Therefore, the problem of the high storage requirement and low I/O efficiency/cache utilization of BVHs of massive models will be more pronounced in coming years. In order to address this problem, there have been several approaches. One class of methods is to use compact in-core BV representations by using quantized BV information or by utilizing the connectivity information of an original mesh and coupling the mesh and the BVH. Another class of methods is to store BV nodes in a cache-coherent manner to improve cache utilization and, thus, improve the performance of traversing BVHs. However, due to the widening performance difference between the data access speed and processing speed, prior work may not provide enough reduction on storage requirement nor achieve high I/O efficiency during the BVH traversal. Main results: In this paper we propose a novel BVH compres- sion and decompression method supporting transparent random access on the compressed BVHs. We present a cluster-based layoutpreserving BVH compression method. We compress BVs of a BVH by sequentially accessing BVs in the BV layout of the BVH. During the compression, we decompose consecutive BVs into a set of clusters, which will serve as access points for random access at runtime. Our compression method preserves the original layout of a BVH and, thus, maintains high-cache utilization during the BVH traversal if the original layout maintains high cache-coherence. In order to allow various applications to transparently access the com-

2 pressed BVHs, we provide a general BVH access API. Given a BV node requested by the API, our runtime decompression framework efficiently identifies, fetches, and decompresses a cluster containing the data into an in-core representation that can efficiently support random access. To demonstrate the benefits of our method, we implement two applications, ray tracing and collision detection, by using our BVH access API. Overall, our approach has the following benefits: 1. Low storage requirement: Our random-accessible compressed BVHs (RACBVHs) has more than 10:1 compression ratio compared to an uncompressed BV representation. Also, we use random-accessible compressed meshes and achieve a similar compression ratio for the compressed meshes. 2. Improved performance: By selectively fetching and decompressing data requested by the BVH access API, we can achieve higher I/O efficiency. Therefore, we are able to achieve up to 2:1 performance improvement on our tested applications over using uncompressed BVHs and meshes. 3. Wide applicability: The provided BVH access API allows various applications to transparently access the compressed BVHs. Moreover, our BVH access API supports random access and does not restrict the access pattern for BVH-based applications. As a result, existing BVH-applications can be easily modified to take advantage of the benefits of our RACBVH representation. Organization: In Sec. 2, we discuss related work followed by an overview of our approach in Sec. 3. Then, we present our compression and runtime decompress framework in Sec. 4 and Sec. 5 respectively. We highlight results of our method in Sec. 6. Then, we conclude in Sec Related Work In this section we review prior work related to BVHs and compression methods supporting random access on the compressed data. 2.1 Bounding Volume Hierarchies BVHs have been widely used as an acceleration data structure for ray tracing [Rubin and Whitted 1980], visibility culling, and proximity computations [Lin and Manocha 2003; Teschner et al. 2005]. There are different types of bounding volumes (BVs). Some of the commonly used BV types include simple shapes such as spheres [Hubbard 1993] and axis-aligned bounding boxes (AABBs) [van den Bergen 1997], or tight fitting BVs such as oriented bounding boxes (OBBs) [Gottschalk et al. 1996], and discretely oriented polytopes (k-dops) [Klosowski et al. 1998], etc. Many top-down and bottom-up techniques have been proposed to construct these BVHs [Lin and Manocha 2003; Teschner et al. 2005]. 2.2 Mesh compression In the fields of computer graphics and visualization, mesh compression techniques have been well researched over the last decade and excellent surveys are available [Alliez and Gotsman 2005; Gotsman et al. 2002]. Most previous mesh compression schemes were designed to achieve maximum compression as they were targeted for archival use or transmission. They achieved this goal by encoding vertices, edges, and faces in a particular order agreed upon by encoder and decoder such that the mesh layout itself would not have to be transmitted. 2.3 Compression and Random Access Most of prior techniques of mesh compression do not directly provide random access to the compressed meshes. Typically, in order to access a particular mesh element such as vertex, the whole compressed mesh must be sequentially decompressed to an uncompressed format that can support random access. In this section we will focus on various compression techniques supporting random access on the compressed data. Single or multi-resolution mesh compression: Choe et al. [2004] proposed a single-resolution mesh compression method supporting selective rendering. Recently, Yoon and Lindstrom [2007] proposed random-accessible compressed meshes for general applications requiring random mesh access. Their compression method preserves the original layout of the mesh in order to maintain cachecoherence of the layout. This method achieves up to 20:1 compression ratio and performance improvement on iso-contouring and layout re-computation. There have been a few multi-resolution compression methods that support random access. Gobbetti et al. [2006] proposed a compressed adaptive mesh representation of regular grids for terrain rendering. Also, Kim et al. [2006] introduced a multi-resolution compression method for selective rendering based on their earlier multi-resolution data structure. Multimedia and regular grids: Random access is one of the key components of the MPEG video compression format that allows users to browse video in a non-sequential fashion [Gall 1991]. Particularly, MPEG video codec method periodically inserts intra pictures as access points in the compressed scheme. Such intra pictures are compressed without utilizing information from other frames. Then, subsequent frames are compressed by predicting the motion in between these intra pictures. For regular volumetric grids, wavelet-based compression methods [Ihm and Park 1999; Rodler 1999] that support random access have been proposed. 2.4 Tree and BVH compression Tree compression has been researched in many different fields [Katajainen and Makinen 1990]. These techniques include compression of the tree structure by linearizing the structure [Zaks 1980] and transforming the tree into a pre-defined tree [Zerling 1985]. However, these compressed trees do not support random access nor preserve the layouts of the trees. There are relatively few research efforts on compressing BVHs. A BVH has two main components: BV information and indices to child nodes. We will discuss prior compression methods on these two components in detail. Encoding bounding volumes: In order to compress the bounding volume information, fixed-rate quantization methods [Gersho and Gray 1991] are frequently used [Cline et al. 2006; Mahovsky 2005; Terdiman 2003] as employed to compress geometry of meshes [Alliez and Gotsman 2005]. Also, hierarchical encoding schemes are developed to further achieve higher compression ratio and improve the compression quality [Rusinkiewicz and Levoy 2000; Hubo et al. 2006] by performing quantization of bounding volumes of nodes within the region of the bounding volume of its parent node. These methods can support fast decoding and random access on the quantized bounding volume information. We also employ the quantization method. We further improve the compression ratio by using a simple prediction model and the context-based arithmetic coding scheme [Moffat et al. 1998] while supporting fast random access. Encoding tree structures: Many techniques assume a particular tree structure (e.g., complete tree) in order to totally remove the cost related to encoding the tree structure [Cline et al. 2006; Lauterbach et al. 2007]. Recently, Lauterbach et al. [2007] introduced a Ray- Strip representation, which implicitly encodes a complete spatial kd-tree from a series of vertices. These techniques do not use any bit for encoding the tree structures. However, these methods are not compatible with various hierarchy construction methods [Wald 2007] optimized to achieve high culling efficiency, since the computed trees may not be complete trees. Lefebvre and Hoppe [2007] employed local offsets to encode the location of child nodes given the pre-ordered layout of the tree. All of these techniques support random access on the compressed meshes, but assume a particular tree structure or a layout for the tree. Papers 0126: RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies Page 2 of 8

3 3 Overview In this section we will discuss issues of dealing with BVHs of massive models and give a brief overview of our approach to efficiently handle them. 3.1 Dealing with BVHs of Massive Models BVHs are widely used to accelerate the performance of intersection or culling tests in various applications. Leaf nodes of a BVH contain triangles of the original model. Each intermediate node of a BVH contains the BV information that encloses all the triangles located under the sub-tree rooted at the intermediate node. There are many different types of BV representations including spheres, axis-aligned bounding boxes (AABBs), oriented bounding boxes (OBBs), and convex polytopes. In this paper we use the AABB and a binary BVH due to its simplicity and the wide acceptance in various applications. High storage requirement: Although BVHs can efficiently provide culling methods for intersection tests, the storage requirement of BVHs can be very high for massive models consisting of hundreds of millions of triangles. For example, a simple AABB node representation has the following structure: s t r u c t AABB { s t r u c t BV { V e c t o r 3 f Min, Max ; / / bounding volume i n f o r m a t i o n. }; s t r u c t T r e e S t r u c t u r e { Index Left, Right ; / / i n d i c e s f o r c h i l d nodes. } }; Listing 1: AABB node representation The Min and Max have minimum and maximum extents of the AABB in x, y, and z dimension. Also, the Left and Right have indices of child nodes in the case of intermediate nodes. For a leaf node, the Left and Right encode triangles associated with the leaf node. Typically, a BVH is constructed until each leaf node has only one triangle. Therefore, we assume that each leaf node has only one triangle; the Left and Right of the leaf node have a triangle index of the triangle and a null index respectively. This AABB structure requires 32 bytes. The storage requirement for a model consisting of a hundred of millions of triangles is about 6.4 GB. Therefore, BVHs of massive models may not be loaded into the main memory and be accessed from disk or through a network. Random access pattern: Traversal on BVHs shows random access pattern for applications including ray tracing and collision detection. These applications typically take two inputs: two 3D objects for collision detection and one 3D object and a ray for ray tracing. The runtime algorithm traverses the BVH of each object using a depth-first or breadth-first order as long as a collision is detected between two inputs. In general, it is hard to predict the runtime access pattern on BVHs at preprocessing time and optimize access pattern at runtime. Therefore, the data access time can be the major bottleneck of many applications using BVHs of massive models. Cache coherence: There have been several research efforts on designing cache-coherent algorithms by re-ordering the runtime access patterns [Arge et al. 2004; Isenburg and Lindstrom 2005] or by re-ordering the underlying data [van Emde Boas 1977; Yoon and Manocha 2006]. These techniques target to reduce the number of expensive cache misses during random access on the data, since cache misses in various memory levels (e.g., L1/L2, main memory) are significantly expensive compared to the computation time. Out-of-core techniques: Out-of-core techniques have been widely researched in order to handle massive models that cannot fit into the main memory [Silva et al. 2002]. These techniques aim at reducing the expensive data access operations when dealing with massive models by only loading necessary data and performing local operations. However, due to the widening gap between data processing speed and data access speed [Patterson et al. 1997], the time spent even on loading only the necessary data from disk can be very expensive. 3.2 Our Approach In order to efficiently access BVHs and improve the performance of various applications using BVHs, we propose a novel BVH compression and decompression method. Since BVHs are accessed in an arbitrary manner at runtime by applications, we design our compression and decompression method supporting random access on the compressed BVHs. Our method has two main components: (1) a cluster-based layout preserving BVH compression and (2) a runtime decompression framework that transparently supports random access on the compressed BVHs without decompressing the whole BVH. Cluster-based layout preserving BVH compression: We compress BVs of a BVH by sequentially reading BVs in the BV layout of the BVH. We choose our compression method to preserve the original layout of the BVH in order to achieve high cache utilization that original layouts may maintain. We decompose the original layout of the BVH into a set of clusters. We assign consecutive BVs in the BV layout to each cluster. We set each cluster to have the same number (e.g., 4K) of BVs and compress each cluster separately from other clusters. At runtime, decompression is performed at the granularity of clusters. Therefore, each cluster serves as an access point for random access on the compressed BVHs. Runtime BVH access framework: We define an atomic BVH access API supporting transparent and random access on the compressed BVHs. Our runtime BVH access framework identifies a cluster containing a BV node requested by an application. Then, the runtime framework fetches and decompresses the cluster into an in-core representation. Based on our in-core representation, we can very efficiently support random access on the decompressed BV nodes. Our runtime BVH access framework guarantees to return correct BV information of the requested data when applications access the compressed data via our BVH access API. We employ a simple memory management method based on a least recently used (LRU) in order to handle massive models and their BVHs that cannot fit into the main memory. We perform the memory management in the granularity of clusters. 4 Compression In this section we will explain our cluster-based layout preserving BVH compression method. 4.1 Cluster-based Layout Preserving BVH Compression Our compression method sequentially reads and compresses BV nodes as represented in Listing 1. As we read each BV node in the BV layout, we assign the BV node into a cluster. For clustering, we simply decompose consecutive BV nodes into a cluster, where each cluster has the fixed number of power-of-two nodes (e.g., 4K). Then, each index of a BV node can be encoded as a pair of indices, (C i, l i), where C i is the cluster index of a cluster that the node is assigned and l i is the local index of the node within the cluster. Let us call the pair of indices, a pair index. Also, note that each cluster can have one or multiple sub-trees. We call root nodes of those subtrees contained in a cluster local roots of the cluster. We also define local leaf nodes to denote leaf nodes of those sub-trees within each clusters. We also define Parent(n) to be a parent node of a node n. Also, parent clusters of a cluster c are defined to be clusters containing parent nodes of local roots of the cluster c. Similarly, we can define child clusters of a cluster. Fig. 2 shows an example of a BV layout and computed clusters. For a new cluster, we initialize all the compression context. Therefore, each cluster can be decompressed at runtime in any order although we compress each cluster sequentially at a particular order at preprocessing time. We also define a front for the sub-tree located Papers 0126: RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies Page 3 of 8

4 Layout n 7 n 8 n 9 Cluster C 0 Cluster C 1 Cluster C 1 n 9 n 11 n 12 Local roots n 8 n 13 n 10 n 14 n 15 Local leaves Figure 2: Clusters from a BV layout: This figure shows a BV layout on the left and a computed cluster, C 1, on the right. Red arrows indicate the BV layout of the BVH. under each local root of a cluster during compression. A front consists of BV nodes that are not yet connected to its two child BV nodes during compressing the cluster. Once a node in the front is connected to its two child nodes, the node is deleted from the front. An example of a front is shown at Fig. 3. It is desirable that constructed clusters should contain BV nodes that are likely to be accessed together during the traversal of BVHs. Otherwise, we may have to load and decompress many clusters, which can lower the performance of applications using RACB- VHs. Since clusters are implicitly computed from original layouts of BVHs, BV nodes that are likely to be accessed together should be stored very closely in the layout of a BVH. Fortunately, there are a few layouts satisfying such property. Such layouts include cacheefficient layouts of BVHs [Yoon and Manocha 2006] and van Emde Boas layout [van Emde Boas 1977]. An example of clusters computed from different layouts are shown in Fig. 4. We will compare the performance of different layouts in Sec Arithmetic coding: We use a context-based arithmetic coding [Moffat et al. 1998] for virtually most of the data that we encode in our compression method. In particular, we use the previous compression data as a context for the next one. We also re-initialize all probability tables with a uniform distribution when compressing a new cluster to allow independent decoding of clusters. To minimize the negative impact of this periodic initialization in terms of the compression ratio, we employ a fast adaptive probability modeler [Schindler 2000]. 4.2 Encoding Bounding Volumes The Min and Max contain the minimum and maximum extents of a AABB node. We first quantize each component, i.e., x, y, and z, of the Min and Max of each BV node. We use a fixed-rate quantized method [Gersho and Gray 1991] for those components based on the root bounding volume of a BVH. We perform the quantization conservatively such that the quantized BV still encloses all the triangles contained in the original BV of the node. Then, we further compress the quantized min and max values based on the BV information of P arent(n) of the node n currently being encoded. To do that, we predict its two child BVs given the BV of Parent(n). Then, we only encode the difference between the predicted and actual BVs by using an arithmetic encoder. For the prediction, we partition the parent BV into two child BVs by dividing the longest axis of the BV into half. We found that this simple median prediction method works quite well in our benchmarks. One notable thing is that a parent node Parent(n) of a node n may be stored in a different cluster to that of the node n. In this case, we cannot assume that the BV information of the Parent(n) is available when decompressing the node n. Our runtime framework addresses this problem by guaranteeing the existence of the P arent(n) by loading the cluster containing the P arent(n). This will be elaborated in Sec Encoding Tree Structures The Left and Right of intermediate BV nodes as shown in Listing 1 contain two child indices and represent the structures of BVHs. Also, the Left of a leaf node has a triangle index contained in the n5 n3 n6 n1 n7 n4 n8 n0 n10 n9 n11 n2 n13 n12 n14 Front n 2 n 3 n 4 n 5 : Compressed nodes : Not yet compressed nodes Figure 3: A Front during Compression: This figure shows a front of a sub-tree during compression. By maintaining the front, we can compute two child indices, Left and Right, by encoding a parent index in the front. Since the front has relatively small number of nodes, we can efficiently encode Left and Right. leaf node. We first describe our compression method for child indices and, next, for triangle indices Encoding Child Indices Initially, we attempted to directly encode child indices of the Left and Right. However, we found it shows poor compression results because those indices can be arbitrary values for various layouts. Instead, we propose to encode those child indices by compressing the parent index of a BV node. More precisely, we encode the parent node among nodes stored in the front defined in Sec Note that our BV representation does not have any direct information for the parent node P arent(n) for each node n. Therefore, this information should be constructed during compression. In order to efficiently identify the parent node Parent(n) from a node n, we maintain a hash table. For each node n with a node index, our BV representation gives us indices of two child nodes, Left and Right. We simply construct two hash map elements connecting a key of each child index to its current node index. Therefore, we can very easily compute a parent node Parent(n) for a node n by querying the node index of n to the hash table. There are two different cases for computing a parent node index by using the hash table. If we can find a parent node index from the hash table, then, it is guaranteed that we can find and encode the parent node among nodes stored in the front. This operation can be done in a constant time by using a dynamic vector for nodes of the front. Note that the number of nodes stored in the front is typically very small compared to the number of nodes in the BVH. Therefore, we can compactly encode the parent node by using the information acquired from the front. The average size of the front with the cache-efficient layouts is about 13 on average when we assign 4K nodes for each cluster in our tested models. However, we cannot find the parent node of a node from the hash table if the node is the root node of the BVH or is one of local roots of a cluster. In the case of the root node, this can be very easily identified and addressed. In the case of local roots of a cluster, note that parent nodes of those local roots are located in another cluster. Therefore, the front of the cluster currently being encoded cannot have those information of parent nodes of local roots during the compression and decompression of the cluster. One naive solution is to directly store an index of the parent node, which requires many bits. Instead, we encode the index of the parent node by decomposing it into a pair index of (C i, l i). Then, we encode C i in the context of indices of parent clusters of the cluster currently being encoded. Since the number of parent clusters can be very small (e.g., 2 on average for cache-efficient layouts), we can compress them very compactly. Local leaf nodes: Given our compression scheme, we cannot know the child indices of local leaf nodes of a cluster without loading child clusters of the cluster at runtime. Loading the child clusters of a cluster can significantly increase the working set of applications during the BVH traversal. To avoid this issue, we directly encode left and right child indices stored in Left and Right only for those local leaf nodes. To compactly encode those left and right child indices of local leaf nodes, we employ the delta encoding. Given a child index that we are going to encode, we compute the delta between the index and the previous index that we encoded previously. Then, we encode the delta using the arithmetic encoder Papers 0126: RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies Page 4 of 8

5 Clusters Clusters Depth-first layout Cache-efficient layout Figure 4: Clustering with Different BV Layouts: This figure illustrates different layouts of a BVH and constructed clusters by assigning the fixed number (e.g., 3) of consecutive BV nodes into clusters if the delta is less than a threshold (e.g., 10). Otherwise, we simply encode the delta without using the arithmetic encoder in order to avoid maintaining a large probability table for the arithmetic encoder. We found that most of delta values (e.g., more than 50%) are within the threshold of Encoding Triangle Indices The Left of leaf nodes contains a triangle index. To encode triangle indices of leaf nodes, we design two different compression methods that explicitly or implicitly exploit the connectivity of a mesh. Explicit utilization of the mesh connectivity: Our first method is to explicitly utilize the underlying mesh connectivity. We encode triangle indices when we encounter leaf nodes during sequentially accessing BV nodes in the BV layout. For each encoded triangle index of a triangle t, we compute three indices of neighboring triangles sharing one of edges of the triangle t and store them in a cache. Then, for the triangle index of a next leaf node, we attempt to encode the triangle index among three triangle indices stored in the cache. If the triangle index is not in the cache, we decompose the triangle index into a pair index assuming that there are virtual clusters in the mesh. We assume that the virtual mesh clusters contain 4K consecutive triangles in the mesh layout. We also encode the cluster index of the pair index in the context of virtual clusters that have been encoded during compressing a cluster. We found that this method works well and about 50% of triangles indices of leaf nodes can be encoded by the small cache holding three previous neighboring triangle indices. However, we found that computing three neighboring triangles of a triangle requires expensive computation time of constructing mesh connectivity, which is undesirable for efficient random access at runtime. Implicit utilization mesh connectivity: In order to support efficient decompression and high compression ratio, we propose to use a simple delta coding method. We found that the difference between the previous and the current triangle indices is typically small when layouts of a BVH and a mesh have high coherence. Therefore, we encode the triangle index difference with an arithmetic encoder if the difference is less than a small threshold (e.g., 10). We found that about 80% of the differences are within the threshold of 10 when using cache-efficient layouts. Otherwise, we encode the triangle index by decomposing it into a pair index as mentioned above. This implicit compression method utilizes the underlying layouts of BVHs and meshes having high spatial coherence between neighboring nodes and triangles and works quite well. We found that this implicit method has much lower bits per node (bpn) and, even, shows much faster decompression time. Meta file: In order to support random access on the compressed BVH at runtime, we construct a meta file as we compress a BVH. The meta file has the starting address of each cluster in the compressed BVH and the number of BV nodes assigned to each cluster. Since the meta file takes only a minor portion of the disk space, we store the meta file without any compression. Note that this meta file is constructed progressively as we compress a BVH in one pass. 5 Runtime Decompression Framework In this section we present our runtime decompression framework that transparently supports random access on the compressed BVHs. In-core BV representation: As we decompress BV nodes requested by applications, we store the decompressed BVs as the simple BV representation shown in Listing 1 in the main memory. The major benefit of using this in-core BV representation is that it can directly support random access without any computation overhead. 5.1 BVH Access API In order to allow various applications transparently access our RACBVHs, we support the following BVH access functions: Index GetRootIndex (void): Return the index of the root node of a BVH. BV & GetBV (Index n idx ): Return the BV information given the node index n idx. bool IsLeaf (Index n idx ): Return whether the BV node of the given node index n idx is a leaf. Index GetLeftChildIdx (Index n idx ): Return the index of the left child of the BV node specified with the node index n idx. We also define a similar function for the right child of the node. Index GetTriangleIdx (Index n idx ): Return the triangle index stored at a leaf node specified with the node index n idx. Based on this BVH access API, we can traverse a BVH in a hierarchical manner or access any BV nodes in a random order. 5.2 Runtime BVH Access Framework Our runtime data access framework first reads the meta file. If an application requests a BV node through one of BVH access API (e.g., GetBV ( )), the runtime data access framework identifies a cluster containing the requested data, decompresses it into our incore BV representation, and returns the data to the application. Since clusters have consecutive power-of-two BV nodes, we can compute a cluster index by performing a few bit operations on a given node index. Once a cluster index is computed, we refer to the meta file to acquire the starting address of the cluster on the compressed BVH and, then, we decompress the cluster. Decompressing a cluster: Our decompression process of a cluster is symmetric to the compression process of the cluster. As we read the compressed data of a cluster, we reconstruct the tree structures represented by Left and Right and BV information. The tree structure is reconstructed without extracting any information from other clusters. On the other hand, reconstructing BV information of a node requires BV information of the parent node of the node due to our hierarchical BV compression method. For local roots of a cluster, we cannot reconstruct the BV information of those local roots and their sub-trees if the BV information of parent nodes of those local roots are not available at runtime during decompressing the cluster. We call those nodes that we cannot reconstruct the BV information at the time of decompressing the cluster incomplete nodes. We also call all the rest of the nodes complete nodes. We use a most significant bit of Left to indicate whether a node is incomplete or complete at runtime. For complete nodes, we can reconstruct BV information as we decompress a cluster since their parent BV nodes are available. For each incomplete node, we decompress the differences between the predicted and actual BVs and store them at Min and Max. Also, we store the decompressed parent index at Left instead of computing the left and right indices of the node and storing them at Left and Right. We lazily construct the BV information and tree structures of incomplete nodes based on stored data at the in-core BV representation when they are requested by an application. Papers 0126: RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies Page 5 of 8

6 BV Completion: Suppose that an application requests the BV information of a node n by calling GetBV( ). If the node is a complete node, we can simply return the stored in-core BV representation to the application. If the node is an incomplete node, then we search for a local root, n l, of the incomplete node n. This operation can be easily done by using the parent index stored in the Left of incomplete node n. Then, we force to load a cluster that a parent node of the local root n l is assigned to, if the cluster is not loaded yet. Note that loading of a cluster for the BV completion may require recursive loading of another cluster. Fortunately, in typical hierarchical traversing of BVHs, it is very unlikely that a cluster is not loaded yet when a node located in a subtree of the cluster is already accessed. Once we obtain the BV information of a parent node of the local root n l, we can build the BV information based on the BV difference stored at the Min and Max of those incomplete nodes. We also compute the left and right child indices for the Left and Right. We complete the BV information of all the incomplete nodes of the sub-tree rooted at the local root node n l within the cluster that n l is assigned to. Then, we set those incomplete nodes to be the complete nodes. 5.3 Memory Management In order to handle massive models whose BV nodes and meshes cannot fit into a main memory, we employ a simple memory management. Given a user-defined size of the available main memory, we perform the memory management at the granularity of clusters. We maintain a LRU-list of clusters that have been accessed by our BVH access API. Since updating the LRU-list of clusters is expensive, we update the list only when we encounter a new cluster that is different from the previously accessed cluster. Note that clusters located in lower BVHs are less likely to be reused compared to clusters located in upper portions of BVHs during the BVH traversal. Our simple LRU-list update method implicitly considers this issue since clusters located at upper portions of BVHs are more likely to be updated during the BVH traversal and, thus, are less likely to be unloaded. 6 Results We have implemented our compression, out-of-core runtime decompression methods, and benchmark applications on a 3.0 GHz Intel Core2 Extream-PC with the WindowsXP, 4GB of RAM, and a SATA disk drive with the sequential reading performance of 62 MB per second. Our current implementation uses a single-thread. We set our runtime decompression framework to use no more than 2.3 GB of main memory to cache uncompressed data. Our compression method sequentially reads BVs stored as our in-core AABB representation in a streaming order from a file and preserves its layout. Our method works with any layouts or BVH construction methods. Random-accessible compressed meshes: We employ randomaccessible compressed meshes (RACMs) [Yoon and Lindstrom 2007] to further reduce the storage requirement of meshes, which are used together with BVHs for various applications. We use cache-oblivious layouts for meshes since these layouts have been reported to provide fast I/O access and high cache utilization during random walks on the meshes. We use OpenRACM library 1 for computing RACMs and employ the provided mesh access API to access the compressed meshes. Benchmark models: We have tested our method with various benchmark models including St. Matthew model consisting of 128M triangles (Fig. 1(a)), Lucy model consisting of 28M triangles (Fig. 1(c)), CAD turbine models consisting of 1.8M triangles, and an iso-surface model consisting of 102M triangles (Fig. 1(b)) extracted from a scientific simulation. More detail information about our benchmark models are shown in Table sungeui/openracm Model Tri. Vert. Size (MB) of Size (MB) of Compressed Compressed uncompressed compressed bpn ratio (M) (M) BVH Mesh BVH Mesh Tree BV BVH Mesh St.Matthew : : 1 Iso surface : : 1 Lucy : : 1 CAD turbine : : 1 Table 1: Benchmark Models and Compression Results: Model complexity, compression results, and compression ratios for our benchmark models are shown. Tree indicates tree structures in BVHs and BV for BV information. Our method achieves more than 10:1 compression ratio over the uncompressed BV representation shown in Listing 1. We use 16 bits for the quantization of the BV information, 4K node cluster size, and cache-efficient layouts. 6.1 Compression Results We construct BVHs of our benchmarks and store them in a cachecoherent manner, particularly, cache-efficient layouts [Yoon and Manocha 2006]. We choose this layout since it shows high compression ratio and, more importantly, the best runtime performance among the tested layouts, as we will see later. We use 16 bits for the quantization of the BV information. In this configuration we are able to achieve 23.4 bits per node (bpn) on average for our benchmarks. For the St. Matthew model, our compression method spends 13.7 bpn for encoding BV information and 7.45 bpn for encoding tree structures. Compared to a simple AABB representation, we are able to achieve more than a 10:1 compression ratio in our benchmark models. In addition, we achieve about a 20:1 compression ratio for the tested meshes by using RACMs. As a result, we are able to achieve about 12:1 compression ratio compared to uncompressed BVHs and meshes. Please refer to Table 1 for more detail compression results for the tested benchmarks. We also measure the processing speed of our method. We are able to compress 0.35M nodes per second. However, our decompression method is able to process 1.56M nodes per second when we decompress clusters sequentially. The higher decompression performance is mainly due to the fact that the decompression is a simply reverse process to that of the compression and we do not need to construct various data structures like the hash table that we used during the compression process. 6.2 Benchmark Applications We implement two different applications, ray tracing and collision detection, to verify the benefits of our proposed method. We choose these two applications due to their different access patterns on BVHs. For example, ray tracing typically traverses larger portions of BVHs while collision detection accesses smaller and more localized portions of BVHs. We implement these two applications based on our BVH mesh API. For comparison, we can also set our BVH mesh API to access uncompressed BVHs stored in the disk in the format of our in-core BV representation. Therefore, we use the same application code for accessing both uncompressed and compressed BVHs using our BVH mesh API. Note that applications get the original un-quantized BV information from the stored uncompressed BV nodes. Therefore, applications get more tighter BV information, which can achieve higher culling efficiency during the BVH traversal, compared to using our quantized BVs of the RACB- VHs. Ray tracing: We implement a BVH-based ray tracer [Wald et al. 2007; Lauterbach et al. 2006] for the distributed ray tracing [Cook et al. 1984] using our BVH mesh access API. We also construct BVHs optimized with the surface-area heuristic (SAH) [Wald and Havran 2006], which is a well known method to construct acceleration hierarchies maximizing the performance of ray tracing. The BVH-based ray tracer is tested in three cases: 1) using our random-accessible compressed BVHs (RACBVHs) and the random-accessible compressed meshes (RACMs), 2) using uncompressed BVHs, but using RACMs, and 3) using uncompressed original BVHs and meshes. Papers 0126: RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies Page 6 of 8

7 Relative Rendering Time Uncomp. BVH & Mesh Uncomp. BVH & RACM RACBVH & RACM Frame Number Figure 5: Performance of Ray Tracing St. Matthew Scene: This graph shows the relative rendering time during ray tracing the St. Matthew scene shown in Fig. 1(a). We compare the performance of three different configurations: 1) using the compressed BVH (RACBVH) and compressed mesh (RACM), 2) using RACM, but uncompressed BVH, and 3) using un-compressed BVH and mesh. By using RACBVH and RACM, we are able to achieve 54% and 35% performance improvement on average compared to those of options of 2) and 3). We measure the rendering time during ray tracing the St. Matthew model in the scene setting shown in Fig. 1(a). We use 7 point light sources, reflections, and 3 by 3 stratified sampling. Initially, a viewer is located away from the St. Matthew model and zooms to the face of the model; please refer to the accompanying video for the used animation path. We are able to observe 54% and 35% performance improvement on average and up to 2 times improvement on some of frames over the cases of 2) and 3). Fig. 5 shows the ray tracing time of the tested three different cases. The performance improvement of using RACBVHs and RACMs are mainly due to the reduced I/O time and maintaining high cache-utilization during the BVH traversal. Also, note that our method shows a bit less performance at the frame numbers between 50 and 60, where we zoom in the face of the St. Matthew model. In this case, most of the working set data necessary to perform ray tracing is already located in main memory. Therefore, the overhead of our method, a few bit operations computing cluster indices for each GetBV ( ) call and less tighter BVs due to quantization, lowers the performance of our method over the other tested cases. However, we would like to point out that the overhead of our method is very small (e.g., 3%) compared to using uncompressed BVHs that can fit into the main memory. Therefore, even in the case where all the uncompressed data of BVHs and meshes fits in the main memory, our method is comparable to using the uncompressed data in terms of the runtime performance. We also measure the performance of ray tracing the iso-surface model shown in Fig. 1(b). We use 5 point lights and 3 by 3 stratified sampling. In this configuration, we are able to observe 95% performance improvement over using uncompressed meshes and BVHs. Collision detection: We implement discrete collision detection by traversing BVHs and integrate it for a rigid-body simulation [Mirtich and Canny 1995]. We create a benchmark where we drop the Lucy model on top of the CAD turbine model (see Fig. 1(c)). In this benchmark, we measure the number of intersection tests during the BVH traversal. Due to the less tighter BV caused by the conservative quantization, using RACBVHs performs 3% more intersection tests over using uncompressed BVHs. We also measure the collision detection time with and without using RACBVHs given using uncompressed meshes. We are able to observe up to 3.5:1 and 25% on average performance improvement over using uncompressed meshes and BVHs during the rigid body simulation shown in the accompanying video. 6.3 Analysis The performance of our method can be affected by cluster sizes and original layouts given to our compression method. We discuss the performance of applications using our RACBVHs with different cluster sizes and layouts. Cluster size 512 1K 2K 4K 8K 16K Compression ratio 10.5 : : : : : : 1 Frame time (sec.) Table 2: Cluster Size vs. Performance: This table shows the compression ratio and rendering time of the St. Matthew scene as the function of the cluster size at the scene setting shown in Fig. 1(a). Our method shows rather stable performance for the tested cluster sizes and the best performance when the cluster size is 4K. Cluster size vs. performance: In order to see the performance variance as the function of cluster sizes, we compute different versions of the RACBVHs of the St. Mathew model with different cluster sizes: 0.5K, 1K, 2K, 4K, 8K and 16K nodes. The compression ratios and the performance of ray tracing with the different cluster sizes are shown at Table 2. We found that the performance of ray tracing is not drastically affected among the tested cluster sizes. Note that we achieve higher compression ratio as the cluster size is getting bigger. However, the performance of the ray tracing shows the best performance at cluster size 4K nodes. The main reason of achieving low performance with higher cluster sizes is that we fetch and decompress a large cluster where some of BV nodes may not be used at all and, thus, waste the memory space. Layouts vs. performance: We also compare the performance of applications with different layouts of BVHs. We compute depthfirst, van Emde Boas [van Emde Boas 1977], and cache-efficient layouts [Yoon and Manocha 2006] of our tested benchmark models. Surprisingly, our compression method shows the best compression results with the depth-first layouts. However, we found that cacheefficient layouts show the best runtime performance, followed by van Emde Boas, and depth-first layouts. This is mainly due to the high spatial and cache coherences that the cache-efficient layouts maintain. Detailed performance results with different layouts of ray tracing the ST. Matthew model are shown in Table Comparisons We provide comparison of our method against prior work on reducing sizes of BVHs. Hierarchical quantization methods: QSplat [Rusinkiewicz and Levoy 2000] and Quantized kd-tree [Hubo et al. 2006] employed fixed-rate quantization methods. We also use fixed-rate quantization method and further compress them by using a simple prediction method and encoding prediction errors with a context-aware arithmetic encoder. We choose to use this more aggressive compression method to further reduce the storage requirement of BVHs and lower the expensive I/O data access time, which is getting more expensive. Ray-Strip methods: Recently, Lauterbach et al. [2007] proposed a RayStrip, a compact and coupled hierarchy and mesh representation, for ray tracing and further improved it in a following work [Lauterbach et al. 2008]. Its main idea is to compute a triangle strip and build an balanced implicit spatial kd-tree on the triangle strip. This method provides compact in-core representations. Since this method always uses a complete spatial kd-tree, it may have lower runtime performance compared to ray tracers using optimized hierarchies (e.g., hierarchies optimized with the SAH). Although our method achieves two times more compression ratio and can have better performance due to being able to use optimized BVHs, we believe that some of compression methods employed in the paper can be combined with the Ray-Strip method and may achieve better performance. 7 Conclusion and Future Work We have presented a novel compression and runtime BVH decompression framework that transparently supports random access on the compressed BVHs. Our compression method preserves the original layout of a BVH and sequentially compresses BVs of a BVH. In order to support random access on the compressed BVHs, we decompose an input BVH into a set of clusters, each of which Papers 0126: RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies Page 7 of 8