Jim Helman (jimh++at++surreal)
Sat, 20 Nov 93 14:51:43 -0800
1) Is there a way to modify the zwritemask from within performer or do I
have to use a pre/post render callback approach ? With the callback method
would there be any other implications ? How could I minimise the impact of
this mode change if I have a number of geosets that require a modified
zwritemask ?
Callbacks are the way to do it. You can group the affected geodes
together under a single group and set and restore the Z writemask in
its pre- and post- draw callbacks. If the geometry is not spatially
localized, you'll have a cull vs. draw tradeoff to make. One big
pfGroup with geometry from all over the database would minimize the
mode changes, but be detrimental to efficient cull testing.
2) If I want to switch blendfunction on/off dynamically for a number of geosets
depending on a variable set per frame, what is the most performance efficent
way to do this ? The blendfunction may be the only common feature between the
geosets. Would changing the geostate of a parent node while in cull work
reliably when in multiprocess mode ?
Nodes do not have geostates, but if you want to turn on
blendfunction for everthing under a single node, you could turn on
blendfunction in a pre-draw callback and then turn it off in the
post-draw callback. You might also want to change the Performer
transparency mode, since we default to multisample alpha.
3) If I have dynamically changing geometry, performance wise is it better to
write the code in GL or to modify geosets at cull time ? Is there a way to
lock out the render process to allow safe changing of geosets dynamically,
in a multiprocess environment ?
It depends. Doing any computation in the draw process will detract
from rendering throughput. Modifying the geosets in the draw process
could also create problems in multipipe mode, as well as potentially
duplicate work. The best thing to do is to create multiple copies of
the geometry and use a pfSwitch node to cycle among them. This way
all the computations can be done in the application process. See the
code to the lake demo, the water is handled this way. A future release will
have a much slicker way to handle dynamic geometry.
4) When running an a RE what does performer do with the ms alpha mask ? If I
was to modify this dynamically would there be any Performer implications ?
By default, we use multisample alpha rather then blendfunction
transparency since it's faster. We also use msmask() for fade LOD.
Playing with it could affect fade LOD or transparency.
5) Again in a multiprocess environment what would happen if a cull callback
was to delete its node ? Would this throw the app out of skew ?
You can only delete portions of the scene graph safely in 1.2. You
should only create and delete pfNodes in the application process.
6) Is the pfChanData structure the only multiprocess buffered data available ?
Is it possible to use pfNodeTravFuncs data in shared memory to communicate
bewteen associated cull and render callbacks - assuming of course that there
is a way to buffer the data.
As long as the userdata pointer or pfNodeTravData pointers you supply
point to share memory, you can look at them in any process. The
pointers themselves should be set in the application process since
they propagate downstream frame accurately.
7) Is there a way to prepage texture into texture memory dynamically, to avoid
having the huge delay on the first drawing of every texture? Without
having the luxury of being able to load/draw every texture at init time ? I
don't care if it is unsupported or unreliable, anything would be better than
the current situation.
A future release will support texture paging. Currently, when a
texture is needed, it's downloaded. For large textures this can be
time consuming especially on PowerSeries machines. Using smaller
textures will help some since you can spread the download over
several frames.
Like in the perly downloadtextures routine, be sure you have done a
pfApplyTex on all of the textures before hand, even if they won't
all fit in the pipe . This insures that the texdef has been done, the
texture formatted and mipmaps generated.
Also calling pfIdleTex on any textures you know are no longer needed
will also help. This tells the texture manager what can be safely
trashed. Otherwise you might thrash for a while as you overwrite
needed textures. It's best to spread these out over a number of
frames, since pfIdleTex can be slow. This is the approach used by
the Yellowstone Park geospecific terrain flythough shown at TriAda.
If the texture is not mipped and you need to def on the fly as well,
you can do a fast def using the GL's TX_FAST_DEFINE and a texture
already in the correct format. This is how programm like Wade
Olsen's tele do video effects texturing in Performer at 30Hz.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/390-1151
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:06 PDT