From: Fred Dech (fred@cerulean.bvis.uic.edu)
Date: 05/25/2000 12:44:48
Don Burns wrote:
>
> >
> > 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
>
thank you sir. i knew part of #2, although i wasn't sure that the first
Performer Node didn't do this. #1 is subjective, since alot of the
functionality for APP to DRAWING process communication is not there yet.
but the code is definately cleaner...
-fd
> > 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:47:45 PDT