Re: [PyOpenGL-Users] glu nurbs problem

[Raymond M. <cfd...@gm...>]

I checked the depth of the three matrix stacks just before the call to
gluBeginSurface and just after gluEndSurface(), and they don't change.
modelview depth is 2, projection is 1, and texture is 1 - all exactly what I
would expect them to be for my code.  In addition, here's the actual error
message:

    baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
        err = 1283,
        description = 'stack overflow',
        baseOperation = gluEndSurface,
        cArguments = (
                <OpenGL.GLU.glunurbs.GLUnurbs object ...,
        )

I've been trying to plow through the mesa glu code to try to determine where
the error might be occuring.  Haven't found it yet.

Any ideas are greatly appreciated.

Thanks,
Ray

On Mon, Dec 6, 2010 at 10:39 PM, Raymond Maple <cfd...@gm...>wrote:

> 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.
>
> Ray
>
> 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.gluBeginSurface(nurb)
>         glu.gluNurbsSurface(nurb, self.U1, self.U2, self.Q,
> GL_MAP2_VERTEX_3)
>         for trim in self.trims:
>             glu.gluBeginTrim(nurb)
>             for c in trim:
>                 c.draw(nurb)
>             glu.gluEndTrim(nurb)
>         glu.gluEndSurface(nurb)
>
>
> And in the main app class, something like:
>
>     def draw(self):
>         for s in self.surfaces:
>             s.draw()
>
>
>
> On Mon, Dec 6, 2010 at 9:45 PM, Ian Mallett <geo...@gm...> wrote:
>
>> Hi,
>>
>> 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?
>>
>> Ian
>>
>
>