Re: Performer Cloned Instanc

New Message Reply Date view Thread view Subject view Author view

Marcus (Marcus++at++multigenuunet.UU.NET)
Mon, 19 Dec 1994 17:10:33 PST

        Reply to: RE>Performer Cloned Instancing
>From: Marco Crocetta <onyx++at++datamat.it>
>Subject: Performer Cloned Instancing
>To: info-performer++at++sgi.com
>Date: Wed, 14 Dec 94 9:32:25 MET
>
>Hi,
>
>I built a model whit MultiGen V.11.
>In this model some objects are instanced more times.
>As you know, when the loader encounters one instance reference bead,
>it make a cloning operation.
>Now, I need to move at run-time some parts of these cloned instances,
>one instance independently from each other.
>In other words, I need to find the specific instance that I have
>to move, and his dynamic parts.
>
>
>The question is:
>How can I find the groups to move ?
>I couldn't find the names of the MultiGen groups that represent
>the instance, even in disabling the scene tree optimization in the loader.
>
>Thanks in Advance
>
>--------------------------
>Marco Crocetta
>DATAMAT SpA, Rome
>E-Mail: onyx++at++datamat.it
>--------------------------

All local instances in the scene graph are pfClones. The original
nodes are *never* attached to the scene graph. As a side effect
of this, the pfNodes that are exported via the Flight loader
callback (say a DOF's pfDCS) will not be found in the scene
graph if they are part of an instanced subtree.

Hmm ... this is weak ... instance loading needs improvement.
It's now on my list of things to do. In the meantime ...

To find all the pfDCS nodes that were cloned because of local
(and external) instancing, you'll have to perform a post load
traversal of the scene graph and look for them by type and
pathname. Assuming PFFLT_CLEAN is disabled (as you said)
, each cloned instanced will have a unique pathname. It'll be a
concatenation of the node names of the unique base nodes plus the
non-unique cloned nodes. You can build the pathname (and matrix
stack) as you traverse down. Still, matching up the cloned pfDCS's
with the corresponding DOF bead information could get complicated.
>From the point of view of the DOF callback, it's a one (bead) to many
(pfNode) relationship.

Regards,
Marcus Barnes, Member Technical Staff
MultiGen Inc., 1884 The Alameda, San Jose CA, 95126
PH: (408) 261 4118 FX: (408) 247 4329
EMAIL: multigen!marcus++at++uunet.UU.NET

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:50:45 PDT

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