From: Don Burns (don_burns@peru)
Date: 05/12/2000 11:50:46
On May 12, 11:22am, Dave Akers wrote:
> Subject: Re: Performer Node [again]
> > >
> > > hi.
> > >
> > > i'm finally at the point of upgrading Volumizer/Performer applications to
> > > use the most current Volumizer release.
> > >
> > > there's not much documentation with the newest Performer node example.
> > > i can tell that it takes a radically different approach than the
> > > earlier Volumizer/Performer node.
> > >
> > > why is it better?
Not being too familiar with the earlier version of the volumizer node for
Performer, I can tell you what the goals were for this implementation.
1) Make volumizer easy to use
2) Take advantage of Performer's multiprocessor architecture to improve
performance.
I think both goals were accomplished. The node is certainly not an end-all
be-all solution to volumes. However, it does hide some of the complexity of
volumizer, but providing a fairly simple API. I believe a README file was
released with it, or it may have even been a man page, can't remember (Dave?).
pfVolume was also released as a source code example, providing the user a
starting point from which to improve upon. Any improvements or enhancements
are welcomed here.
The second goal was also accomplished in that the most expensive part of
volumizer, polygonization, is done asynchronously in a seperate process. The
Volumizer API functions as a single threaded process. Performer volumizer uses
multiprocessing for polygonization. Polygonization is done transparently to the
programmer.
it's also not at all clear to me that there's an avenue
> > > in the new node for creating an interface for passing data, etc., from
the
> > > computational process to the graphics process (and vise-versa) after
volume
> > > initialization. the earlier Performer node, while cumbersome and not
100%
> > > reliable, has such an interface.
> > >
I'm not quite sure what interface you are referring to here, but please note
that the pfVolume node is derived from pfGroup, and therefore pfNode.
Therefore, it has all the inter-node capabilities as any other pfNode.
-don
> > > thanks.
> > >
> > > --fred
> > > --
> > > Fred Dech fdech@uic.edu
> > > VRMedLab
> > > (312) 413-3092: fax (312) 996-8342
> > > "We'll burn that bridge when we come to it." JL
> >
>-- End of excerpt from Dave Akers
This archive was generated by hypermail 2b29 : Fri May 12 2000 - 13:26:49 PDT