Dirk Luesebrink (crux++at++artcom.de)
Tue, 02 Jul 1996 11:36:06 +0200
yes, its possible. but it has some tricky consequences.
> For example, suppose I have an indexed set of quads.
> What if I determine all visible polygons and rearrange the index array
> to reflect only the visible polygons (assuming the primitive is one color and
> non textured)? I would also change the primitive count to reflect the
> number of primitives in the geoset. Would this approach work?
>
you have to have in mind that and change you apply to the real data in
a geoset is not multibuffered. this is only relevant in multiprocess
mode. for example, if you modify the prim count, it takes immidiate
effect. depending on the timing of app proccess the current draw(which
is up to 2 or 3 frames ahead of the app) or the next draw cycle will use
the new value. you even can loose certain values completly when
timeing is somthing like this
app3 app4
draw1 draw2
then the value set by app3 never will make it to a rendered frame.
(the diagram is not that precise, i know)
same arguments apply to the vertex data or colors and texture data in
the geosets. this results in jumping, jittering simulations.
check out pfCycleBuffer to wrap a multiprocessing save api around
your unbuffered data modifications.
> Would there be a performance loss to changing the geoset?
>
as long as the calculations involved didnt make my app to slow(slower
then the draw), no problem. one concern can be the recomputation
of bounding boxes. Performer can be configuered to automatically
recalculate the BBox when the geometry changes, which can becomes
preformance problem to be done every frame.
> Eric
>
>
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ <--new!
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:07 PDT