From: Dave Akers (dla@engr.sgi.com)
Date: 05/24/2000 11:21:59
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
This archive was generated by hypermail 2b29 : Wed May 24 2000 - 17:28:34 PDT