Here's the two classes - very simple as this is just experimental code.  The actual data is loaded from IGES files (generated in CATIA V5) that I can't share.  If I comment out the "for trim in self.trims:" loop in TrimmedSurface.draw method, everything runs with no problems.    If I leave in the trims, then the first N surfaces render fine, and the remaining throw the error.   If the list of surfaces is long enough, this happens in a single call to the main app draw method, and as you can see there are no matrix pushes (or any other matrix calls) in this code.   I've verified the surfaces and trims are all OK by drawing each by itself.  (which works, at least for a while)  I've also got one iges file (relatively small) that has never caused the error.  The only difference I've noticed about the file that works and the ones that don't (other than # surfaces and complexity) is that the file that works has knot vectors that range from 0 to 1, while the other files have knot vectors with seemingly random ranges.  All surfaces/curves are simple BSplines (not rational) so I don't need to worry about homogeneous coordinates.


class TrimCurve(object):
    def __init__(self):
        self.p = 0
        self.U = None
        self.Q = None

    def draw(self, nurb):
        glu.gluNurbsCurve(nurb, self.U, self.Q, glu.GLU_MAP1_TRIM_2)

class TrimmedSurface(object):
    def __init__(self):
        self.p1 = 0
        self.p2 = 0
        self.U1 = None
        self.U2 = None
        self.Q = None
        self.nurb = glu.gluNewNurbsRenderer()
        glu.gluNurbsProperty(self.nurb, glu.GLU_SAMPLING_METHOD, glu.GLU_OBJECT_PATH_LENGTH)
        glu.gluNurbsProperty(self.nurb, glu.GLU_SAMPLING_TOLERANCE, 10)
        glu.gluNurbsProperty(self.nurb, glu.GLU_DISPLAY_MODE, glu.GLU_FILL)
        self.trims = []

    def draw(self):
        nurb = self.nurb

        glu.gluNurbsSurface(nurb, self.U1, self.U2, self.Q, GL_MAP2_VERTEX_3)
        for trim in self.trims:
            for c in trim:

And in the main app class, something like:

    def draw(self):
        for s in self.surfaces:

On Mon, Dec 6, 2010 at 9:45 PM, Ian Mallett <> wrote:

As far as I know, there's not another way to get a GL_STACK_OVERFLOW.  Tessellation shouldn't alter the matrix stack. 

So, just to check, completely disabling the function solves the issue?  If it doesn't, your problem isn't there.  Otherwise, can we see the code?