From: Dave Akers (dla@engr.sgi.com)
Date: 07/19/2000 16:15:18
Hi Fred,
We're working on a way to easily add interleaving support, and we are
looking into the other problems you reported. Things are a bit hectic
around here with SIGGRAPH approaching, but we will let you know ASAP.
-Dave
On Fri, 7 Jul 2000, Fred Dech wrote:
> 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 : Wed Jul 19 2000 - 17:40:35 PDT