Re: [PyOpenGL-Users] glu nurbs problem
Brought to you by:
mcfletch
|
From: Raymond M. <cfd...@gm...> - 2010-12-07 04:39:59
|
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
>
|