Sean Spicer (spicer@bme.stanford.edu)
Wed, 10 Nov 1999 21:07:04 -0800 (PST)
Good questions!
The volumeOptimize() command actually does several different things
depending on the arguments you give it. Most likely what you are seeing
is the result of texture interleaving being performed by the command.
As of the 3696 patch, texture interleaving is done "in place" meaning that
the raw voxel data is re-arranged in such a way that it is not intuitive
to the user where things are any more. (e.g. voxel[10][10][10] may not be
at (10, 10, 10) in the array any more, it may be at [30][0][0] or some
other location. This is an optimization done to improve texture download
performance for specific machine configs and dataset sizes. So the short
answer to your question is that if you want to modify voxel data as you do
in the pseudo code below, don't optimize.
However, voxel modification is an important feature, and the roadmap
for Volumizer shows that this feature will be in the next release (1.2)
and will handle proper addressing of optimized volume objects as well as
unoptimized ones. Dave may even have this already working and tested.
Talk to him (dla@engr.sgi.com).
As for your other question, volumeUnoptimize() was originally provided
solely to de-allocate space which was created by volumeOptimize()...a
problem we found early in Volumizer's development internally at SGI. I'm
not so sure what it's used for now since memory is no longer allocated
within volumeOptimize(). I've not tried to do what you're doing
optimizing and un-optimizing, but I'd be surprised if there was a memory
leak there.
cheers,
sean
On Wed, 10 Nov 1999, Dave Ahn wrote:
> Hello,
>
> I may have uncovered another bug in Volumizer 1.1 + 3696 patch.
>
> I am changing the voxel data in each brick in a brick set collection. All
> other brick properties are the same; only the voxel values are altered.
>
> The pseudo code is:
> [for each brick]
> memcpy(brick->getDataPtr(), dsk_data, data_size)
> voAppearanceActions::dataConvert(brick, brick->getDataPtr(),
> dsk_format);
> voAppearanceActions::dataScaleRange(brick, lo_value, hi_value);
> brick->setDirtyFlag(VO_TRUE);
>
> The code works just fine when the brick collection is unoptimized, as shown:
> http://www.vec.wfubmc.edu/volumizer_bug/vo_unopt.gif
>
> which proves that the voxel copy and dataConvert() are working properly.
>
> However, if the volume had been optimized beforehand using
> voAppearanceActions::volumeOptimize(), then the result has a repeated brick:
> http://www.vec.wfubmc.edu/volumizer_bug/vo_opt.gif
>
> I am calling volumeOptimize() only once after the initial creation and
> voxel load of the brick set collection, and I am not calling volumeUnoptimize()
> followed by another volumeOptimize() after changing the voxel data. I
> shouldn't have to, since I'm marking the brick as dirty.
>
> Is my code incorrect, or is this a bug with texture object updates in
> optimized brick set collections?
>
> My platforms are Max Impact/TRAM and Octane MXE, both running IRIX 6.5.5m.
>
> On a related note, is it legal to optimize, unoptimize, optimize the same
> brick set collection without deleting it? I'm concerned about memory leaks,
> and the documentation is not clear on this.
>
> Thanks in advance,
> 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
>
___________________________________________________________________________
Sean Spicer Stanford University Medical Center
Biomechanical Engineering Division of Vascular Surgery, Suite H3642
Cardiovascular Biomechanics Lab Stanford CA, 94305
Telephone...650.723.1695
Fax.........650.723.8762
http://solvedeath.stanford.edu/~spicer
This archive was generated by hypermail 2.0b2 on Wed Nov 10 1999 - 23:23:35 PST
