Version 1.10 of TerraD3D project implementing GPU geometry clipmaps.
Synhtesization and shading changes described in older posts. Many framework changes. There are still some issues as always ;)
TerraD3D report (czech ~3.0MB)
36RSO presentation (czech ~8MB)
Video here (~7.1MB)
TerraD3D v1.10 binary here (~5MB)
TerraD3D v1.10 source here (~49kB)
Doxygen documentation
Showing posts with label TerraD3D. Show all posts
Showing posts with label TerraD3D. Show all posts
Saturday, June 9, 2007
Monday, May 21, 2007
36RSO Project progress 5
Last 2 weeks
- reconsidered height and normal texture packing due to float precision problem and artifacts on clipmap edges
- textures are now separate, no coarse and fine values packing together. It means more texture lookups but solves many problems - use of A32B32G32R32F and packing height value and normal together could be interesting in the future
- camera speed control and fixed updating when moving too fast (still minor bugs)
- TerraD3D automatically uses noise addition to real height data or synthesizes all the levels with perlin noise according to selected synth_levels variable, which can be set from the console
- perlin noise added for complete terrain synthesization. Terrain is synthesized on GPU
- perlin noise functions are implemented as a GPU shader program - thanks to FilouGK http://filougk.blogspot.com/
36RSO presentation (czech ~8MB)
Video here (~7.1MB)
Friday, March 30, 2007
TerraD3D Shading 1 (v1.04)
Implemented two different ways of shading - using normal maps and on-the-fly.
Normal maps define one normal per vertex and are computed during clipmap update. Asirvatham and Hoppe use double resolution normal maps but these form undesirable blocks. Normal maps are computed in vertex shader and rendered to a texture, during rendering the pixel shader simply samples the texture and computes a color. Normal maps require the same amount of video memory as height maps (4 times more for double resolution) but provide very fast way of shading.
The second way is to compute normals on-the-fly in vertex shader reading several height samples (currently 4) to obtain a normal, which is then sent through pipeline to pixel shader. No extra memory is needed but vertex texture lookup is still very expensive and framerate drops down to 50% compared to normal maps. It would be interesting to find out if only 2 extra texture lookups can produce similar shading quality.
Normal maps - close
Normal maps define one normal per vertex and are computed during clipmap update. Asirvatham and Hoppe use double resolution normal maps but these form undesirable blocks. Normal maps are computed in vertex shader and rendered to a texture, during rendering the pixel shader simply samples the texture and computes a color. Normal maps require the same amount of video memory as height maps (4 times more for double resolution) but provide very fast way of shading.
The second way is to compute normals on-the-fly in vertex shader reading several height samples (currently 4) to obtain a normal, which is then sent through pipeline to pixel shader. No extra memory is needed but vertex texture lookup is still very expensive and framerate drops down to 50% compared to normal maps. It would be interesting to find out if only 2 extra texture lookups can produce similar shading quality.
Normal maps - close

On-the-Fly - close

Normal maps - far

On-the-Fly - far

Normal maps form block artifacts at close views, on-the-fly method provides best results with higher vertex density. Blending both methods could be the way to go (http://www.robertwrose.com/cg/terrain/rose-geoclipmaps.pdf).
TerraD3D v1.04 binary here (~4.5MB)
Shading techniques can be changed in console using clipmap.render_texhnique command with parameter render for normal maps and render1 or render2 for on-the-fly method. clipmap.normal_res_double turns on/off double resolution for normal maps.
Thursday, March 22, 2007
TerraD3D
- school project for 36GS and 36SEM
- C++ Win32 Direct3D application
- terrain LOD algorithm based on geometric clipmaps, mainly on their GPU version
- very effective and promising algorithm for today's graphics hardware
- main aspects described in paper (czech) and presentation (czech)
- binary v1.03 here (~4.5MB)



Subscribe to:
Posts (Atom)