Adaptive Real-Time Rendering of Planetary Terrains WSCG 2010 Raphaël Lerbour Jean-Eudes Marvie Pascal Gautron THOMSON R&D, Rennes, France

2 Terrain rendering 2D maps of elevation and color samples 3D applications: games, GPS, virtual tourism…

3 Objectives Render large terrain datasets – Support huge, planetary maps (dozens of GB) – Progressive remote loading context Offer good interactivity – Speed requirements (adaptive rendering) – Real-time hardware 3D rendering Reduce typical visual artifacts due to: – Multi-resolution structure – Planet projection – Limited rendering precision

4 Plan Generic data streaming and selection Application to real-time 3D terrain rendering Planetary terrains Preprocessing Results and conclusion

5 Overview of our work Generic adaptive solution [Lerbour, Marvie, Gautron 2009] – Streaming and rendering of sample maps – Guided by adaptive measure of importance Application to 3D terrain rendering – Support of planetary terrains File server Server database Network Adaptive streaming and selection Partial client database 3D conversion and rendering

6 Hierarchy of square blocks [Levenberg 2002] – Can be progressively loaded as a tree, starting with the root – Hierarchical block selection  minimize amount of rendered blocks Blocks have sets of regular levels of detail (LOD) [De Boer 2000] – Adaptive LOD selection  minimize amount of structure operations Data structure

7 No data redundancy: less to store and transmit – LODs of a block share data (common sample grid) – Parent and children share one LOD (local copy when split/merge) New LOD: samples interleaved between existing ones – Possible to render a block with not all LODs loaded – Possible to render a block and load one of its LODs in parallel

8 Plan Generic data streaming and selection Application to real-time 3D terrain rendering Planetary terrains Preprocessing Results and conclusion

9 Hardware 3D rendering We render 3D geometry with triangles – Conversion from elevation at data reception while rendering continues with previous data – 3D culling with bounding boxes Geometry caching in graphics hardware – Well suited for discrete LODs – Saves memory transfers (up to +40% rendering speed) Sample masks as triangle strips – Applied directly in hardware – Need to solve cracks on block edges

10 Fixing geometry cracks Additional triangle strip masks on block edges – Block with higher definition adapts – No new samples required – Neighbor knowledge: one per edge – No adaptation needed when more than one There are unsolvable cases – Split and merge constraints

11 Texture maps Color maps rendered using textures – 1 LOD = 1 mipmap – Hardware caching and selection Distinct but linked geometry and texture trees – Specific measures of importance – Single texture coordinates mask for all geometry blocks – Only one texture per geometry block: split and merge constraints Data filtering for down-sampling – Improved quality for low definition LODs – Progressive Texture Map [Marvie03]

12 Plan Generic data streaming and selection Application to real-time 3D terrain rendering Planetary terrains Preprocessing Results and conclusion

Modeling a planet Datum to support ellipsoid reference shape Sphere projected onto a bounding cube – Produces square maps – Saves most redundant data compared to classical solution (25% global) – Avoids visual “stretching” on poles 13 Google Earth (global, cylindrical) Our solution (cube, gnomonic)

14 Projection adjustment Base: gnomonic 2D map projection – Fast reverse projection (normalization) – 75% less surface on corners than center New adjusted sampling – Planet surface instead of plane of projection – Steps = independent angles of rotation – Two tangent values computed per sample – 33% less surface on corners than center Plane of projection:

Crack fixing on edges of the cube – Faces specifically numbered and oriented – Implicit and transparent management Runtime adaptive clipping planes – Good rendering precision, from any distance – Culls hidden parts of the planet (behind the horizon) – No additional comparison 15 Solving specific planet issues

16 Plan Generic data streaming and selection Application to real-time 3D terrain rendering Planetary terrains Preprocessing Results and conclusion

Huge input, huge output – Memory constraints for loading input files – Linear writing to output files preferred First step: re-projection of a planetary map – Project specific points of output window to find input window – Recursive output map subdivision – Load input window when fits in memory and re-project samples Preprocessing 17 1 of 6 output gnomonic maps 1 global input cylindric map

Preprocessing Second step: generation of a server database – Direct input window computation – Top-down subdivision into complete tree of blocks – Load input for any sub-tree when fits in memory – Bottom-up construction of block LODs and linear file writing 18 Input mapTree of blocks

19 Plan Generic data streaming and selection Application to real-time 3D terrain rendering Planetary terrains Preprocessing Results and conclusion

Results - preprocessing Support for input and output maps of arbitrary size – Projection on a cube: -25% database size – LOD compression with Zlib: up to -75% database size 20 Puget Sound 1.25 GB 740 MB 2mn SRTM 174 GB TrueMarble 41.7 GB 9h 1h30 5h 35mn 14.9 GB 6.8 GB 31 GB 126 GB

Results – streaming & rendering Tested on GeForce 9800 GTX+, all features turned on – 140 FPS when asking for 2 million triangles 21 Earth database from NASA

Conclusion Application of a generic adaptive solution to 3D rendering of planetary terrains – Optimizations for 3D graphics hardware – Most rendering artifacts avoided – Uniformly sampled planet surface – Improved rendering precision Future work – Fix for popping artifacts (geomorphing) – GPU shaders for fast and flexible 3D conversion – GPU shaders for better texture mapping – avoid constraints – Local coordinate systems for even higher precision Thanks to Kadi Bouatouch, IRISA 22

Any questions? Thomson is looking for Post-doc fellows! Contact: 23