Jim Helman (jimh++at++surreal)
Mon, 15 Nov 93 14:12:09 -0800
"fairly" How about "very"?
Currently the maximum depth of the Performer transformation
stack is 64, which compares with GL's 32. So even if we
could traverse it, you probably won't get it past the GL.
Similarly, the OpenGL spec only requires that an
implementation support of a depth of at least 32.
I'm curious what sort of applications require such a deep
transformation hierarchy.
> and get a matrix stack overflow when Performer
> traverses for the cull (this is a modified perfly program).
>
> Performer Warning (9):pfPushMStack: Matrix stack full
>
> it then core dumps.
>
> It seems to be pushing the matrix stack at pfDCS node (and pfGroup
> nodes)
Only at DCSes and SCSes.
> but is not really necessary at each level for our application
> (there are only about 5 max branches in our articulation tree going
> down any one path in the database). so I was wondering how I can
> control Performer's pushing and poping of the matrix stack using the
> node callbacks (to suppress the unnecessary pushes). Does anyone have
> an example of this?
Are you saying that only 5 of the 70 pfDCSes and pfSCSes down any
one path are non-identity transformations? If so, I can only
suggest that you modify the effective topology of your scene
graph. You can either dynamically reparent nodes or place
pfSwitch nodes in parallel to switch between a path that goes
through the DCS and one which goes around it. To avoid the
memory and performance impact of lots of pfSwitch nodes, the same
thing can be done with traversal masks and additional connections
in the existing scene graph. Any of these approaches will return
both the Performer and GL stack depth requirements of the
application to within sane limits.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/390-1151
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:06 PDT