From: Fred Dech (fred@cerulean.bvis.uic.edu)
Date: 07/07/2000 14:45:29
Don Burns wrote:
>
> On Jul 7, 3:14pm, Fred Dech wrote:
> > Subject: Performer Node Pole
> > has anyone out there been able to adapt the newest Performer node to do
> > anything actually useful, or am i the only chump who's been beating on this
> > thing and finding a forest full of problems with it?
> >
>
> So, how does one actually respond to that question.... yes?
>
> What are you trying to do? What are the problems you are having with it?
>
oh, hi Don.
yes? yes, indeed.
i was actually directing my question to the volume-rendering user community,
but since you replied i'll tell you some of the problems i've been having.
the handling of textures in the pfGeoState(s), while workable
for a ubyte volume that is small and generates complete bricks, becomes
problematic when dealing with partial bricks, large volumes and different
voxel depths. my personal area of research is with medical data, which is
almost always stored in 2 byte-per-datavalue format.
i eventually figured out that this needed to be reflected in *makeGState()
as something to the effect of:
tex->setFormat( PFTEX_INTERNAL_FORMAT, PFTEX_IA_8);
tex->setFormat( PFTEX_EXTERNAL_FORMAT, PFTEX_PACK_16);
however, i still have artifacts at the end of each Brick. the last few
planes in the Brick appear scrambled. there is also an obaque black plane
at the beginning of each Brick which is backface-culled and whos effects
are confined to the volume. this makes it imperceptable until multiple
bricks are used. in that case, the base of the brick occludes the brick
below it. i've attempted numerous strategies to resolve these two problems,
but have had no luck.
voPartialBrickTypeScope::AUGMENT does not work in this node. and for the
life of me, i haven't been able to figure out why. the partial brick comes
up mapped incorrectly. again, i've made numerous attempts to fix this
problem, but have had no success.
finally. neither
voAppearanceActions::volumeOptimize(
_aVolume, voOptimizeVolumeTypeScope::INTERLEAVE_2WAY);
nor
voAppearanceActions::volumeOptimize(
_aVolume, voOptimizeVolumeTypeScope::BEST_PERFORMANCE);
work in this node. i'm sure it is because of the decoupling of texture
managment from oglVolumizer to native Performer. however, i have no
idea how one would map to texure memory through Performer with an
interleaved brick. interleaving is critical to the work we do here. we
have large datasets and need the ability to double-up on texture memory.
incidentally, we do have an earlier application using the first performer
node which handles all of these issues correctly. i was very interested
in porting to the new, improved Performer node due to its use of pfFluxed
geoSets. but, while i have been able to impliment useful interactivity
from the APP process to the Performer node, i've not been able to display
my data correctly or fast.
--fred
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 15:38:55 PDT