Dave Ahn (ahn@vec.wfubmc.edu)
Thu, 18 Nov 1999 23:52:01 -0500
I am trying to render a relatively "small" CT dataset, say 512x512x64
unsigned short voxels, on Octane MXE hardware. getBestParameters() is
returning a brick size of 512x512x4 for Octane MXE/Max Impact platform.
This is fine if I don't rotate the volume, but polygonize() creates way
too many polygons if I try to rotate the volume, and it dies with
voIndices::add(): realloc failed after running out of memory on a 512MB
machine. Manually setting the brick size to 256x256x16 is the only way
to render the dataset.
It seems intuitive that a more cubic brick size of 128x128x64 would make
the polygon count more consistent during arbitrary rotations, and the
numbers prove that. However, what effect (if any) does this have on
the render performance after the polygonize() is complete? In other
words, if I cache the polyset, does it matter whether I use 256x256x16
or 128x128x64 brick size?
I realize getBestParameters() simply provides suggestions for best
performance, but perhaps it should be made a bit smarter about returning
more cubic brick sizes, particularly for machines without much TRAM.
Or at least document its limitations in the man page & programmer guide.
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?
Thanks in advance.
Regards,
Dave
--
Dave Ahn <ahn@vec.wfubmc.edu> | "When you were born, you cried and the
| world rejoiced. Try to live your life
Virtual Endoscopy Center | so that when you die, you will rejoice
Wake Forest Univ. School of Medicine | and the world will cry." -1/2 jj^2
This archive was generated by hypermail 2.0b2 on Fri Nov 19 1999 - 09:07:52 PST