Interactive Isosurface Ray Tracing of Large Octree Volumes

Transcription

1 Interactive Isosurface Ray Tracing of Large Octree Volumes Aaron Knoll, Ingo Wald, Steven Parker, and Charles Hansen Scientific Computing and Imaging Institute University of Utah 2006 IEEE Symposium on Interactive Ray Tracing Salt Lake City, Utah 1

2 Roadmap Motivation Octree volume definition Previous work Algorithm overview Build Traversal Results Conclusions 2

3 Motivation Rendering large volumes is difficult High scene complexity Our solution: ray tracing Large physical memory footprint Richtmyer-Meshkov: 8 GB per timestep, 270 timesteps Our solution: compression via octree volumes 3

4 Why ray trace isosurfaces of large data? Why not mesh extraction? piecewise-linear approximation large data requires adaptive LOD scheme (e.g. Westermann et al. 99) geometric error bound no topological guarantees 4

5 Why ray trace isosurfaces of large data? Why not GPU direct volume rendering? large data also requires LOD (e.g. Guthe et al. 02) singular transfer function is an isosurface approximation incorrect or fuzzy surfaces 5

6 Why ray trace isosurfaces of large data? Ray tracing on the CPU: O(P log T) vs O(T) ray-isosurface intersection guarantees topologically correct implicit (Parker et al. 98) within cell slower, but parallel flexible memory access multiple samples, bounces, advanced shading maybe later! 6

7 Octree volume an octree volume is an adaptive-resolution, spatially hierarchical scalar field. leaf nodes contain scalars interior nodes contain pointers to children data may be computed in this format 7

8 Previous work: Isosurface Ray Tracing Parker et al. 98 hierarchical grid DeMarle et al. 03 hierarchical grid, clusters, DSM Wald et al. 05 kd-tree, coherence 8

9 Previous work: octree acceleration structures General-purpose structures for polygonal geometry Glassner 84, Samet 89, Gargantini & Atkinson 93, etc. For single-ray tracing (late 90 s), hierarchical grids: easier on cache cheap march step With packets (2001-) kd-trees: adapt to geometry amortize stack cost 9

10 Our work: Traversing an octree volume No overlapping primitives Key idea: one octree for both acceleration structure and volume data (cell primitives). No separate memory access costs 10

11 Algorithm overview 1. Octree build (preprocess) Given a 3D array volume, build an octree: voxel data consolidation min/max tree computation 2. Rendering Given a ray, an isovalue, and an octree volume: Traverse octree; skip cells when isovalue is outside min,max range Reconstruct cell from octree voxel data Perform ray-cell intersection test to compute point on isosurface 11

12 Octree build : voxels Our build is bottom-up. Given a scalar field in a 3D array, 12

13 Octree build : voxels Consider voxels of the finest depth, grouped by their parent at the previous depth 13

14 Octree build : voxels Consider voxels of the finest depth, grouped by their parent at the previous depth 14

15 Octree build : voxels Consolidate voxels with variance zero (lossless), or below a certain threshold (lossy) 15

16 Octree build : voxels Consolidate voxels with variance zero (lossless), or below a certain threshold (lossy) 16

17 Octree build : voxels Recursively repeat this process at the parent level... 17

18 Octree build : voxels Only scalar children (leaves) may be consolidated. 18

19 Octree build : voxels Only scalar children (leaves) may be consolidated. 19

20 Octree build : voxels Only scalar children (leaves) may be consolidated. 20

21 Octree build : voxels When the root level is reached, the build is complete. 21

22 Octree build: isovalue clamping What if data is too large even after compression? Lossy compression (nonzero variance threshold) blah. Specify a range of isovalues, and clamp anything outside that range. RMI, t=270: 8 GB full range: 2.4 GB isovalues : 1.8 GB lossless quality for that segmented range 22

23 Octree build : min/max tree The min/max tree is computed alongside voxel consolidation, and stored in the same octree. 22% footprint on top of raw octree voxel data Output: a serviceable acceleration structure for ray tracing. First, consider what we are ray tracing... 23

24 Cell reconstruction concept Octree volume is voxel-centered. Intersection primitives are cells (8 voxels form cell vertices) We need to reconstruct a cell from voxel data Use forward neighbors Observe duality between voxels and cells 24

25 Octree build : min/max tree Since we ray-trace cell primitives, the general idea is to build the min/max tree around cells. We do NOT do this, due to prohibitive footprint. 25

26 Octree build : min/max tree Instead, we begin computing the tree at d_max-1. Further parent nodes: compute min, max of children 26

27 Octree volume implementation octree structure starts at d_max-1 structures are the parents, not voxels themselves cap node at d_max -1 children: 8 finest-level voxels interior node pointer to each child min, max for each child scalar leaves scalar leaf coarser-resolution scalar embedded in parent 27

28 Traversal Start at octree root Given a ray, a parent node, t_enter and t_exit... 28

29 Traversal Compute the ray intersection with the X,Y,Z mid-planes: t_midx, t_midy, t_midz Note: a ray will intersect at most 4 octants 29

30 Traversal Sorted mid-plane intersections gives octant traversal order Bitwise nand, or 0-7 octant index 30

31 Traversal March the ray through those octants in that order. 31

32 Traversal March the ray through those octants in that order. 32

33 Traversal March the ray through those octants in that order. 33

34 Traversal March the ray through those octants in that order. 34

35 Traversal When the ray traverses a non-emtpy child octant, recurse. Separate traversal routines: interior nodes child can be interior, cap or scalar leaf scalar leaves child is always the same scalar leaf only non-empty at forward edges. cap nodes child is a voxel maps to a cell via reconstruction perform ray-cell intersection (Marmitt et al. 03) 35

36 Cell reconstruction: octree hashing How do we find forward neighbors? Octree hashing: point location from root: O(log N) neighbor finding Given an origin and a neighbor destination, 1. find nearest common ancestor 2. perform point location Worst case: O(log N) Best case = average case = O(1) 36

37 Cell reconstruction: octree hashing Frisken & Perry JGT 02 bitwise arithmetic hash scheme each octree node maps to a point P [0, 2 d_max ] 3 N 3 find an octant: bitwise-& with left-shifted mask; interleave X,Y,Z coordinates Interactivity dependent on fast hash scheme optimization: precompute masks, constant interleaving. Both ray traversal and neighbor-finding use this traversal provides path to origin voxel for neighbor-finding 37

38 Ray-isosurface intersection and shading Marmitt et al. 03, Neubauer iterative intersection Cost of cell reconstruction (neighbor-finding) is high forward-difference stencil for gradient normals (same as intersection cell) no deferred normal computation Interactivity is main goal simple Lambertian illumination Future work: centrally-differenced normals (deferred?) phong with shadows global illumination via 3D textures (e.g. Wyman et al. 06) 38

39 Results 39

40 Data Compression data RM (t=150) size 2048x 2048x 1920 preprocess time (*) 3D array octree volume(**) compression 45 min 8.0 GB 1.89 GB 4:1 heptane (full sequence) min 4.11 GB 678 MB 6:1 CTHead sec 14.8 MB 12.4 MB 1.2:1 * Preprocess computation time on a single core of an 2.6 GHz Opteron workstation **Total octree volume footprint, including min/max tree (+22%) 40

41 Memory footprint: comparison to other methods Render-time footprint: octree: 20-30% of uncompressed data size acceleration structure included inherently bricked grid (e.g. Parker et al. 98): bricking for memory coherence: data size +15% 5-deep min/max macrocells: +4.5% kd-tree (e.g. Wald et al. 03): bricking: data size +15% full min/max kd-tree: up to 2x original data size 41

42 FPS: Octree vs Hierarchical Grid traversal grid octree data bricked 3D array (uncompressed) octree volume (compressed) Benchmarks on a 16-core NUMA 2.4 GHz Opteron workstation, 64 GB RAM, frame buffer 42

43 RM Laptop Performance Richtmyer-Meshkov timestep 270 (left), Intel Core Duo 2.16 GHz with 2 GB RAM: 2.4 fps at 5122 comparable to Wald et al. 05 (1.1 fps at 640x480 on dual 1.8 GHz Opteron) faster than DeMarle et al. 03 (2.1 fps at 5122 on a 32-PC cluster with DSM) 43

44 Scalability Scalability, as measured in FPS for the RM 270 scene, on a 16-core NUMA 2.4 GHz Opteron workstation. We test octree volumes, and the Parker et al. 98 grid. Dynamically load-balanced tiles (Bigler et al. RT06) 8 cores: 99% 16 cores: 91% NUMA memory bandwidth an issue, but not a major bottleneck 44

45 Time-variant data Can store and render full sequences of medium-size time-variant data on a PC (4.11 GB 678 MB) Utah CSAFE heptane: fps at

46 Conclusions For the purpose of ray tracing volumes, octree is a good balance of speed, compression Single-ray tracing can render large data with no LOD competitive with packets Limitations not the best all-round volume renderer packets, GPU faster for small-medium data data lookup cost hinders nice shading Future work: packets multiresolution (LOD) better isosurface shading, or direct volume rendering 46

47 Open questions (IMO) Is LOD qualitatively good or bad for volumes? for isosurfaces? Are packets really a win for large data? larger frame buffers, supersampling no primitive-level coherence What shading effects could interactive volume ray tracing provide, that GPU techniques could not? 47

48 Acknowledgments Manta Ray Tracer James Bigler, Abe Stephens colleagues Andrew Kensler, Vincent Pegoraro, Christiaan Gribble, Thiago Ize, Dave DeMarle, Matthias Gross Support: DOE VIEWS 48