From: Dan Johnston (dan.johnston++at++nrc.ca)
Date: 09/26/2003 09:51:05
>
Yet more follow-up on this problem.
I reduced the number of 'joints' with pfTraversers to less than 32.
According to
the theory below this should have solved the problem. But it didn't. The
12th
traverser that was set up is not being traversed.
Here is the code;
/**
Setup a pfTraverser for this joint. As Performer traverses the
scene graph, this code will cause a callback to be invoked when
the application traversing gets to the joint value node. Then
we can store the current value of the joint in terms of the global
or 'world' position and orientation.
*/
void
AbstractJoint::setupWorldValue( void )
{
// this joint's applications will need a world position set by a
traverser
// our default value for the joint's world position is Identity until
// it is set by the joint traverser
worldPosition = new pfMatrix;
worldPosition->makeIdent();
// set a traverser on the joint DCS, set data to point to this class
object
jointDCS->setTravData( PFTRAV_APP, static_cast<void *>(this));
jointDCS->setTravFuncs( PFTRAV_APP, travCallback, NULL);
cout << "Trav set: joint " << (unsigned int)this << ", func " <<
(unsigned int)travCallback << endl;
}
/**
Callback function for this joint. As Performer traverses the
scene graph, it will issue a callback when it gets to checking this
'joint'. We use the callback to store the current position/orientation
of the joint in world coordinates, i.e. we know Performer has already
done this 'chain' of transform calculations so we just record the
intermediate (and useful to us) result. This result is stored in the
class's world position matrix, using the data supplier by the traverser
to access the class object.
\param trav The pfTraverser class is passed as a standard parameter
for the callback function. The traverser will hold the matrix value
we are searching for (via a trav->getMat()).
\param data A callback parameter that we can use to pass user data
to the callback function. In this case we pass a pointer to the
class so that w can access the class-private data even when the
callback function is declared as a method of this class.
\return the value that tell Performer wether or not to continue
to traverse the scene graph. For this 'grab the matrix' application,
we always want to continue.
*/
int
AbstractJoint::travCallback(pfTraverser *trav, void *data)
{
// store the current joint value (in world coordinates)
// Get an object pointer from the user data for this node
AbstractJoint *pSelf = static_cast<AbstractJoint*>(data);
// if( pSelf->debugFlag )
// cout << "Trav Callback: get world position for joint" << endl;
cout << "Trav Callback: joint " << (unsigned int)pSelf << endl;
// This should never happen...
if( pSelf->worldPosition == NULL )
return PFTRAV_CONT;
/* trav->getMat() will have the transformation to translate from
the world coordinate system into the coordinate system of this
node. We store that in the worldPosition matrix.
*/
trav->getMat(*(pSelf->worldPosition));
// if( pSelf->debugFlag )
// {
// cout << "Set world position for joint" << endl;
// float f0, f1, f2, f3;
// pSelf->worldPosition->getCol( 0, &f0, &f1, &f2, &f3 );
// cout << "mat[0] " << f0 << " " << f1 << " " << f2 << " " << f3 << endl;
// pSelf->worldPosition->getCol( 1, &f0, &f1, &f2, &f3 );
// cout << "mat[1] " << f0 << " " << f1 << " " << f2 << " " << f3 << endl;
// pSelf->worldPosition->getCol( 2, &f0, &f1, &f2, &f3 );
// cout << "mat[2] " << f0 << " " << f1 << " " << f2 << " " << f3 << endl;
// pSelf->worldPosition->getCol( 3, &f0, &f1, &f2, &f3 );
// cout << "mat[3] " << f0 << " " << f1 << " " << f2 << " " << f3 << endl;
// }
// Tell Performer to continue
return PFTRAV_CONT;
}
and here is some output (the joint numbers were added after by me)
0 Trav set: joint 268919080, func 268596096
1 Trav set: joint 268921984, func 268596096
2 Trav set: joint 268925408, func 268596096
3 Trav set: joint 268928832, func 268596096
4 Trav set: joint 268932256, func 268596096
5 Trav set: joint 268935160, func 268596096
6 Trav set: joint 269186896, func 268596096
7 Trav set: joint 269190320, func 268596096
8 Trav set: joint 269193744, func 268596096
9 Trav set: joint 269197168, func 268596096
10 Trav set: joint 268949760, func 268596096
11 Trav set: joint 268953184, func 268596096
12 Trav set: joint 268956608, func 268596096
13 Trav set: joint 268960032, func 268596096
14 Trav set: joint 268963456, func 268596096
15 Trav set: joint 268966880, func 268596096
16 Trav set: joint 268972432, func 268596096
17 Trav set: joint 268975904, func 268596096
18 Trav set: joint 268979376, func 268596096
19 Trav set: joint 268982848, func 268596096
0 Trav Callback: joint 268919080
1 Trav Callback: joint 268921984
2 Trav Callback: joint 268925408
3 Trav Callback: joint 268928832
4 Trav Callback: joint 268932256
5 Trav Callback: joint 268935160
6 Trav Callback: joint 269186896
7 Trav Callback: joint 269190320
8 Trav Callback: joint 269193744
9 Trav Callback: joint 269197168
10 Trav Callback: joint 268949760
12 Trav Callback: joint 268956608
13 Trav Callback: joint 268960032
14 Trav Callback: joint 268963456
15 Trav Callback: joint 268966880
16 Trav Callback: joint 268972432
17 Trav Callback: joint 268975904
18 Trav Callback: joint 268979376
19 Trav Callback: joint 268982848
> This is a follow-up to my own posting.
> Additional information.
>
> It looks like the one pfObject which is not invoking
> the traverser is object number 32 in the list of
> objects that should. The number 32 may be a hint
> to the problem (power of 2, 32 bit flags in an int,
> and so on).
>
> I confirmed that if I stick in an extra, dummy object
> before the problem joint, then I get 40 traverser
> callbacks called out of 41 - but now it was the
> dummy object's callback that was not called.
>
> Hope this extra prods some pfDevelopers to a solution
> to this problem.
>
> Thanks
>
> Dan.Johnston++at++nrc.gc.ca
>
> -------- Original Message --------
> Subject: [info-performer] Why is 1 node (out of 40) not being traversed?
> Date: Tue, 23 Sep 2003 16:59:34 -0230
> From: Dan Johnston <dan.johnston++at++nrc.ca>
> To: info-performer++at++sgi.com
>
> Time to get an idea or two from the group..
>
> I have a C++ class that includes 40 'joints'. Each joint is created
> as a separate class so that I can add features;
>
> For example: a simple 'joint' cointains a DCS to hold the
> joint value. It has children;
> - a switch to control the display of axis geometry. The
> children of the switch are a DCS to scale the axis display,
> a pfArrow for z axis, an SCS to rotate pfArrows to the
> x axis, ax a axis pfArrow, another SCS for the y axis, and
> finally another y axis arrow.
> - another switch to select which 'geometry' is shown for
> this 'joint'. Possible children of this switch are a thin
> cylinder, a thicker one, geometry defined in the config
> file, etc.
>
> Children of a simple 'joint' will attach to the joint value
> DCS. It is only a bit more complicated for the Offset Joint
> class.
>
> As I said. I have 40 of these classes in my superclass.
> One feature of the 'joints' is that they set a Traverser
> on each 'joint value DCS' so that a class method can
> read out the value of the joint in world coordinate values
> (since the pfTraverser will set a matrix with this value
> pre-computed by Performer).
>
> I can see that all 40 'joints' call the same code to
> setTravData ( set to the 'this' pointer so the callback
> can access class data) and then setTravFunc
> to set the callback. I have added a print statement
> so that I see the hex pointer value to all 40 DCSs.
>
> Another print statement in my callback will list out
> (each frame) all the hex address of all the DCSs which
> invoke the callback. I can match 39 of the 40. One
> 'joint' (number 11) never invokes the callback, so it
> never stores a new value for the 'world value' matrix,
> so the matrix is always identity.
>
> Why would this DCS not cause the traverset to be
> called. I did a complete pfPrint dump of the entire
> scene, and verified that the DCS has the correct parent
> and the correct number of children (as does the parent
> of this DCS, and so on) The children which are the
> coordinate axis display can be seen, the 'joint' geometry
> can be switched as desired. But no callback for this one
> DCS - when there are 39 that work just fine!
>
> I do not set any traverser mask values, so the default
> of 'all ones' was active (and confirmed in the pfPrint
> output).
>
> I have checked and re-checked the parent/child
> relationships for all 'joints' and their sub-nodes.
> I need another idea. Any help??
>
> Thanks.
>
--
___|__ |
/ | \ ||\ Daniel (Dan) Johnston
/___|___\ || \ Dan.Johnston++at++nrc.gc.ca
_____|____ || \ National Research Council of Canada, London, ON
| | | || \ Integrated Manufacturing Technologies Institute
\___| | | ||____\ Tel: (519) 430-7081 Fax: (519) 430-7090
\_o_\___|____|_|______\_ Inst: http://www.nrc.gc.ca/imti
\ o / These opinions are my own! Not those of NRC.
\________________/ Virtual Reality:
http://www.nrc.ca/imti/vetc/home.html
More Tall Ships - Fewer Computers!
This archive was generated by hypermail 2b29 : Fri Sep 26 2003 - 09:56:52 PDT