Sharon Clay (src++at++rose.engr.sgi.com)
Wed, 2 Jul 1997 12:35:06 -0700
->As I told you in the cull traversal I'm creating a separate display list
->for my shadow volumes. So I've created a descendent of pfGeode which
->contains only shadow volume geometry. It has it's own post & pre cull
->callback.
->
->abbreviated:
->
->static pfDispList *currentDL; // actually a member of my class
->static pfDispList *shadVolDL; // init'd elsewhere
->
->preShadVolCullCallback( ... )
->{
-> currentDL = pfGetCurDList( );
-> currentDL->close( );
-> shadVolDL->open( );
-> return( PFTRAV_CONT );
->}
->
->// in between capture the draw commands for the shadow volume
->// in the shadVolDL
->
->postShadVolCullCallback( ... )
->{
-> shadVolDL->close( );
-> currentDL->open( );
-> return( PFTRAV_CONT );
->}
->
->drawChannelFunc( ... )
->{
-> pfDraw( ); // one extra pop
-> shadVolDL->draw( ); // one extra push
->}
->
->So I temporarily bypass the current display list. Would this not be correct?
->
->What happens is that for some reason a popmatrix() (or apparently the
->token DL_POPMAT) does not get appended to the shadVolDL. It instead gets
->appended to currentDL. So I have an extra pushmatrix() without its
->corresponding popmatrix() in a my shadow volume display list; and I have
->an extra popmatrix() without a cooresponding pushmatrix() in the scene
->display list (this is what I gather from looking at output from gldebug).
->
->It would seem that AFTER the call to preShadVolCullCallback() a
->pushmatrix() is being added, and that AFTER postShadVolCullCallback() a
->popmatrix() is being added. Wouldn't it either be before and after, or
->after and before, but not after and after?
->
->Why would that happen? Obviously I'm not doing things in the right order.
->What would the correct order be?
This looks OK to me so far. We don't arbitrarily stick on push/pop of
matrices so I assume that you have a pfSCS or pfDCS above this node and
you are getting caught by some optimization logic we have in flattening the
scene graph with xforms into the dlist. These matrix ops get tied
to pfGeoSets and are put out with the first pfGeoSet that they affect which
would give you this "after and after" type effect.
This is getting into some ugly details that code inspection does not
verify nearly as well as dbx :-) If you could dbx your cull and put
a breakpoint in your cull callback and then put one in pfPopMatrix()
and send me the stack trace I can be sure. If this is it, I think
a post-draw callback on your pfGeode should do the trick to clean
things out.
This is an interesting case and as it so happens we are currently in
the progress of trying to make such smart cull tricks work a little
better in 2.2 with some node hints since it has come up for other things.
Thanx for your timely post and keep me posted!
src.
--
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
=======================================================================
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:34 PDT