Adaptive Real-Time Rendering of Planetary Terrains

1. WSCG 2010 Raphaël LerbourJean-Eudes MarviePascal GautronTHOMSON R&D, Rennes, France Adaptive Real-Time Rendering of Planetary Terrains

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 Network File server Adaptive streaming and selection 3D conversion and rendering • 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 Server database Partial client database

6. Data structure • 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

7. Data structure • 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 receptionwhile 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

13. Modeling a planet Google Earth (global, cylindrical) • Datum to support ellipsoid reference shape • Sphere projected onto a bounding cube • Produces square maps • Saves most redundant data compared toclassical solution (25% global) • Avoids visual “stretching” on poles 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:

15. Solving specific planet issues 0 • 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 1 2 3 4 5

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

17. Preprocessing • 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 1 global input cylindric map 1 of 6 output gnomonic maps

18. 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 Input map Tree of blocks

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

20. 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 740 MB 2mn Puget Sound 1.25 GB 14.9 GB 5h 9h SRTM 174 GB 126 GB 6.8 GB 35mn 1h30 TrueMarble 41.7 GB 31 GB

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

22. Conclusion • Application of a generic adaptive solutionto 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

23. Any questions? Thomson is looking for Post-doc fellows! Contact: jean-eudes.marvie@thomson.net