From: Don Burns (don_burns@peru)
Date: 05/25/2000 13:26:19
>
> hi Dave, Don.
>
> ok. what you describe below sounds do-able. i do have the source for the
> old Performer node. it's actually been heavily modified to suit our pur-
> poses but the basic structure was not changed.
>
> my BIG question. the new Performer node sounds better. i am by no means
> an expert on extending the Performer class structure, so i'm pretty easy
> to convince. but. is it REALLY BETTER? like i said before, to re-develop
> using the new Performer node constitues alot of man-hours.
>
> if you could, please desribe to me briefly (i think alot of the answers are
> imbedded in this thread) what makes the new Performer node superior to the
> old Performer node.
>
Ok.. once again, short and sweet. Two reasons:
1) It is easier to use
2) It takes advantage of multi-processing to do the polygonization
in a parallel process to the drawing process.
-don
> thanks.
>
> --fred
>
> Dave Akers wrote:
> >
> > Hi Fred,
> >
> > Here are my responses to your questions..
> >
> > > here's a list of things that we have implimented or quasi implimented using
> > > the 1st Performer node. we need to be able to do the following things, plus
> > > other not yet implimented proceedures as we continue to develop our software.
> > >
> > > 1. we used OGL clipping planes mainly because i did not find a suitable
> > > analog in Performer. the ability to set and manipulate multiple clipping
> > > planes is a must for our use of Volumizer. it looks like there may be
> > > a way to do this by setting a pfGeoState attribute, but we haven't done
> > > that, and it's not clear to me that Performer has the flexibility of
> > > OGL in this respect. for example, allow a user to select 1 of a number
> > > (i don't recall, i believe OGL supports 5) clipping planes and manipulate
> > > it with respect to the volume.
> >
> > Yes, you're correct that there's no suitable analog for GL clip planes in
> > Performer. We would recommend that you use a channel draw callback to
> > enable the GL clip planes. To pass data to this draw callback you could
> > store user data in shared memory, as was demonstrated for other purposes
> > with the original Performer node part of the 1.1 distribution.
> >
> > You'll want to use pfObject::setUserData() to set the user data pointer on
> > your pfVolume node to a struct in shared memory with the data you need to
> > pass through.. The struct you use as a data container should inherit from
> > pfMemory so that allocation takes place within a shared memory arena. If
> > you need help with this, let us know -- or take a look at the way it
> > worked with the old pfVONode (assuming you still have it..)
> >
> > > 2. as i said earlier, being able to change the color LUT dynamimcally. and
> > > your reply to use pfColortable with the pfGeoState seems very straight-
> > > forward. i wonder if it acts on the geometry in a similar way to
> > > OGLVolumizer voLookupTablePost()?
> >
> > Actually, upon closer examination, pfColortable won't do what you want. It
> > is not a texture lookup table at all, but a color indexing technique to
> > apply on geosets. Sorry about that. :( But you can certainly accomplish
> > lookup tables by using pre- and post- draw callbacks on the pfVolume node.
> > In the pre callback, enable the lookup table and in the post callback,
> > disable it. This way, other nodes in your scene will not be affected by
> > the texture lookup table you've applied to your volume. Make sense? You'll
> > of course need to send the lookup tables from the APP process to the DRAW
> > process using shared memory..
> >
> >
> > > 3. being able to change the threshold value of voDrawActionCache for image
> > > and performance tradeoffs as an application is running is important to us.
> >
> > This should be no problem within the structure provided..
> >
> > > 4. being able to interactively modify voIndexedTetraSet. for example, have
> > > the ability from the APP process to send new values to x_sz, y_sz, z_sz,
> > > x_dev, y_dev, z_dev in the Performer Volumizer node as illustrated in the
> > > fragment below:
> >
> > Should be no problem as well. Just make the modifications to the tetra set
> > in the APP process and new geosets will be created within
> > pfVolume::polygonize().
> >
> > If you need more help, please ask away. :)
> >
> > -Dave
> >
> >
> >
> >
> >
> >
>
>
> --
> Fred Dech fdech@uic.edu
> VRMedLab
> (312) 413-3092: fax (312) 996-8342
> "We'll burn that bridge when we come to it." JL
>
This archive was generated by hypermail 2b29 : Thu May 25 2000 - 13:26:19 PDT