Re: preIsectFunc bad trav matrix
Don Hatch (hatch++at++hell.asd.sgi.com)
Wed, 16 Apr 1997 16:26:43 -0700
On Apr 16, 1:57pm, Steve Baker wrote:
> Subject: Re: preIsectFunc bad trav matrix
>
> Chehayeb, Nassouh <nchehayeb++at++ceit.es> asked:
>
> > this is an example code tha I use to get the node isect matrix In
> > the ISECT process.
> >
> > int vrPoolIsect::preIsectFunc(pfTraverser *trav, void *data)
> > {
> > pfMatrix mat;
> > ...
> > trav->getMat(mat);
> > ...
> > }
> >
> > The node used to set the traverser CB is a pfDCS with a changing matrix,
> > The result of printing is an Ident matrix instead of the dcs matrix at
> > ISECT time.
> >
> > Am I making a mistake or its a Performer bug?
>
> Bernard Leclerc <bleclerc++at++cae.ca> replied:
>
> > If you're using a pre-Isect callback, the DCS matrix is not yet applied.
> > You can change to a post-Isect callback if you're interested in the
> > current transformation matrix after the DCS matrix is applied.
> >
> > However if you're interested in the current value of the DCS matrix, you
> > should do this
> >
> > pfDCS* dcs = (pfDCS*) trav->getNode();
> > dcs->getMat(mat);
>
> ..but that only works for DCS's - what about other kinds of nodes?
>
> I'm pretty sure I've seen this problem in Cull traversals too.
>
> What makes you so sure that the matrix isn't applied until after
> the pre-traversal callback? I could (maybe) understand that in
> the case of a DCS or an SCS, the matrix might be applied somewhere
> between the pre- and post- traversal callbacks, but for (say) a
> regular pfGroup, this should not be a problem...yet (for me at least)
> there *is* a problem.
>
> The man page simply says:
>
> pfGetTravMat sets mat to the current transformation matrix, which is the
> concatenation of the matrices from the root of the scene down to and
> including the current node.
>
> ...it warns you that you can't make this call in a DRAW traversal, but
> for APP, CULL and ISECT traversals, it makes it pretty clear that even
> for DCS and SCS nodes, you can expect to get back a transform that includes
> the current node.
>
> I still think it's a genuine pfBug.
I agree now. That part of the man page was news to me, and my first
assumption was that it was just wrong.
However, looking at the code, I think I see the following (very flaky)
implementation for SCS and DCS:
When called from pre- and post- node APP funcs:
trav->getMat() matrix includes the SCS transformation.
When called from pre- and post- node CULL or ISECT funcs:
trav->getMat() matrix *does not* include the SCS transformation.
When called from pre- and post- node DRAW funcs:
pfGetModelMat() includes the SCS transformation.
Does this explain everyone's problems?
For Performer 2.2, I'll try to get all of them to conform to the man page's
description (i.e. change the CULL and ISECT traversals so that the traverser
matrix will include the node's matrix).
Unfortunately, that means if you
want to write code that works now and will also work later,
you simply can't call trav->getMat()
in the CULL or ISECT node callbacks of an SCS or DCS;
you need to attach the callback
to a node above or below the SCS instead
(depending on which behavior you want).
Don
--
Don Hatch hatch++at++sgi.com (415) 933-5150 Silicon Graphics, Inc.
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:55:05 PDT