Applying Ground Textures
You can just apply your satellite/aerial texture as one enormous texture map,
but there are many problems with this approach:
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.
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
- 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
- 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)
- Single
- 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
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