Re: Best parameters !?

New Message Reply Date view Thread view Subject view Author view

Chikai Ohazama (chikai@talula)
Wed, 6 Oct 1999 11:04:23 -0700

> 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 - 12:56:34 PDT