Dave Akers (dla)
Fri, 19 Nov 1999 16:41:44 -0800
Manfred Weiler asked a similar question about a month ago (see
Wednesday, Oct. 6, "Subject: Best Parameters!?" in the archives at
http://reality.sgi.com/Volumizer). It turns out that you can specify an
optional [undocumented] parameter to getBestParameters() that lets you
select how you want the bricks divided up.
If subdivideMode is 1:
This is the default behavior (divides the z dimension by 2 until the
brick fits in texture memory.)
If subdivideMode is 2:
This goes through a loop, dividing the largest dimension by 2 until a
single brick fits in texture memory. ** Sounds like this is what you want
**
If subdivideMode is 3:
This alternates between dividing X,Y, and Z sizes by 2 until a single
brick fits in texture memory.
This will all be better documented in the 1.2 release! A word of caution:
be careful to use the default subdivideMode of 1 when you're in 2D mode --
otherwise, strange results will follow. ;)
> Lastly, could someone cite a good example where reducing the brick size
> a step below what would fit in TRAM (e.g. 128x128x32 vs 128x128x64 on
> MXE) would actually improve performance?
Well, if no other texture objects are being used besides the ones
Volumizer knows about, then there's not much of a difference. But if an
application is making use of other texture objects, then it might make
sense for you to use somewhat smaller brick sizes within Volumizer. Then,
if an external textureBind call causes a Volumizer texture object to be
swapped out, at least it'll be a smaller chunk of texture that gets
swapped out -- not the whole volume. (This assumes that your entire volume
fits in memory -- otherwise, the whole volume gets re-downloaded on every
frame anyway.)
By the way, we are considering implementing techniques which would reduce
(or possibly remove) the memory requirements for transient geometry
storage... More on this soon..
-Dave
This archive was generated by hypermail 2.0b2 on Fri Nov 19 1999 - 19:07:36 PST