Re: documentation clarification

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Fri, 11 Dec 1998 12:28:30 -0800


Robert Wolfe wrote:
>
> Hi,
>
> I am fairly certain that there is an error in the following
> paragraph of manpage doc from pfNode.
> Can somebody identify the error please ?
>
> //////////////////////////////////////////
> The transformation of a pfDCS affects all its children. As the
> hierarchy is traversed from top to bottom, each new matrix is pre-
> multiplied to create the new transformation. For example, if DCSb
> is below DCSa in the scene graph, any geometry G below DCSa is
> transformed as G*DCSb*DCSa.
> /////////////////////////////////////////
>
> What then would be the correct order of multiplication of a point
> defined in the local coordinate system of the geometry G with the
> parent DCSs in order to produce the point in world coordinates ?
>
> (My guess is G*DCSb*DCSa if I have correctly identified the error
> above).

But this is what is stated above, there is no error. You are correct
about the object to world xform. This paragraph is discussing
*modelling*
transformation which is what DCS' & SCS' do, modelling transformation
converts from object to 'world' coords. In OpenGL it is concatenated
with viewing transformation, but performer hides this.

I don't really understand your confusion, you seem to understand the
transformation process.

>
> On another subject, I am also confused by the documentation about
> pfNode::find. See the manpage paragraphs below.
>
> pfNode* pfNode::find(const char *pathName, pfType *type);
>
> //////////////////////////////////////////
> pfNode::find is a general search routine for finding named pfNodes.
> pfNode::find begins searching for the node of type type and identified
> by a '/'-separated path name pathName. The search begins at the pfNode
> and uses a depth-first traversal. pfNode::find returns NULL if it
> cannot find the node. Note that the type checking performed by
> pfNode::find is equivalent to pfMemory::isOfType, not
> pfMemory::isExactType, e.g.
> searching for a pfGroup includes derived classes such as pfSwitch.
>
> The string pathName can be either a name or a '/'-separated pathname.
> If the name contains no '/' characters, it is assumed to be unique and
> the global name table is searched. If pathName contains '/' characters,
> it is assumed to be a path. Paths are searched by first finding the node
> corresponding to the first component of the path in a global name table.
> The find routine then traverses the subtree rooted at that node,
> searching for the rest of the path. The first node encountered during
> the search traversal which matches pathName is returned.
> //////////////////////////////////////////
>
> The first paragraph seems to indicate that any search for a named node
> starts with the subtree indicated by the instance of pfNode calling
> find. If I have two nodes with the same name and a same subtree
> structure both located at the same level in the scene graph,
> then there would not be any ambiguity in finding a same-named child
> of one of those nodes if I have the pointer to the correct parent.
> Is this correct?

Yes, you could search from the parent, find is a node method, and will
searh from a calling object.

>
> The second paragraph seems to indicate that in any case, at least the
> first element of the sought name (either the name without /'s or the
> first component of the pathname with /'s) will be searched for in the
> global name table. This means that identically named nodes at the same
> scene graph level would be indistinguishable to the find method.
>
> Is there a contradiction here between these two paragraphs ?

Ambiguities can exist in a scene graph.
The second paragraph wording does suggest a global search.
There is no contradiction however, the second paragraph draws a
distinction between ordinary names and names with '/' characters.
The potential ambiguity would be where the some name sequence at
the end of a path existed multiple times at the same level but
the motivation for paths is to avoid this very scenario, ie is
using a path you wouldn't put same named trees at one level. Often
however the node under this situation would be the same node, ie
instanced at the root so you'd find the same node.
It does suggest that relative paths are not supported which
doesn't make a lot of sense to me.

  
>
> Any help will be appreciated.
>
> Robert
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 

For advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Fri Dec 11 1998 - 12:28:34 PST

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