1. Accelerating Marching Cubes with Graphics Hardware Gunnar Johansson, Linköping University Hamish Carr, University College Dublin

2. Presentation outline Goal Background Previous work Our approach Results Conclusions, Future work

3. Goal Isosurface visualization for studying 3D scalar functions –Marching Cubes is standard algorithm This work presents GPU acceleration in combination with CPU-based algorithmic acceleration (interval/Kd-trees)

4. Background

5. Isosurface visualization Goal: study a volumetric scalar function, f(x) Isosurface is a set of points with equal isovalue (h) { x : f(x) = h } Illustration by Stefan Roettger, University of Erlangen

6. Marching Cubes Each corner of a cube is classified as above (black), or below (white), a given isovalue Vertices of surface is linearly interpolated along the edges Normals are computed using central differences and interpolated along the edges

7. Marching Cubes

8. Example application Studying medical datasets –MRI, CT scans

9. Previous work

10. Previous work Algorithmic acceleration Original marching cubes visits all cells in the dataset –O(N) in time complexity, N = number of cells However, an isosurface is expected to intersect only a fraction of the cells Efficient search structures can be used to store maximum and minimum value of each cell –Kd-tree O(√N + k), k = size of isosurface –Interval tree O(log N + k)

11. Previous work GPU acceleration Restricted to tetrahedral cells –Marching tetrahedra Pascucci, 04 Klein et al, 04 Reck et al, 04 Cannot create/delete vertices on GPU –“Worst-case” strategy –Always fed 4 vertices (a quad) to the GPU

12. Previous work GPU acceleration CPU tasks –Selects cell and sends data to GPU GPU tasks –Classifies cell –Interpolates surface vertices –Compute normals (per face) Bottleneck? –Data transfer CPU – GPU

13. Previous work GPU acceleration Parallel to our work –Goetz et al, “Real-time marching cubes on the vertex shader”, 05 Classifies cell on both CPU and GPU Do not apply interval/Kd-trees Only computes face normals

14. Previous work Traditional pipeline (with accelerating search structures)

15. Previous work GPU accelerated pipeline (by Pascucci / Reck et al / Klein et al)

16. Our approach

17. Marching cubes on GPU: Basic challenges –Cannot create vertices on GPU –Too costly to send all possible triangulations (“worst-case” strategy)

18. Our approach “Caching cell topology” –Store each case triangulation on the GPU using display lists –Classify cell on CPU and invoke corresponding display list –Minimize CPU – GPU bandwidth bottleneck by storing dataset on GPU

19. Our approach “Caching cell topology”

20. Our approach Display list stores corner indices Use indices for texture lookup Use values from texture to interpolate vertices and normals 0 7 6 5 4 3 2 1 (0,1) (0,3) (0,4)

21. Our approach Case classification still a CPU bottleneck?

22. Our approach Accelerate case classification by “pre-computing cell topology” Pre-compute possible cases for each cell Store all intervals with corresponding case in interval or Kd-tree

23. Our approach “Case interval/Kd-tree” –Shifts case classification to pre-computation –Storage requirements increase for noisy dataset (as much as 7 times)

24. Results

25. First approach –Store dataset packed in 2D 1-channel float texture –Central differencing on GPU for normals –Results disappointing 1.2-1.6 speedup for Marching Cubes without accelerating structures Even decrease in speedup when using accelerating structures: GPU bottleneck

26. Results Vertex texture support is currently poor –Only 2D 1/4–channel floats –High latency Central differencing –12 texture lookups per vertex normal 14 lookups in total for each vertex

27. Results Second approach –Pre-compute normals and store dataset and normals packed in 2D 4-channel float texture –Only need 2 lookups for each vertex –Results improved Speedup of 3-4 times compared with CPU counterpart 128x128x128 “Hydrogen atom” dataset –Interval tree + CPU: 27 fps –Interval tree + GPU: 112 fps (4 times speedup)

28. Conclusions Accelerating isosurface extraction using GPU –Cache all possible cell triangulations (cases) –Use CPU for classification –Use GPU for interpolation –Optimize CPU classification by pre-computing all possible cases (case interval/Kd-tree)

29. Conclusions Applicable to any interpolant (in this work described using Marching Cubes) Current hardware impose restrictions –Float textures, high latency for vertex texture lookup

30. Future work Move computation to fragment processor –More powerful than vertex processor –Better, more efficient texture support –Ability to download (to CPU) the extracted surface Optimize memory usage (texture/system) Apply to higher-order interpolants

31. Thank you Acknowledgements: Thanks to UCD for funding