Re: Best parameters !?

New Message Reply Date view Thread view Subject view Author view

Dave Akers (dla@sgi.com)
Wed, 06 Oct 1999 14:30:34 -0700

As Manfred pointed out, the default behavior of
voAppearanceActions::getBestParameters() is to divide the z brick size repeatedly
until a single brick fits entirely within texture memory. This heuristic works fine
generally, but there are situations where you might want to override it. You can of
course adjust the brick sizes manually yourself, or you could also make use of the
optional [undocumented] last parameter to getBestParameters(), the subdivideMode
integer.

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.

If subdivideMode is 3:
    This alternates between dividing X,Y, and Z sizes by 2 until a single brick fits
in texture memory.

I promise that this will all be better documented in the next version. A word of
caution: be careful to use the default subdivideMode of 1 when you're in 2D mode --
otherwise, strange results will follow. ;)

-Dave

Chikai Ohazama wrote:

> > I'm wondering whether the "getBestParameters" methods really choose the "best"
> > possible parameters. E.g. I tried to visualize a 128 ^ 3 volume on an Indigo2
> > with IMPACT graphics. When I call voAppeareanceActions::getBestParameters with
> > bricktype TRUNCATE I get:
> >
> > voInterpolationType 3D
> > voDataType UNSIGNED_BYTE
> > diskDataFormat LUMINANCE
> > externalFormat LUMINANCE_ALPHA
> > internalFormat LUMINANCE8_ALPHA8_EXT
> > brick sizes 128 128 64
> >
> > Just look at this little calculation.
> >
> > 128 x 128 x 128 x 1 Byte = 2 MB
> >
> > As the volume only defines luminance values it should totaly fit into the
> > available TRAM (4 MB).
>
> You would think this is true, but it's not. The way IMPACT graphics is
> setup you can only have 1 Mtexels in texture memory. So you
> can have a RGBA 128x128x64 volume in memory (which takes up 4 MB) or a
> 128x128x64 LUMINANCE_ALPHA in texture memory (which takes up 2 MB), but
> you cannot have a 128x128x128 LUMINANCE volume since it takes up 2
> Mtexels.
>
> > Another example:
> > When bricking is required the volume seems to be divided only in z direction.
> > This leads to crude differences in the number of polygons within the transient
> > geometry depending on the view direction.
> > When you look along the z-axis each slice is fully contained in a single brick
> > -
> > clipping against brick boundaries doesn't divide this slice.
> > When you look along the x- or y-axis every slice spreads over all of the bricks
> > - you get n pieces of this slice when clipping against the boundaries of n
> > bricks. This effect leads to different time for polygonization and rendering
> > and therefor variing framerates during rotation of the volume.
>
> I can't disagree with you here. I think Dave or Robert G could comment on
> this, discussing the actual algorithm for bricking. If it's really
> affecting performance I would just pick you're own brick size explicitly.
> Also realize that the some of the variations in framerate may also stem
> the from the texture mapping hardware.
>
> Hope this helps.
>
> ________________________________________________________________________
> Chikai J. Ohazama, Ph.D. SGI
> Scientific Visualization 1600 Amphitheatre Pkwy., ms 525
> AGD Applied Engineering Mountain View, CA 94043.1351
> Telephone: (650) 933-6533
> FAX: (650) 932-6533

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed Oct 06 1999 - 16:47:48 PDT