pyopengl-users

[PyOpenGL-Users] glu nurbs problem

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

Hello,
     I'm attempting to use the GLU nurbs functions to display trimmed nurbs,
but have run into some problems.  The first few surfaces I draw display just
fine, but eventually, a GL_STACK_OVERFLOW exception is raised when
gluEndSurface is called.  It doesn't seem to depend on the surface itself.
I get the error whether I display a short list of surfaces many times (e.g.
rotating, etc) or a long list once.  Eventually the stack overflow occurs.
I think the problem is associated with trimming, because if I draw the
surfaces without trimming, the error does not occur.    I'm running Ubuntu
Linux 9.04 (Mesa 7.6 libGLU), Nvidia drivers/core OpenGL, and pyopengl
3.0.0.  I've duplicated the problem on an RHEL 5.4 installation.

Thanks!

Re: [PyOpenGL-Users] glu nurbs problem

[Ian M. <geo...@gm...>]

Hi,

This sounds like a glPushMatrix()/glPopMatrix() issue.  Check to make sure
you aren't pushing something somewhere and not popping it back.

Ian

Re: [PyOpenGL-Users] glu nurbs problem

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

    I thought of that, but the nurbs code is isolated in a small "draw"
method with no matrix manipulation whatsoever (on my part, anyway).  All of
my modelvew code is in another module that has been working in other apps
with no problems for some time.  By default, the GLU nurbs tesselator does a
lot of "level of detail" work - polygon edges are sized in pixels - which
means that it is probably manipulating the matrix stack itself.  That said,
I am doing refinement based on model space, not view space, by calling
glu.gluNurbsProperty(nurb, glu.GLU_SAMPLING_METHOD,
glu.GLU_OBJECT_PATH_LENGTH, so I wouldn't think the matrix stack would come
into play.  It does suggest that I should query the depth of the matrix
stack after each surface is drawn and see if it is getting deeper for some
reason.

Ray


On Mon, Dec 6, 2010 at 8:33 PM, Ian Mallett <geo...@gm...> wrote:

> Hi,
>
> This sounds like a glPushMatrix()/glPopMatrix() issue.  Check to make sure
> you aren't pushing something somewhere and not popping it back.
>
> Ian
>

Re: [PyOpenGL-Users] glu nurbs problem

[Ian M. <geo...@gm...>]

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

Re: [PyOpenGL-Users] glu nurbs problem

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

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
>

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
>>
>
>

Re: [PyOpenGL-Users] glu nurbs problem

[Ian M. <geo...@gm...>]

Hi,

I've never seen this behavior before.  Like ever.  So I'm confused.

You can look at the source, as you're doing.  You may also want to check the
way your do your NURBS setup.  It occurs to me that if something is
happening in that call, it may be because it's not be getting data in an
anticipated way.  In all honesty, I haven't done NURBS rendering in years,
so I'm sorry, but I can't be much help there.

Ian