Re: Node Callbacks and pfNode derivation

New Message Reply Date view Thread view Subject view Author view

Nicolas Gauvin (nicolas++at++cae.ca)
Mon, 9 Dec 1996 18:12:24 -0500

On Dec 9, 1:50pm, Bryan Wasileski wrote:
> Subject: Node Callbacks
> Performers:
> Another question regarding Node callbacks. I have a class which
> contains an array of pfNode members. The object create from this class
> is allocated from shared memory. In my node callback, I need to know
> which pfNode in the above array is currently being drawn. I use the
> trav->getNode() to get the current node within the callback; I am cannot
> get a "TRUE" comparison result of this node to any of the pfNodes in my
> list from shared memory. How do go about determining which node in the
> list you are drawing?
> thanks.
>

Use pfNodeTravData(node, PFTRAV_DRAW, node) to save your application node
pointer and retrieve it with trav->getData in your draw callback.

You cannot rely on the node returned by trav->getNode because Performer doesn't
really make a traversal of the scene graph when it has reached the draw stage.

What is done in fact is executing a display list built by the cull stage.
This display list no longer contains the notions of node and scene graph, it
contains references to pfGeoSet, explosed pfGeoState and other undocumented
things needed to efficiently draw the primites without the overhead of a
traversal.

Also when multiprocessing, the pointers to the nodes are multibuffered across
the various stages. In other words, the node
pointer in the app and in the cull may not the same! This is done to ensure
frame accuracy of changes made on a node and it is done internally by Performer
so it is transparent to you.

This is why we cannot derive directly from pfNode.
It would involve re-writting those virtual and undocumented nb_functions.
Much like asking the Performer team "Could you give us the Performer source?"
;)

When I started deriving classes from Performer classes I also find it was
a bit of a drag not to be able to derive directly from pfNodes. But then
I saw all the pfUpdatable stuff in pfNode.h and I came to the conclusion that
it was better left alone. I started deriving from pfGroup and everything worked
fine since then.

-- 
Nicolas Gauvin			CAE Electronics Ltd., 8585 Cote De Liesse
Software Developer 		Saint-Laurent, Quebec, Canada, H4L-4X4
3-D Graphics Applications	tel: +1 514 341 2000 extension 2275
nicolas++at++cae.ca			fax: +1 514 340 5496
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:07 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.