Re: again: subclassing pfNode

New Message Reply Date view Thread view Subject view Author view

Steve Baker (steve++at++mred.bgm.link.com)
Mon, 9 Dec 96 11:17:28 -0500


Carsten Scharfe wrote:

> i think my problem was misunderstood.
>
> Subclassing from pfGroup instead of pfNode would
> give the derived Node Class the properties of a pfGroup.
> That is not my aim.

I think I understand what you want - and although it *seems*
reasonable, I'm not sure you'll get it to work in practice.

The problem is that when Performer walks the database tree
for any reason (APP, CULL, ISECT and others need to do this),
they have no idea what to do with your node.

Imagine that CULL is traversing the scene graph, selecting
just those nodes that are in the field of view. Somehow,
it has to know that for pfGroups and their derivatives, it
has to recurse down into the child nodes, and for pfGeodes
and their derivatives, that something different happens.

The trouble with the pfNode abstract class is that it appears
to have no documented public/protected member function for
deciding what CULL should do.

I would have expected there to be a pfNode::cull() member
function, but (at least according to the man page) there
is no such beast. This is a little suprising - but that's
it. Performer doesn't know how to traverse your new node
so you're stuck.

I would definitely suggest that you pick a node like pfGroup
or pfGeode to derive from and suffer the additional penalty.

Steve Baker 817-619-1361 (Vox-Lab)
Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
2200 Arlington Downs Road 817-619-4028 (Fax)
Arlington, Texas. TX 76005-6171 Steve++at++MrEd.bgm.link.com (eMail)
http://www.hti.com (external) http://MrEd.bgm.link.com/staff/steve (intranet)
                                http://web2.airmail.net/sjbaker1 (external)

"You can't destroy the Earth - that's where I keep all my stuff!" - The Tick.

=======================================================================
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.