Robert Grzeszczuk (rg@hoek.engr.sgi.com)
Tue, 11 May 1999 10:10:09 -0700 (PDT)
This is indeed a bug. Fortunately, there is a workaround.
History: V1.0 had a bug where the overlap was ignored in computing the
number
of bricks. This was an obscure bug only visible in cases with a large number
of thin bricks (e.g., a 256^3 volume bricked into 256x256x2 bricks with
overlap
of 1 would produce 128 bricks that would cover only half of the volume even
using AUGMENT). This was fixed in V1.1. However, another bug was introduced:
now for volumes that divide evenly into bricks, there is an additional layer
of
1-voxel thick bricks being added in AUGMENT and AUGMENT_TIGHT modes).
You can avoid creation of these additional bricks by articially decrementing
the size of the volume before it is sent into the constructor (but *only* in
AUGMENT and AUGMENT_TIGHT modes) in this common case:
new voBrickSetCollection(
// xVolumeSize, yVolumeSize, zVolumeSize, // REMOVE
xVolumeSize%(xBrickSize-1) == 1 ? xVolumeSize-1 : xVolumeSize, // FIX
yVolumeSize%(yBrickSize-1) == 1 ? yVolumeSize-1 : yVolumeSize, // FIX
zVolumeSize%(zBrickSize-1) == 1 ? zVolumeSize-1 : zVolumeSize, // FIX
xBrickSize, yBrickSize, zBrickSize,
voPartialBrickTypeScope::AUGMENT,
1,
internalFormat,
externalFormat,
dataType,
my_Data.interpolationType);
This is a simple off-by-one error in the voBrickSet::voBrickSet()
constructor,
but happens to be very visible and quite annoying (judging by the traffic on
info-volumizer and personal communitations :-) ). We will likely create a
patch to fix it (as well as another, more serious bug related to download
performance on IR) some time soon. We'll keep you posted.
Sorry for the inconvenience.
-rg
On May 10, 5:58pm, Fred Dech wrote:
> Subject: problem with V1.1
> hi.
>
> we upgraded to Volumizer 1.1 late last week. some applications that use
> voPartialBrickTypeScope::AUGMENT in the voBrickSetCollection constructor
> now either exhibit some unpredictable behavior, or simply don't work.
> if voPartialBrickTypeScope::TRUNCATE is used, they work fine, but, of
course,
> don't process partial bricks.
>
> is this something that others have experienced? if so, is there a
workaround?
>
> thanks.
>
> --fred
> --
> Fred Dech fdech@uic.edu
> VRMedLab
> (312) 413-3092: fax (312) 996-8342
>-- End of excerpt from Fred Dech
This archive was generated by hypermail 2.0b2 on Mon Nov 01 1999 - 13:42:00 PST