From: Paolo Farinelli (paolo++at++sgi.com)
Date: 02/11/2003 19:38:36
Hi,
Thanks to Steve for pointing out this problem, and to Jean-Christophe
for providing very valuable additional info.
It turns out there is an inconsistency in the implementation of nb_findNode
(also called from within pfLookupNode): The base-class implementation
(pfNode::nb_find) actually carries out an exact type comparison
(pfIsExactType),
while pfGroup::nb_find calls pfIsOfType.
This is the cause of the strange behaviors you are seeing.
To sum up current behavior:
pfLookupNode( nodeName, pfGetNodeClassType() ) and
pfLookupNode( nodeName, pfGetGroupClassType() ),
currently will behave identically, and will only end up finding pfGroups
(and derived
objects) with the given name..
If pfGeodes (or pfBillboards) exist with that same name, they will be
skipped (since
pfNode::nb_find will only succeed if types match exactly).
NOTE that pfLookupNode( nodeName, pfGetNodeClassType() ) could potentially
return a pointer to a pfNode object, but pfNode is an abstract class,
hence this should
never actually happen.
pfLookNode( nodeName, pfGetGeodeClassType() ), however, will only find
pfGeodes
with given name.
Note: objects derived from pfGeode (eg pfBillboard) will not be found
unless
pfLookupNode(nodeName, pfGetBillboardClass() ) is called.
Contrary to what Jean-Christophe stated, the man page for pfFindNode
says that
the type checking performed by pfFindNode is equivalent to pfIsOfType, not
pfIsExactType, e.g. searching for a pfGroup includes derived classes
such as pfSwitch.
I have filed a bug (#881372) regarding this issue, and will fix it for
our next release.
The intended fix is to implement the bahavior documented in the man
page, ie to
always carry out pfIsOfType type-checking.
Setting an environment variable (eg: _PF_NODE_FIND_REQUIRES_EXACT_TYPE)
will allow the current behavior to be restored.
For the moment, I guess Steve could work around this by creating a
pfGroup and
adding the loaded node (which can be a pfGroup or a pfGeode) to this
group, then
assigning a name to this group.. He will then be able to find it through
either
pfLookupNode( nodeName, pfGetNodeClassType() ) or
pfLookupNode( nodeName, pfGetGroupClassType() ),
Hope this helps,
ciao,
Paolo
Jean-Christophe Ulysse wrote:
>Steve Satterfield wrote:
>
>>I am hoping that someone can give me some help with an Inventor loader problem.
>>
>>Summary:
>>
>> I am developing a new file loader on IRIX 6.5.17m with Performer 2.5. Among
>> other things, the loader loads other files. As the other files are loaded,
>> the objects they represent are added to a group node and given a unique
>> name (ASCII string) which is stored with pfNodeName. Within the loader I
>> am writing, these names are later used to find their corresponding node
>> using pfLookupNode and create translated instances to the original objects.
>> The idea is to save space by referring to existing objects rather then
>> re-loading them.
>>
>> The loader I am writing works fine on several of the usual Performer file
>> formats. But it does not work when I use a very simple Inventor file. In
>> that case, the pfLookupNode fails, and the instance is not displayed.
>>
>> Does anyone have any suggestions?
>>
>
>
>Hi Steve,
>
>The way you're using pfLookupNode() with pfGetNodeClassType() is quite
>curious ! In fact, the samples you provided have to don't work... both.
>Actualy, pfLookupNode use the name AND the type to retrieve the right
>object.
>
>First :
>There's a big difference in your samples for performer : when it loads a
>simple iv object, it creates a pfGeode, and when it's a more complicated
>iv model, it creates a pfGroup to enclose the objects. So the roots of
>your
>two samples are not the same type and it's the point !
>
>Second :
>You have to give a right type to pfLookupNode (see man pfFindNode), so
>giving
>the type of "pfNode" can't help.
>
>And to finish :
>Replacing pfGetNodeClassType() by pfGetGeodeClassType() make the first
>sample
>working but not the second, and replacing it by pfGetGroupClassType()
>make the
>second sample working but not the first.
>(I think that if pfGetNodeCl
>assType() succeed in place of
>pfGetGroupClassType(),
>it's a bug).
>
>
>Hope this could help,
>
>
>-----------------------------------------------------------------------
> Jean-Christophe Ulysse
> PhD student in Computer Science
> ISA Team
> Laboratoire Lorrain de Recherche en Informatique et ses Applications
>-----------------------------------------------------------------------
>
>-----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-----------------------------------------------------------------------
>
>
-- Paolo Farinelli paolo++at++sgi.com Member of Technical Staff, OpenGL Performer 1-650-933-1808 Silicon Graphics 1600 Amphitheatre Pkwy, Mountain View, CA 94043
This archive was generated by hypermail 2b29 : Tue Feb 11 2003 - 19:38:46 PST