Applying Ground Textures

You can just apply your satellite/aerial texture as one enormous texture map, but there are many problems with this approach:

• you'll probably exceed the limitations of texture size and texture RAM
• when you get close to the ground, it will look bad - usually blurry, due to the magnification filter
• one solution: apply a detail texture

How to tile large textures onto polygonal regions

• the naive approach
  • start with a power-of-2 texture (e.g.. 2048), divide into power-of-2 subsets (e.g.. 1024)
  • map them directly onto the regions, using (u,v) values from (0,0) to (1,1)
  • this results in visible texture seams, due to magnification filter wrap-around
  • seams are minimized but not entirely avoided by using the EDGE CLAMP texture mode
• overlapping tile approach
  • subsets are still power-of-2, but include a single pixel of redundancy on all sides to eliminate the seam
  • the source (full size) texture is no longer a power-of-2
  • the full texture size is n * (patch_size - 1) + 1
    • n is the number of divisions of the original texture
    • e.g.. n = 3 means split into 9 pieces
  • Table: Possible Values for Overlapping Tile Approach
  • vtlib has code to load a very large source texture, subsample to the appropriate full size, and split into a 4x4 array of overlapping regions, each a power-of-2 size
• good summary page: Tiling Textures Without Seams.

Detail Textures / Blending Multiple Ground Textures

Texture Caching and Paging

• good overview of texture caching: Implementing a Texture Caching System, Jonathan Blow, 1998
• Jonathan's more recent and detail paper Terrain Rendering at High Levels of Detail
  • second paper describes one way to do intelligent texture paging
  • pro: details an accurate screen-space metric for texture resolution
  • con: his approach assumes a coherent binary triangle tree (ala ROAM with queues) and access to the camera-space vertex coordinates
• general paging approaches
  1. Quadtree
     • the terrain is divided into a quadtree
     • starting with one texture that covers the entire terrain, child quads are replaced with other textures as needed
     • all texture tiles are the same texels size (e.g. 256*256)
     • some texture RAM is wasted (?) since the lower-resolution quads are present under the higher-resolution children
  2. Array
     • the terrain is divided into a regular grid (N*N) of patches
     • each patch is represented with a stack of textures, very much like mipmaps (1*1, 2*2, 4*4 etc. up to maximum resolution)
     • the number of mipmap levels present for each patch is increased as needed, decreased when acceptable
     • efficient implementation requires incremental mipmap adjustment (an OpenGL 1.2 feature supports this)
  3. Single
     • see Paging Textures and Texture Subloading in SGI's Advanced Graphics Programming Techniques Using OpenGL (1998)
     • clipmapping (see hardware texture support)
     • several implementations claim "clipmapping in software"
• some implementations (e.g. Thatcher Ulrich's Chunked LOD) use the same paging for textures as they do for elevation, by simply dividing and paging the two data sources identically, which can provide a similar kind of support for huge textures
• clipmapping can be reported be simulated in software using multiple textures; several companies have products which claim this
  • As of January 2004, "Performer has integrated sw clipmapping on all its platforms, mainly due now to ATI cards on Irix not having hw support.  MPI Vega has had a sw implementation for a while, Vega Prime also features the same.  Also seen as a single texture only implementation in SiteBuilder3D."
  • Intrinsic Graphics Inc.
    • a startup in Mountain View, was formed by much of SGI's Performer team
    • they had an implementation of clipmapping which claimed to work on any OpenGL card
    • from Intrinsic 99.6.22:
      "Universal Texture is very well working with any OpenGL architecture, and work especially well on UMA (SGI Visual PC).  Both a dual CPU visual PC 320 and an Infinite Reality gives you 60Hz images, but the picture looks much better on the Infinite Reality as the hardware know how to select the right texel on a per pixel basis.
      It has also been tested with a dual CPU NT with a TNT board, and works very well in that configuration too."
    • As of 2007, Intrinsic is long gone, but their spin-off Keyhole lives on as.. some obscure little package called "Google Earth"
  • notes on software clipmapping from Jeffry J. Brickley
  • Hardware-Independent Clipmapping, 2007
    • From a team at University of A Coruña, Spain, published in WSCG 2007
    • Claims that geometry and texture are completely independent, although it's not clear how.  There is a very brief Section 5 on Rendering, but it seems to require that each "geometry set" is mapped to a single texture, which is not independence.  The normal clipmap data layout is used on disk.  In memory, it is a series of regular tiles per detail level.
    • Their implementation (called SANTI) appears to be proprietary with no website.
• Texture Paging with OpenGL
  • Paging Textures from SGI's Programming with OpenGL: Advanced Rendering (1997)
  • Paging Textures in SGI's Advanced Graphics Programming Techniques Using OpenGL (1998) (offline...?)
  • SGI's Texturing Techniques (1997) includes a section on texture paging (offline...?)
  • OpenGL Texture-Mapping With Very Large Datasets and Multi-Resolution Tiles
    • presentation at Siggraph '99 by Paul Hansen

Rendering Textures with OpenGL

typically, you send texture coordinates with glTexCoord, but this involves some amount of computation or storage w/lookup per vertex

• as an alternative, i tried using glTexGen, which is simpler - just set it up and send your vertices
  • it works fine, but on my test platform it was around 5% slower than storing and sending the (u,v) values explicitly
  • this is probably because glTexGen is doing the computation for you, which requires more math instructions (in my case, on the host CPU)
  • probably wouldn't be slower if the math was done on the 3D hardware, and could be faster due to less traffic of sending uv coordinates over the graphics bus