1. Cody White Department of Computer Science and Engineering University of Nevada, Reno

2.  Dr. Frederick C. Harris, Jr.  Dr. Sergiu Dascalu  Dr. Scott Bassett  Joe Mahsman

3.  Introduction  Background Work  Our Solution  Implementation  Results  Conclusions and Future Work

4. Department of Computer Science and Engineering University of Nevada, Reno

5.  Approximation of real terrain in a computer simulation  Realistic  Fictional

8.  Photorealistic  Terrain gradients  Coloring  Lighting

9.  Large amount of data  Gigabytes or more  Too big for modern graphics cards ▪ 1.5GB of RAM (nVidia GTX 580)

10.  Much more data than just Mt. Rose  Multiple types of data projections

11.  Many datasets  Some large  Some small

12.  Data streaming  Visibility testing  Level-of-detail (LOD) selection

13.  Objects farther away have less detail  Helps:  Realism  Efficiency

14.  Adapt planar data-caching techniques to a planetary scale  Adapt a LOD scheme for planetary datasets  Utilize the GPU for data composition  Datasets can be added at runtime

15. Department of Computer Science and Engineering University of Nevada, Reno

16.  Texture containing information about the terrain  Heights  Easy to use with the GPU

18. W. De Boer. Fast Terrain Rendering Using Geometrical Mipmapping. October 2000.

19.  Same as heightmap  Contains data about color

20. +

21.  Speedup existing algorithms  Mesh generation 1  Data composition 1 R. Kooima, J. Leigh, A. Johnson, D. Roberts, M.SubbaRao, and T. DeFanti. Planetary-Scale Terrain Composition. IEEE Transactions on Visualization and Computer Graphics. 2009.

22.  Hard-drive to system memory  Based on view  GPU  Store datasets as part of a texture 1  Atlas 1 R. Kooima, J. Leigh, A. Johnson, D. Roberts, M.SubbaRao, and T. DeFanti. Planetary-Scale Terrain Composition. IEEE Transactions on Visualization and Computer Graphics. 2009.

23. Dataset 1 Dataset 2 Dataset 3 Dataset 4 Dataset 5 Dataset 6 Texture containing datasets

24.  Why?  Easy data composition  Efficiency  Stays in GPU memory

25. Department of Computer Science and Engineering University of Nevada, Reno

26. Read data using GDAL Partition data into quadtrees Create BVH Populate runtime BVH Render Interface Start thread for searching Upload patches to GPU Search BVH for data Preprocessing Runtime

27.  Large amounts of data  Need to be processed before runtime  Only happens once  Different instances of the program Read data using GDAL Partition data into quadtrees Create BVH

28. 1. Partition datasets into smaller pieces using GDAL 1 2. Place partitioned datasets into a quadtree hierarchy  Perform mipmapping operations 3. Order datasets into a bounding volume hierarchy (BVH) 1 Geospatial Data Abstraction Library. http://www.gdal.org Read data using GDAL Partition data into quadtrees Create BVH

29.  Extract  Projection coordinates of dataset  Projection information of dataset P2 P1 P4 P3 P5 Read data using GDAL Partition data into quadtrees Create BVH

30.  Store  Lower left coordinate in projection coordinates  Width and height in projection coordinates Width Height L Read data using GDAL Partition data into quadtrees Create BVH

31.  Spatial subdivision hierarchy where all nodes have either zero or four children  Four equal-sized children  Easy mipmapping Read data using GDAL Partition data into quadtrees Create BVH

32.  Bottom-up approach  High-resolution data in the leaves  Lower detail nodes up the tree  Serialize to the hard drive Read data using GDAL Partition data into quadtrees Create BVH

33. Read data using GDAL Partition data into quadtrees Create BVH

34.  Ordered based on geographic location Read data using GDAL Partition data into quadtrees Create BVH

35. 1. Search the BVH for data 2. Determine the LOD 3. Upload data to the GPU 1. Composite the data 4. Perform maintenance 5. Allow for the insertion of new data Composite Search Maintenance Insertion LOD Upload

36.  Frustum-box collision  Test quadtrees iff: 1. Frustum collides 2. Dot product of dataset normal and inverse view > zero  Determine level of tree based on LOD  Preformed by a background thread Composite Search Maintenance Insertion LOD Upload

37.  Error-based metric  Mipmaps introduce error (δ m )  As data gets coarser, error should get higher Composite Search Maintenance Insertion LOD Upload

38.  Need to calculate the error depending on the screen resolution and field of view  S = screen resolution  τ = user-defined threshold  fov = field of view of the camera T. Lauritsen and S. Nielsen. Rendering Very Large, Very Detailed Terrains. 2005 Composite Search Maintenance Insertion LOD Upload

39.  Data uploaded to atlas when available Composite Search Maintenance Insertion LOD Upload

40. Composite Search Maintenance Insertion LOD Upload

41.  Datasets composited on the GPU  For each dataset:  Render center  Screen-aligned quad  Composite into framebuffer object Composite Search Maintenance Insertion LOD Upload

42. Screen-aligned quad Composite Search Maintenance Insertion LOD Upload

43. Width Height L D D = P – L S = (width, height) P (u,v) = D / S Composite Search Maintenance Insertion LOD Upload

44. P Composite Search Maintenance Insertion LOD Upload

45.  Too large for GPU memory to handle  Maintain a list of distances from viewer to each patch  Remove farthest patches  Replace with new, closer patches  Performed by a separate thread Composite Search Maintenance Insertion LOD Upload

46.  User may want to add new data  Move through same preprocessing step with new data  Fit into existing tree  Ready for rendering  Background thread Composite Search Maintenance Insertion LOD Upload

47.  Three types of data:  Height  Color  Normal  Handled by multiple threads

48. Department of Computer Science and Engineering University of Nevada, Reno

49.  Extends Hesperian  Mars  Written in C++  VR and desktop environment

51. Department of Computer Science and Engineering University of Nevada, Reno

52.  Intel Core i7 at 2.8GHz  8 GB of RAM  nVidia GeForce GTX 480  480 cores  1.4MHz per core  1536MB of graphics memory

53.  GPU set to have a maximum atlas of 8192x8192 per data type  Averaged over 10,000 frames  Hesperian as a base

54.  5335.39MB of data NameScale (m/px)WidthHeightSize (MB) MOC Tile 12604.6994096 191.84 MOLA Height1853.00011520 126.56 Victoria Height1.011127916948.27 Select Dataset Information

57.  Flyby from south to north pole

58. SceneData CacherHesperianPercent Different Planetary View127.15118.04+7.7% Olympus Mons127.36115.52+10.2% Flyby107.20111.54-3.89% Average Frames Per Second (FPS)

59.  Flyby scene  Worst case  4.82% of total runtime  Rest in Hesperian ProcessTime (ms)Percent of Runtime Uploading0.064.68% Compositing0.3603.28% Average Timing of Algorithm Steps

63. Department of Computer Science and Engineering University of Nevada, Reno

64.  Presented a data-caching mechanism  Planetary terrain  Hybrid CPU/GPU approach  Insertion of new data  Decoupled from the renderer

65.  Data compression  Laid out differently on hard drive  Global color dataset