From: Fred Dech (fred@cerulean.bvis.uic.edu)
Date: 05/25/2000 12:30:21
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.
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:18:29 PDT