Weiblen, Mike (mweiblen++at++wb.com)
12 Dec 1994 14:08:21 U
We've done similar things using 10m SPOT imagery covering large areas of
Nevada.
Mipmapping essentially does texture LODs, but for image quality, not
performance. The highest texture LOD must be in memory to use any of the lower
details. No matter how small a 1024x1024 image appears in the scene, it will
still occupy 2.8MB (1024x1024x2x4/3) of texture memory.
What we do is downsample the imagery, and bind each texture LOD to a separate
geometry LOD that switches at the best distance for texture smoothness. For
each 10240x10240 meter tile in the database, the texture LODs are 16 256x256
images (10m res), 4 256x256 (20m), 1 256x256 (40m), 1 128x128 (80m), and
finally 1 64x64 (160m) image.
This buys three things:
1) we can get far enough from the terrain to see views that would have crashed
the system before. (REs don't like scenes whose texture content exceed texture
memory)
2) the texture is granular so that the RE can page. We texdef all the textures
at startup and have loaded databases containing over 25MB texture and more on
16MB RM5s; the RE pages it in as needed.
3) the database can be represented completely in MultiGen format, and can be
loaded and flown in MaK Stealth, Vega, perfly, and MultiGen.
The downside is that paging textures can have a very jarring effect on frame
rate.
There are other techniques where you can do texture paging/management at the
app level, fastbinding them in anticipation of use. They can provide beautiful
results, and the expense of app complexity and database portability. It
depends on your performance requirement. For us, it is more important not to
customize apps to run a non-portable database.
-- mew
Mike Weiblen (mweiblen++at++wb.com) ARPA War Breaker, Arlington VA 22203
703-908-4358
_______________________________________________________________________________
To: info-performer++at++sgi.com
From: Martin Roth on Mon, Dec 12, 1994 12:56 PM
Subject: Geographical Texture Data
...
the reality of the rendering we are trying to implement a texture mapping of
satellite data on the polygon surface. As you can imagine texture data is
considerably increasing the amount of data to transfer.
At the time we are dealing with three levels of detail. We are working on a
4 Mbyte texture RAM Onyx. In order not to run out of texture RAM it probably
will be inevitable to introduce the concept of LODs into the texturing, too.
Is there an easy (and RAM saving) way to realise texture LODs, eventually
preventing the possibility of incrementally loading higher LODs?
...
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:43 PDT