Embed Size (px)
Citation preview
Adaptive Real-Time Rendering of Planetary Terrains
WSCG 2010
Raphaël LerbourJean-Eudes Marvie
Pascal GautronTHOMSON 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
Serverdatabase
Network Adaptivestreaming
and selection
Partial clientdatabase
3D conversionand 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
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
Modeling a planet
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
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 ofprojection:
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
0
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
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 outputgnomonic maps
1 global inputcylindric 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 map Tree 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 Sound1.25 GB 740 MB
2mn
SRTM174 GB
TrueMarble41.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 databasefrom NASA
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
22
