pyopengl-users — Discussion of all PyOpenGL matters.

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

[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

[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...>]

    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,

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

Ian

[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] Odd framebuffer error

[Alejandro S. <as...@gm...>]

On Mon, Dec 6, 2010 at 2:46 PM, Derakon <de...@gm...> wrote:

> After having a few days of not working on this, I came back fresh and
> quickly found the problem. Alejandro was right: I didn't have a valid
> OpenGL context when the framebuffer object was first created. I was
> creating the framebuffer on a class instantiation, when I should have
> been creating it the first time the class paint function is called.
> Problem solved, on to bigger and better problems!
>

Cool! I'm glad you found the problem.

Alejandro.-


>  On Thu, Dec 2, 2010 at 8:37 AM, Derakon <de...@gm...> wrote:
> > The problem I'm running into is with calling glBindFramebuffer, not
> > anything after that. I might have problems with drawing to the
> > framebuffer, but currently I have to way to tell as my program doesn't
> > make it that far. This implies to me that there's some kind of setup
> > step that I'm missing, maybe.
> >
> > I guess my next step is to get my test app running on the Windows side
> > (I went straight from test-app-on-OSX to real-app-on-Windows since I
> > didn't anticipate platform difficulties), and if that works, start
> > figuring out what it's doing differently from the real app.
> >
> > -Chris
> >
> > On Thu, Dec 2, 2010 at 5:16 AM, Mike C. Fletcher <mcf...@vr...>
> wrote:
> >> On 10-11-30 02:40 PM, Derakon wrote:
> >> ...
> >>
> >>> I made a test program that works fine (on my OSX laptop), but I'm
> >>> running into an error when I try to adapt the code to the main program
> >>> (on a considerably more powerful Windows 7 box). Each small texture is
> >>> contained in a Tile class instance, and a single Tile can be placed
> >>> and oriented arbitrarily. Meanwhile, the entire working area is tiled
> >>> with MegaTile instances; Tiles are pre-rendered onto MegaTiles using
> >>> framebuffers as needed. However, I'm getting a 1286 error when I call
> >>> glEnd() after rendering a Tile. From what I can tell this means I
> >>> didn't set up the framebuffer properly, but it looks fine to me. I
> >>> must be missing something.
> >>>
> >> Win32 has some funkiness relating to FBOs, from OpenGLContext's shadow
> >> tutorial:
> >>
> >>            fbo = glGenFramebuffers(1)
> >>            '''It has to be bound to configure it.'''
> >>            glBindFramebuffer(GL_FRAMEBUFFER, fbo )
> >>            '''The texture itself is the same as the last tutorial.'''
> >>            texture = glGenTextures( 1 )
> >>            glBindTexture( GL_TEXTURE_2D, texture )
> >>            glTexImage2D(
> >>                GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT,
> >>                shadowMapSize, shadowMapSize, 0,
> >>                GL_DEPTH_COMPONENT, GL_FLOAT, None
> >>            )
> >>            '''We attach the texture to the FBO's depth attachment
> >> point.  There
> >>            is also a combined depth-stencil attachment point when
> certain
> >>            extensions are available.  We don't actually need a stencil
> >> buffer
> >>            just now, so we can ignore that.
> >>
> >>            The final argument is the "mip-map-level" of the texture,
> >>            which currently always must be 0.
> >>            '''
> >>            glFramebufferTexture2D(
> >>                GL_FRAMEBUFFER,
> >>                GL_DEPTH_ATTACHMENT,
> >>                GL_TEXTURE_2D,
> >>                texture,
> >>                0 #mip-map level...
> >>            )
> >>            if sys.platform == 'win32':
> >>                color = glGenRenderbuffers(1)
> >>                glBindRenderbuffer( GL_RENDERBUFFER, color )
> >>                glRenderbufferStorage(
> >>                    GL_RENDERBUFFER,
> >>                    GL_RGBA,
> >>                    shadowMapSize,
> >>                    shadowMapSize,
> >>                )
> >>                glFramebufferRenderbuffer( GL_FRAMEBUFFER,
> >> GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, color )
> >>                glBindRenderbuffer( GL_RENDERBUFFER, 0 )
> >>            holder = mode.cache.holder(
> >>                light,(fbo,texture),key=key
> >>            )
> >>
> >> don't have time to track down why that was done this morning, but I'd
> >> suspect that's likely where you're getting tripped up.
> >>
> >> HTH,
> >> Mike
> >>
> >> --
> >> ________________________________________________
> >>  Mike C. Fletcher
> >>  Designer, VR Plumber, Coder
> >>  http://www.vrplumber.com
> >>  http://blog.vrplumber.com
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> >> Tap into the largest installed PC base & get more eyes on your game by
> >> optimizing for Intel(R) Graphics Technology. Get started today with the
> >> Intel(R) Software Partner Program. Five $500 cash prizes are up for
> grabs.
> >> http://p.sf.net/sfu/intelisp-dev2dev
> >> _______________________________________________
> >> PyOpenGL Homepage
> >> http://pyopengl.sourceforge.net
> >> _______________________________________________
> >> PyOpenGL-Users mailing list
> >> PyO...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> >>
> >
>
>
> ------------------------------------------------------------------------------
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to
> build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>



-- 
Alejandro Segovia Azapian
Director, Algorithmia: Visualization & Acceleration
http://web.algorithmia.net

Re: [PyOpenGL-Users] Odd framebuffer error

[Derakon <de...@gm...>]

After having a few days of not working on this, I came back fresh and
quickly found the problem. Alejandro was right: I didn't have a valid
OpenGL context when the framebuffer object was first created. I was
creating the framebuffer on a class instantiation, when I should have
been creating it the first time the class paint function is called.
Problem solved, on to bigger and better problems!

Thanks again for all your help, everyone.

-Chris

On Thu, Dec 2, 2010 at 8:37 AM, Derakon <de...@gm...> wrote:
> The problem I'm running into is with calling glBindFramebuffer, not
> anything after that. I might have problems with drawing to the
> framebuffer, but currently I have to way to tell as my program doesn't
> make it that far. This implies to me that there's some kind of setup
> step that I'm missing, maybe.
>
> I guess my next step is to get my test app running on the Windows side
> (I went straight from test-app-on-OSX to real-app-on-Windows since I
> didn't anticipate platform difficulties), and if that works, start
> figuring out what it's doing differently from the real app.
>
> -Chris
>
> On Thu, Dec 2, 2010 at 5:16 AM, Mike C. Fletcher <mcf...@vr...> wrote:
>> On 10-11-30 02:40 PM, Derakon wrote:
>> ...
>>
>>> I made a test program that works fine (on my OSX laptop), but I'm
>>> running into an error when I try to adapt the code to the main program
>>> (on a considerably more powerful Windows 7 box). Each small texture is
>>> contained in a Tile class instance, and a single Tile can be placed
>>> and oriented arbitrarily. Meanwhile, the entire working area is tiled
>>> with MegaTile instances; Tiles are pre-rendered onto MegaTiles using
>>> framebuffers as needed. However, I'm getting a 1286 error when I call
>>> glEnd() after rendering a Tile. From what I can tell this means I
>>> didn't set up the framebuffer properly, but it looks fine to me. I
>>> must be missing something.
>>>
>> Win32 has some funkiness relating to FBOs, from OpenGLContext's shadow
>> tutorial:
>>
>>            fbo = glGenFramebuffers(1)
>>            '''It has to be bound to configure it.'''
>>            glBindFramebuffer(GL_FRAMEBUFFER, fbo )
>>            '''The texture itself is the same as the last tutorial.'''
>>            texture = glGenTextures( 1 )
>>            glBindTexture( GL_TEXTURE_2D, texture )
>>            glTexImage2D(
>>                GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT,
>>                shadowMapSize, shadowMapSize, 0,
>>                GL_DEPTH_COMPONENT, GL_FLOAT, None
>>            )
>>            '''We attach the texture to the FBO's depth attachment
>> point.  There
>>            is also a combined depth-stencil attachment point when certain
>>            extensions are available.  We don't actually need a stencil
>> buffer
>>            just now, so we can ignore that.
>>
>>            The final argument is the "mip-map-level" of the texture,
>>            which currently always must be 0.
>>            '''
>>            glFramebufferTexture2D(
>>                GL_FRAMEBUFFER,
>>                GL_DEPTH_ATTACHMENT,
>>                GL_TEXTURE_2D,
>>                texture,
>>                0 #mip-map level...
>>            )
>>            if sys.platform == 'win32':
>>                color = glGenRenderbuffers(1)
>>                glBindRenderbuffer( GL_RENDERBUFFER, color )
>>                glRenderbufferStorage(
>>                    GL_RENDERBUFFER,
>>                    GL_RGBA,
>>                    shadowMapSize,
>>                    shadowMapSize,
>>                )
>>                glFramebufferRenderbuffer( GL_FRAMEBUFFER,
>> GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, color )
>>                glBindRenderbuffer( GL_RENDERBUFFER, 0 )
>>            holder = mode.cache.holder(
>>                light,(fbo,texture),key=key
>>            )
>>
>> don't have time to track down why that was done this morning, but I'd
>> suspect that's likely where you're getting tripped up.
>>
>> HTH,
>> Mike
>>
>> --
>> ________________________________________________
>>  Mike C. Fletcher
>>  Designer, VR Plumber, Coder
>>  http://www.vrplumber.com
>>  http://blog.vrplumber.com
>>
>>
>> ------------------------------------------------------------------------------
>> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
>> Tap into the largest installed PC base & get more eyes on your game by
>> optimizing for Intel(R) Graphics Technology. Get started today with the
>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
>> http://p.sf.net/sfu/intelisp-dev2dev
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>

Re: [PyOpenGL-Users] Odd framebuffer error

[Derakon <de...@gm...>]

The problem I'm running into is with calling glBindFramebuffer, not
anything after that. I might have problems with drawing to the
framebuffer, but currently I have to way to tell as my program doesn't
make it that far. This implies to me that there's some kind of setup
step that I'm missing, maybe.

I guess my next step is to get my test app running on the Windows side
(I went straight from test-app-on-OSX to real-app-on-Windows since I
didn't anticipate platform difficulties), and if that works, start
figuring out what it's doing differently from the real app.

-Chris

On Thu, Dec 2, 2010 at 5:16 AM, Mike C. Fletcher <mcf...@vr...> wrote:
> On 10-11-30 02:40 PM, Derakon wrote:
> ...
>
>> I made a test program that works fine (on my OSX laptop), but I'm
>> running into an error when I try to adapt the code to the main program
>> (on a considerably more powerful Windows 7 box). Each small texture is
>> contained in a Tile class instance, and a single Tile can be placed
>> and oriented arbitrarily. Meanwhile, the entire working area is tiled
>> with MegaTile instances; Tiles are pre-rendered onto MegaTiles using
>> framebuffers as needed. However, I'm getting a 1286 error when I call
>> glEnd() after rendering a Tile. From what I can tell this means I
>> didn't set up the framebuffer properly, but it looks fine to me. I
>> must be missing something.
>>
> Win32 has some funkiness relating to FBOs, from OpenGLContext's shadow
> tutorial:
>
>            fbo = glGenFramebuffers(1)
>            '''It has to be bound to configure it.'''
>            glBindFramebuffer(GL_FRAMEBUFFER, fbo )
>            '''The texture itself is the same as the last tutorial.'''
>            texture = glGenTextures( 1 )
>            glBindTexture( GL_TEXTURE_2D, texture )
>            glTexImage2D(
>                GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT,
>                shadowMapSize, shadowMapSize, 0,
>                GL_DEPTH_COMPONENT, GL_FLOAT, None
>            )
>            '''We attach the texture to the FBO's depth attachment
> point.  There
>            is also a combined depth-stencil attachment point when certain
>            extensions are available.  We don't actually need a stencil
> buffer
>            just now, so we can ignore that.
>
>            The final argument is the "mip-map-level" of the texture,
>            which currently always must be 0.
>            '''
>            glFramebufferTexture2D(
>                GL_FRAMEBUFFER,
>                GL_DEPTH_ATTACHMENT,
>                GL_TEXTURE_2D,
>                texture,
>                0 #mip-map level...
>            )
>            if sys.platform == 'win32':
>                color = glGenRenderbuffers(1)
>                glBindRenderbuffer( GL_RENDERBUFFER, color )
>                glRenderbufferStorage(
>                    GL_RENDERBUFFER,
>                    GL_RGBA,
>                    shadowMapSize,
>                    shadowMapSize,
>                )
>                glFramebufferRenderbuffer( GL_FRAMEBUFFER,
> GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, color )
>                glBindRenderbuffer( GL_RENDERBUFFER, 0 )
>            holder = mode.cache.holder(
>                light,(fbo,texture),key=key
>            )
>
> don't have time to track down why that was done this morning, but I'd
> suspect that's likely where you're getting tripped up.
>
> HTH,
> Mike
>
> --
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Odd framebuffer error

[Mike C. F. <mcf...@vr...>]

On 10-11-30 02:40 PM, Derakon wrote:
...

> I made a test program that works fine (on my OSX laptop), but I'm
> running into an error when I try to adapt the code to the main program
> (on a considerably more powerful Windows 7 box). Each small texture is
> contained in a Tile class instance, and a single Tile can be placed
> and oriented arbitrarily. Meanwhile, the entire working area is tiled
> with MegaTile instances; Tiles are pre-rendered onto MegaTiles using
> framebuffers as needed. However, I'm getting a 1286 error when I call
> glEnd() after rendering a Tile. From what I can tell this means I
> didn't set up the framebuffer properly, but it looks fine to me. I
> must be missing something.
>   
Win32 has some funkiness relating to FBOs, from OpenGLContext's shadow
tutorial:

            fbo = glGenFramebuffers(1)
            '''It has to be bound to configure it.'''
            glBindFramebuffer(GL_FRAMEBUFFER, fbo )
            '''The texture itself is the same as the last tutorial.'''
            texture = glGenTextures( 1 )
            glBindTexture( GL_TEXTURE_2D, texture )
            glTexImage2D(
                GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT,
                shadowMapSize, shadowMapSize, 0,
                GL_DEPTH_COMPONENT, GL_FLOAT, None
            )
            '''We attach the texture to the FBO's depth attachment
point.  There
            is also a combined depth-stencil attachment point when certain
            extensions are available.  We don't actually need a stencil
buffer
            just now, so we can ignore that.

            The final argument is the "mip-map-level" of the texture,
            which currently always must be 0.
            '''
            glFramebufferTexture2D(
                GL_FRAMEBUFFER,
                GL_DEPTH_ATTACHMENT,
                GL_TEXTURE_2D,
                texture,
                0 #mip-map level...
            )
            if sys.platform == 'win32':
                color = glGenRenderbuffers(1)
                glBindRenderbuffer( GL_RENDERBUFFER, color )
                glRenderbufferStorage(
                    GL_RENDERBUFFER,
                    GL_RGBA,
                    shadowMapSize,
                    shadowMapSize,
                )
                glFramebufferRenderbuffer( GL_FRAMEBUFFER,
GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, color )
                glBindRenderbuffer( GL_RENDERBUFFER, 0 )
            holder = mode.cache.holder(
                light,(fbo,texture),key=key
            )

don't have time to track down why that was done this morning, but I'd
suspect that's likely where you're getting tripped up.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] font options

[Christopher B. <Chr...@no...>]

On 12/1/10 11:27 AM, Jonathan Hartley wrote:
>> I have a Tkinter/Togl/PyOpenGL app and am interested in my options for
>> drawing 2d text in the OpenGL window. Text for heads-up text or labels
>> of entities, maybe tooltip-like prompts. I don't care about supporting
>> arbitrarily fonts, as long as I have one good readable font.

I'm looking at using the wxHTML widget to draw text to an offscreen 
bitmap, then making a texture out of that and rendering it with 
pyOpenGL. That has the advantage of doing basic layout for you: 
linewrapping, simple formatting, etc.

Can you use the TK text widget to render to an off-screen bitmap?

Sorry, I don't have a working sample at this point.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] font options

[Jonathan H. <ta...@ta...>]

Pyglet does font rendering.

I don't know whether Pyglet plays nice with Tkinter / Togl applications. 
Maybe you can give pyglet an OpenGL context to use?

If it *does* work, then you could use any installed font, or font files 
you provide. See classes Label (plain text) and HTMLLabel (formatted 
with layout):
http://www.pyglet.org/doc/api/pyglet.text-module.html

I once borrowed someone else's code (origins lost in the mists of time, 
sorry!) which uses pyglet font rendering to render text to a texture, 
rather than to the screen:
http://code.google.com/p/brokenspell/source/browse/trunk/sinisterducks/label2texture.py

     Jonathan




On 01/12/2010 18:46, Philip Winston wrote:
> I have a Tkinter/Togl/PyOpenGL app and am interested in my options for 
> drawing 2d text in the OpenGL window.  Text for heads-up text or 
> labels of entities, maybe tooltip-like prompts.  I don't care about 
> supporting arbitrarily fonts, as long as I have one good readable font.
>
> Is it possible to use glutBitmapString even though I'm not using GLUT? 
>  Is this a reasonable approach, any tips for speed?
>
> I'd like to keep my dependencies minimal. I saw PyFTGL but wondered if 
> it might be overkill for my needs, and it requires FTGL and FreeType.
>
> -Philip
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App&  Earn a Chance To Win $500!
> Tap into the largest installed PC base&  get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

-- 
Jonathan Hartley      Made of meat.      http://tartley.com
ta...@ta...   +44 7737 062 225   twitter/skype: tartley

[PyOpenGL-Users] font options

[Philip W. <pwi...@gm...>]

I have a Tkinter/Togl/PyOpenGL app and am interested in my options for
drawing 2d text in the OpenGL window.  Text for heads-up text or labels of
entities, maybe tooltip-like prompts.  I don't care about supporting
arbitrarily fonts, as long as I have one good readable font.

Is it possible to use glutBitmapString even though I'm not using GLUT?  Is
this a reasonable approach, any tips for speed?

I'd like to keep my dependencies minimal.  I saw PyFTGL but wondered if it
might be overkill for my needs, and it requires FTGL and FreeType.

-Philip

Re: [PyOpenGL-Users] Odd framebuffer error

[Derakon <de...@gm...>]

Thanks for your response, Alejandro. Answers inline.

On Wed, Dec 1, 2010 at 10:11 AM, Alejandro Segovia <as...@gm...> wrote:
> Hi Derakon,
>
>
> These are just a couple of things you might want to check (if you haven't
> already). From the top of my head, I would expect all of these to trigger
> Invalid Operation errors:
> 1) Since "megaTileFramebuffer" is a global variable, are you sure you are
> calling glGenFramebuffers with a valid OpenGL context? If you make the
> assignment at file scope, this is probably running before the context is
> created. This could trigger an Invalid Operation. Also, try printing
> "megaTileFramebuffer" to the console and make sure it's not 0.

I initialize megaTileFramebuffer to None when the module is loaded,
and only call glGenFramebuffers the first time the buffer is required.
Printing it prints "1".

> 2) Has the texture identified by "self.texture" already been created
> (glGenTextures) when attempting to bind the FBO?

Yes; glGenTextures is called in the class's __init__, well before this point.

> 3) Have you tried using GL_FRAMEBUFFER as the first parameter for
> glFrameBufferTexture2D?

I'm not even making it that far; the program stops at the
glBindFramebuffer call. But yes, I've tried GL_FRAMEBUFFER as well as
GL_DRAW_FRAMEBUFFER.

> 4) This might sound silly, but are you certain this is not being executed
> "inside" a glBegin?

To the best of my ability, I am -- the code calling my stuff is rather
messy, but I don't see anything beforehand that would be setting up a
special context.

> Good luck!
> Alejandro.-

Thanks.
-Chris

Re: [PyOpenGL-Users] Odd framebuffer error

[Alejandro S. <as...@gm...>]

Hi Derakon,

On Wed, Dec 1, 2010 at 3:44 PM, Derakon <de...@gm...> wrote:

> On Tue, Nov 30, 2010 at 12:50 PM, Derakon <de...@gm...> wrote:
> >
> > Ah yes, glGetString(GL_VERSION) reports "1.2 APPLE-1.5.48" on my
> > laptop but "3.2.0" on the Windows box.
> >
> > Guess it's time to try to track down where framebuffers are stored
> > when they aren't in OpenGL.GL.EXT. Thanks for the pointer.
>
> Okay, I've updated the Python OpenGL bindings on the Windows machine,
> and modified my code as follows:
>
> Changed imports:
> - from OpenGL.GL.EXT.framebuffer_object import *
> + from OpenGL.GL.framebufferobjects import *
>
> Main drawing code:
>            # megaTileFramebuffer is a global singleton from
> glGenFramebuffers(1)
>            glBindFramebuffer(GL_DRAW_FRAMEBUFFER,
> megaTileFramebuffer) # error occurs here
>            glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
>                    GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D,
>                     self.texture, 0)
>
>            glViewport(0, 0, megaTilePixelSize, megaTilePixelSize)
>             glMatrixMode(GL_PROJECTION)
>            glLoadIdentity()
>            glOrtho(-.375, viewer.m_w - .375,
>                     -.375, viewer.m_h - .375,
>                    1, -1)
>            glScalef(megaTileScaleFactor, megaTileScaleFactor, 1)
>             glTranslatef(-self.pos[0], -self.pos[1], 0)
>            glMatrixMode(GL_MODELVIEW)
>
>            glEnable(GL_TEXTURE_2D)
>            for tile in newTiles:
>                 print glGetString(GL_VERSION)
>                tile.render(viewBox)
>            glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0)
>
>
> I'm now getting a 1282 error (invalid operation) the first time
> glBindFramebuffer is called. I'm having a devil of a time finding
> examples for how this is supposed to work that are for OpenGL 3, but
> as far as I can tell from the "OpenGL API 3.2 API Quick Reference
> Card" PDF I downloaded, I'm doing this correctly.
>
> I've also tried using GL_FRAMEBUFFER instead of GL_DRAW_FRAMEBUFFER,
> and using self.texture instead of megaTileFramebuffer; either or both
> cause the same error at the same point. It seems like OpenGL just
> doesn't want me to call glBindFramebuffer at that point in execution.
> Is there some kind of preparation I'm supposed to have performed
> first?
>

These are just a couple of things you might want to check (if you haven't
already). From the top of my head, I would expect all of these to trigger
Invalid Operation errors:

1) Since "megaTileFramebuffer" is a global variable, are you sure you are
calling glGenFramebuffers with a valid OpenGL context? If you make the
assignment at file scope, this is probably running before the context is
created. This could trigger an Invalid Operation. Also, try printing
"megaTileFramebuffer" to the console and make sure it's not 0.

2) Has the texture identified by "self.texture" already been created
(glGenTextures) when attempting to bind the FBO?

3) Have you tried using GL_FRAMEBUFFER as the first parameter for
glFrameBufferTexture2D?

4) This might sound silly, but are you certain this is not being executed
"inside" a glBegin?

Good luck!

Alejandro.-

-- 
Alejandro Segovia Azapian
Director, Algorithmia: Visualization & Acceleration
http://web.algorithmia.net

Re: [PyOpenGL-Users] Odd framebuffer error

[Derakon <de...@gm...>]

On Tue, Nov 30, 2010 at 12:50 PM, Derakon <de...@gm...> wrote:
>
> Ah yes, glGetString(GL_VERSION) reports "1.2 APPLE-1.5.48" on my
> laptop but "3.2.0" on the Windows box.
>
> Guess it's time to try to track down where framebuffers are stored
> when they aren't in OpenGL.GL.EXT. Thanks for the pointer.

Okay, I've updated the Python OpenGL bindings on the Windows machine,
and modified my code as follows:

Changed imports:
- from OpenGL.GL.EXT.framebuffer_object import *
+ from OpenGL.GL.framebufferobjects import *

Main drawing code:
            # megaTileFramebuffer is a global singleton from
glGenFramebuffers(1)
            glBindFramebuffer(GL_DRAW_FRAMEBUFFER,
megaTileFramebuffer) # error occurs here
            glFramebufferTexture2D(GL_DRAW_FRAMEBUFFER,
                    GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D,
                    self.texture, 0)

            glViewport(0, 0, megaTilePixelSize, megaTilePixelSize)
            glMatrixMode(GL_PROJECTION)
            glLoadIdentity()
            glOrtho(-.375, viewer.m_w - .375,
                    -.375, viewer.m_h - .375,
                    1, -1)
            glScalef(megaTileScaleFactor, megaTileScaleFactor, 1)
            glTranslatef(-self.pos[0], -self.pos[1], 0)
            glMatrixMode(GL_MODELVIEW)

            glEnable(GL_TEXTURE_2D)
            for tile in newTiles:
                print glGetString(GL_VERSION)
                tile.render(viewBox)
            glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0)


I'm now getting a 1282 error (invalid operation) the first time
glBindFramebuffer is called. I'm having a devil of a time finding
examples for how this is supposed to work that are for OpenGL 3, but
as far as I can tell from the "OpenGL API 3.2 API Quick Reference
Card" PDF I downloaded, I'm doing this correctly.

I've also tried using GL_FRAMEBUFFER instead of GL_DRAW_FRAMEBUFFER,
and using self.texture instead of megaTileFramebuffer; either or both
cause the same error at the same point. It seems like OpenGL just
doesn't want me to call glBindFramebuffer at that point in execution.
Is there some kind of preparation I'm supposed to have performed
first?

-Chris

Re: [PyOpenGL-Users] Odd framebuffer error

[Derakon <de...@gm...>]

On Tue, Nov 30, 2010 at 12:17 PM, Alejandro Segovia <as...@gm...> wrote:
>
> On Tue, Nov 30, 2010 at 5:40 PM, Derakon <de...@gm...> wrote:
>>
>> I made a test program that works fine (on my OSX laptop), but I'm
>> running into an error when I try to adapt the code to the main program
>> (on a considerably more powerful Windows 7 box).
>>
>> (snip)
>>
>> Any ideas what could be causing this? Suggestions on what I should be
>> researching to figure it out?
>
> If I understand correctly, this code is working on your Mac.
> Have you checked the OpenGL version you have available on the Win7 machine?
> Mac OS X is stuck on OpenGL 2.1, so using Framebuffers as extensions is
> okay, but if the Win7 machine has OpenGL 3.0 or greater, you might want to
> look into using "native" Framebuffer support.

Ah yes, glGetString(GL_VERSION) reports "1.2 APPLE-1.5.48" on my
laptop but "3.2.0" on the Windows box.

Guess it's time to try to track down where framebuffers are stored
when they aren't in OpenGL.GL.EXT. Thanks for the pointer.

-Chris

Re: [PyOpenGL-Users] Odd framebuffer error

[Alejandro S. <as...@gm...>]

On Tue, Nov 30, 2010 at 5:40 PM, Derakon <de...@gm...> wrote:

> I have a program that displays large numbers (thousands) of textures,
> with the user able to pan and zoom about the collection. The sheer
> texture count is causing slowdown, so I'm working on adding
> framebuffers which collect many of the textures at low detail levels,
> like taking a photo of a group of photos. Since the individual
> textures never move relative to each other, I can just display the one
> pre-rendered texture instead whenever the user is sufficiently
> zoomed-out.
>
> I made a test program that works fine (on my OSX laptop), but I'm
> running into an error when I try to adapt the code to the main program
> (on a considerably more powerful Windows 7 box). Each small texture is
> contained in a Tile class instance, and a single Tile can be placed
> and oriented arbitrarily. Meanwhile, the entire working area is tiled
> with MegaTile instances; Tiles are pre-rendered onto MegaTiles using
> framebuffers as needed. However, I'm getting a 1286 error when I call
> glEnd() after rendering a Tile. From what I can tell this means I
> didn't set up the framebuffer properly, but it looks fine to me. I
> must be missing something.
>
> Here's the prerendering code in MegaTile:
>
>            glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, self.texture)
>            glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
>                    GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D,
>                    self.texture, 0)
>
>            glViewport(0, 0, megaTilePixelSize, megaTilePixelSize) #
> megaTilePixelSize is 512
>            glMatrixMode(GL_PROJECTION)
>            glLoadIdentity()
>            glOrtho(-.375, viewer.m_w - .375, # m_w and m_h are the
> width/height of the window
>                    -.375, viewer.m_h - .375,
>                    1, -1)
>            glScalef(megaTileScaleFactor, megaTileScaleFactor, 1) #
> megaTileScaleFactor is 1/21.0
>            glTranslatef(-self.pos[0], -self.pos[1], 0)
>            glMatrixMode(GL_MODELVIEW)
>
>            glEnable(GL_TEXTURE_2D)
>            for tile in newTiles: # Tile instances to render to MegaTile
>                tile.render(viewBox)
>            glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0)
>
>
> Here's Tile.render():
>
>    def render(self, viewBox):
>        if not self.intersectsBox(viewBox):
>            return
>
>        glColor3f(1, 1, 1)
>
>        theta = N.pi/180 *  self.rotation
>        c = N.cos(theta)
>        s = N.sin(theta)
>        (w,h) = self.size
>        cw = c*w
>        sw = s*w
>        ch = c*h
>        sh = s*h
>
>        img = self.textureData
>        pic_ny, pic_nx = img.shape
>        tex_nx,tex_ny = getTexSize(pic_nx,pic_ny)
>        picTexRatio_x = float(pic_nx) / tex_nx
>        picTexRatio_y = float(pic_ny) / tex_ny
>
>        (x,y) = self.pos
>
>        glBindTexture(GL_TEXTURE_2D, self.texture)
>        glBegin(GL_QUADS)
>        glTexCoord2f(0, 0)
>        glVertex2f(x, y)
>        glTexCoord2f(picTexRatio_x, 0)
>        glVertex2f(x + cw, y + sw)
>        glTexCoord2f(picTexRatio_x, picTexRatio_y)
>        glVertex2f(x + cw - sh, y + sw + ch)
>        glTexCoord2f(0, picTexRatio_y)
>        glVertex2f(x - sh, y + ch)
>        glEnd() # This is where the error triggers
>
>
> Any ideas what could be causing this? Suggestions on what I should be
> researching to figure it out?
>

If I understand correctly, this code is working on your Mac.

Have you checked the OpenGL version you have available on the Win7 machine?
Mac OS X is stuck on OpenGL 2.1, so using Framebuffers as extensions is
okay, but if the Win7 machine has OpenGL 3.0 or greater, you might want to
look into using "native" Framebuffer support.

Good luck!
Alejandro.-


-- 
Alejandro Segovia Azapian
Director, Algorithmia: Visualization & Acceleration
http://web.algorithmia.net

[PyOpenGL-Users] Odd framebuffer error

[Derakon <de...@gm...>]

I have a program that displays large numbers (thousands) of textures,
with the user able to pan and zoom about the collection. The sheer
texture count is causing slowdown, so I'm working on adding
framebuffers which collect many of the textures at low detail levels,
like taking a photo of a group of photos. Since the individual
textures never move relative to each other, I can just display the one
pre-rendered texture instead whenever the user is sufficiently
zoomed-out.

I made a test program that works fine (on my OSX laptop), but I'm
running into an error when I try to adapt the code to the main program
(on a considerably more powerful Windows 7 box). Each small texture is
contained in a Tile class instance, and a single Tile can be placed
and oriented arbitrarily. Meanwhile, the entire working area is tiled
with MegaTile instances; Tiles are pre-rendered onto MegaTiles using
framebuffers as needed. However, I'm getting a 1286 error when I call
glEnd() after rendering a Tile. From what I can tell this means I
didn't set up the framebuffer properly, but it looks fine to me. I
must be missing something.

Here's the prerendering code in MegaTile:

            glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, self.texture)
            glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
                    GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D,
                    self.texture, 0)

            glViewport(0, 0, megaTilePixelSize, megaTilePixelSize) #
megaTilePixelSize is 512
            glMatrixMode(GL_PROJECTION)
            glLoadIdentity()
            glOrtho(-.375, viewer.m_w - .375, # m_w and m_h are the
width/height of the window
                    -.375, viewer.m_h - .375,
                    1, -1)
            glScalef(megaTileScaleFactor, megaTileScaleFactor, 1) #
megaTileScaleFactor is 1/21.0
            glTranslatef(-self.pos[0], -self.pos[1], 0)
            glMatrixMode(GL_MODELVIEW)

            glEnable(GL_TEXTURE_2D)
            for tile in newTiles: # Tile instances to render to MegaTile
                tile.render(viewBox)
            glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0)


Here's Tile.render():

    def render(self, viewBox):
        if not self.intersectsBox(viewBox):
            return

        glColor3f(1, 1, 1)

        theta = N.pi/180 *  self.rotation
        c = N.cos(theta)
        s = N.sin(theta)
        (w,h) = self.size
        cw = c*w
        sw = s*w
        ch = c*h
        sh = s*h

        img = self.textureData
        pic_ny, pic_nx = img.shape
        tex_nx,tex_ny = getTexSize(pic_nx,pic_ny)
        picTexRatio_x = float(pic_nx) / tex_nx
        picTexRatio_y = float(pic_ny) / tex_ny

        (x,y) = self.pos

        glBindTexture(GL_TEXTURE_2D, self.texture)
        glBegin(GL_QUADS)
        glTexCoord2f(0, 0)
        glVertex2f(x, y)
        glTexCoord2f(picTexRatio_x, 0)
        glVertex2f(x + cw, y + sw)
        glTexCoord2f(picTexRatio_x, picTexRatio_y)
        glVertex2f(x + cw - sh, y + sw + ch)
        glTexCoord2f(0, picTexRatio_y)
        glVertex2f(x - sh, y + ch)
        glEnd() # This is where the error triggers


Any ideas what could be causing this? Suggestions on what I should be
researching to figure it out?

-Chris

Re: [PyOpenGL-Users] expected performance vs pyglet

[Mike C. F. <mcf...@vr...>]

On 10-11-18 08:14 PM, Jonathan Hartley wrote:
> Hey folks.
>
> I'm finding pyglet's OpenGL bindings give me at least 2 times faster 
> framerates than PyOpenGL's. This ratio is surprisingly high to me, am I 
> right to be surprised?
>   
I'd probably expect around 1.5x at least, and 2x doesn't surprise *me*
:) .  Pyglet doesn't, AFAIK do any pointer-reference interception, so
their ctypes calls are direct-to-C, while PyOpenGL is doing a *lot* of
Python code for every array-handling call.  Even when that code is
translated to Cython, it is still a lot of machinery involved compared
to passing a ctypes pointer for everything.
> I'm probably doing lots wrong - I don't really know what I'm doing. 
> Here's what I've checked. What else should I be thinking about?
>
> I'm setting ERROR_CHECKING=False
> If I run with FULL_LOGGING then I see no extra GL calls to retrieve 
> status values.
> I tried running with ERROR_ON_COPY=True, no errors are reported
> I'm running Python with -O.
>   
ERROR_CHECKING = False
CONTEXT_CHECKING = False
STORE_POINTERS = False
FULL_LOGGING = False
ALLOW_NUMPY_SCALARS = False

would be the settings to disable as much of the machinery as possible,
but even with that, we're still doing more code than Pyglet for each
array call.  I'd still expect around 1.5x run-time for PyOpenGL vs.
Pyglet on the kind of code you're writing (lots of calls, a "classic"
OpenGL approach).

To get real performance improvements, vertices into a single numpy
array, put your matrices into another array, multiply matrices *
vertices and draw with a single call from an index array across a VBO. 
If you're updating matrices on each call, use a shader and do the
multiply on the video-card (with a streaming VBO for the matrices and a
static one for the points).  The overhead of pointer calls gets
amortized as you get larger and larger arrays in PyOpenGL, so it tends
to favour the modern VBO + shader model rather than the older classic
OpenGL model.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] OpenGL 1.5 VBO's

[Alejandro S. <as...@gm...>]

Oops forgot to CC the list.

On Mon, Oct 18, 2010 at 11:03 AM, Mike C. Fletcher
<mcf...@vr...>wrote:

> On 10-10-14 09:41 AM, Alejandro Segovia wrote:
> > Hello List,
> >
> > I'm using PyOpenGL for conducting a Computer Graphics course at the
> > University where I work.
> >
> > One of my students is working on an Intel-based card (on W/Vista) that
> > reports OpenGL version 1.5, however, when trying to create VBO's, he
> > was getting an error from deep inside the wrapper. I figured this was
> > probably because of the function wrapper existing, but not being
> > actually linked to anything, which would imply VBO's are not supported
> > by his driver.
> Is the error a "null function error"?  Or something more exotic?  Null
> function error is basically just PyOpenGL saying "that doesn't exist"
> when you go to call the function.  If the function evaluates to true
> (i.e. bool( fun ) == True), then we may have an error in the wrappers.
> >
> > The solution was to use the vertex_buffer_object ARB extension, which
> > had to be imported using something akin to:
> >
> > >>from OpenGL.raw.GL.ARB.vertex_buffer_object import *
> Normally you wouldn't use the raw version, but rather the
> OpenGL.GL.ARB.vertex_buffer_object version.  VBOs, in particular, are
> actually provided as a wrapper (OpenGL.arrays.vbo), but this is the
> general pattern of use.
> > I was wondering, is this the recommended way to import and use
> > extensions in PyOpenGL? and, is it possible that although the Intel
> > driver reports OpenGL version 1.5, it does not provide VBO's? I
> > thought VBO's were promoted to Core in version 1.5.
> I seem to recall them being core in 1.5, yes.
>
>
It's been a while since I opened this topic, but since the troublesome
computer isn't actually mine, I couldn't make all the tests I would've liked
to.

Mike, apparently bool(glBufferData) returns False, even though the Intel
driver reports OpenGL version 1.5. My guess is that driver is actually not
OpenGL 1.5 compliant even though it says it is.

Thanks for the help,
Alejandro.-

-- 
Alejandro Segovia Azapian
Director, Algorithmia: Visualization & Acceleration
http://web.algorithmia.net

Re: [PyOpenGL-Users] stackoverflow: fastest way to build a c array from a list of tuples of floats?

[Jonathan H. <ta...@ta...>]

On 12/11/2010 16:29, Christopher Barker wrote:
> On 11/11/10 11:48 PM, Jonathan Hartley wrote:
>> What is the fastest way in python to build a c array from a list of
>> tuples of floats? The context: my Python code pass arrays of 2D vertices
>> to OpenGL.
>
> This seems like an obvious use for numpy:
>
>> points = [(random(), random()) for _ in xrange(1000)]
>
> def array_numpy(points):
>       return np.array(points, dtype=float32)
>
> And you can save the overhead of the function call, since it's a
> one-liner anyway. Of course, if you're using numpy, you probably never
> would have had all those points in tuples in the first place -- you'd
> just use numpy arrays from the start.




Thanks for this. I'm trying out the numpy approach now.

	Jonathan
-- 
Jonathan Hartley      Made of meat.      http://tartley.com
ta...@ta...   +44 7737 062 225   twitter/skype: tartley

[PyOpenGL-Users] expected performance vs pyglet

[Jonathan H. <ta...@ta...>]

Hey folks.

I'm finding pyglet's OpenGL bindings give me at least 2 times faster 
framerates than PyOpenGL's. This ratio is surprisingly high to me, am I 
right to be surprised?

I'm probably doing lots wrong - I don't really know what I'm doing. 
Here's what I've checked. What else should I be thinking about?

I'm setting ERROR_CHECKING=False
If I run with FULL_LOGGING then I see no extra GL calls to retrieve 
status values.
I tried running with ERROR_ON_COPY=True, no errors are reported
I'm running Python with -O.

I have OpenGL-accelerate installed, although I have done nothing to 
'enable' it or explicitly use it. Do I need to?

I'm drawing 500 cubes, each with a separate glDrawElements call, using:

     for item in items:
         gl.glPushMatrix()
         gl.glMultMatrixf(item.matrix)
         gl.glVertexPointer(
             Glyph.DIMENSIONS,
             gl.GL_FLOAT,
             0,
             item.glyph.glvertices # ctypes array of GLfloats
         )
         gl.glDrawElements(
             gl.GL_TRIANGLES,
             len(item.glyph.glindices),
             gl.GLushort,
             item.glyph.glindices # ctypes array GLushorts
         )
         gl.glPopMatrix()

(There are also color and normal array pointers defined outside the loop 
- they never change.)

Where I'm defining 'gl' using:

     if use_pyglet_bindings:
         from pyglet.gl import gl
         from pyglet.gl import glu
     else:
         import OpenGL
         OpenGL.ERROR_CHECKING = __debug__
         OpenGL.ERROR_ON_COPY = __debug__
         OpenGL.ERROR_LOGGING = False
         OpenGL.FULL_LOGGING = False
         from OpenGL import GL as gl
         from OpenGL import GLU as glu

(obviously some function signatures aren't quite the same in pyglet and 
PyOpenGL, so I'm working around those where I have to. In particular, 
the definition of item.matrix passed to glMultMatrixf changes depending 
on which GL bindings I use, effectively:

     if use_pyglet_bindings:
         matrix = Matrix4() # pyeuclid, pure python
         if item.position is not None:
             matrix.translate(*item.position)
         if item.orientation is not None:
             matrix *= item.orientation.get_matrix()
         item.matrix = matrix_to_ctypes(matrix)
     else:
         matrix = item.orientation.get_matrix() # pure python
         matrix[12:15] = item.position
         item.matrix = numpy.array(matrix[:], dtype=GL.GLfloat)

(this code is only run once for each item on startup - for the moment, 
until I figure this out, my items never move or rotate, so the initial 
matrix on each item remains constant)

I'm on WindowsXP, Python2.7, PyOpenGL3.0.1, with OpenGL2.1 ATI drivers. 
(the most recent drivers available for my hardware, on both a laptop and 
a desktop.)

	
-- 
Jonathan Hartley      Made of meat.      http://tartley.com
ta...@ta...   +44 7737 062 225   twitter/skype: tartley

Re: [PyOpenGL-Users] stackoverflow: fastest way to build a c array from a list of tuples of floats?

[Toby D. <to...@ta...>]

On Friday 12 Nov 2010, Christopher Barker wrote:
> def array_array(points):
>      a = array.array('f')
>      [a.extend(p) for p in points]
>      return a
> 
> Which brings up a question I have: is there way to write a "nothing
> comprehension"? 

	for p in points: a.extend(p)

-- 
Toby Dickenson

Re: [PyOpenGL-Users] stackoverflow: fastest way to build a c array from a list of tuples of floats?

[Christopher B. <Chr...@no...>]

On 11/11/10 11:48 PM, Jonathan Hartley wrote:
> What is the fastest way in python to build a c array from a list of
> tuples of floats? The context: my Python code pass arrays of 2D vertices
> to OpenGL.

This seems like an obvious use for numpy:

> points = [(random(), random()) for _ in xrange(1000)]

def array_numpy(points):
     return np.array(points, dtype=float32)

And you can save the overhead of the function call, since it's a 
one-liner anyway. Of course, if you're using numpy, you probably never 
would have had all those points in tuples in the first place -- you'd 
just use numpy arrays from the start.

> Any other alternatives?

There's also array.array:

def array_array(points):
     a = array.array('f')
     [a.extend(p) for p in points]
     return a

Which brings up a question I have: is there way to write a "nothing 
comprehension"? -- I use the list comprehension syntax, as it's a nice 
clean way to process all the items in a list -- but I don't need the 
resulting list -- it seems there should be a way to write that without 
the overhead of creating a useless list.

-Chris


> -----
> http://stackoverflow.com/q/4156872/10176
>
>
> He's already chosen one answer, but I think that was premature, and some
> of you folks might have substantially better ideas. I'm thinking of a
> fully static-typed Cython function, but I apparently lack the smarts to
> get it working over breakfast, and now I have to go to work.
>
> 	Jonathan
>


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...