Manfred Weiler (mdweiler@immd9.informatik.uni-erlangen.de)
Wed, 6 Oct 1999 12:45:54 +0000
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).
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.
Can anyone give me some insight into the way getBestParameters works and which
aspects the method takes into account to choose these parameters?
Thanks in advance
Manfred.
or
You get a lot rather small small
This leads to
the volume i
and there are 4 MB of TRAM available there is no need for bricking at all.
This archive was generated by hypermail 2.0b2 on Wed Oct 06 1999 - 06:43:27 PDT