pyopengl-users

[PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

[Joshua R. D. <jd...@ca...>]

I am trying to cast shadows from multiple lights using shaders. I use one framebuffer object per light. When I have just one light, it works. When I try two lights, the program survives the first call to glGenFramebuffersEXT() but crashes ("Bus error") upon the second call to it.

What follows is a minimal demo. If I run it as-is, then it prints out the two FBO identifiers and terminates normally. If I switch the "cow = ..." and "print framebuffer" lines, then it prints out the first FBO identifier and then crashes ("Bus error"). Why would the location of the print statement matter?

from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
# adapted from http://www.pygame.org/wiki/GLSLExample
try:
    from OpenGL import platform
    gl = platform.OpenGL
except ImportError:
    try:
        gl = cdll.LoadLibrary('libGL.so')
    except OSError:
        from ctypes.util import find_library
        path = find_library('OpenGL')
        gl = cdll.LoadLibrary(path)
glutInit(0)
glutInitDisplayMode(GLUT_RGB|GLUT_DOUBLE|GLUT_DEPTH)
glutCreateWindow('test')
framebuffer = gl.glGenFramebuffersEXT(1)
cow = gl.glGenFramebuffersEXT(1)
print framebuffer
print cow

Other questions:
1. Why do I not need to call glInitFramebufferObjectEXT()?
2. Does glGenFramebuffersEXT(1) return a framebuffer identifier or a list of them? (When I try glGenFramebuffersEXT(1)[0], I get "TypeError: 'int' object is unsubscriptable".)

I'm new to both Python and framebuffer objects, so I may have fundamental misconceptions. My setup is Mac OS 10.4.11, ATI Radeon 9600, Python 2.5, PyOpenGL 3.0.0b6.

-- Josh

Re: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

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

Joshua R. Davis wrote:
> I am trying to cast shadows from multiple lights using shaders. I use one framebuffer object per light. When I have just one light, it works. When I try two lights, the program survives the first call to glGenFramebuffersEXT() but crashes ("Bus error") upon the second call to it.
>
> What follows is a minimal demo. If I run it as-is, then it prints out the two FBO identifiers and terminates normally. If I switch the "cow = ..." and "print framebuffer" lines, then it prints out the first FBO identifier and then crashes ("Bus error"). Why would the location of the print statement matter?
>   
Here's what I'm running to test:

#! /usr/bin/env python
"""Test for glGenFramebuffersEXT multiple-call failure reported by 
Joshua Davis"""
from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
# adapted from http://www.pygame.org/wiki/GLSLExample
from OpenGL.GL.EXT.framebuffer_object import *
def main():
    glutInit(0)
    glutInitDisplayMode(GLUT_RGB|GLUT_DOUBLE|GLUT_DEPTH)
    glutCreateWindow('test')
    framebuffer = glGenFramebuffersEXT(1)
    print framebuffer
    cow = glGenFramebuffersEXT(1)
    print cow

if __name__ == "__main__":
    main()

which prints the two identifiers on a Linux AMD64 (Kubuntu Intrepid) 
machine using driver "2.1.8087 FireGL Release" for an "ATI Mobility 
Radeon HD 3650" using BZR trunk of PyOpenGL.  No change if I swap the 
framebuffer = and print framebuffer lines.
> Other questions:
> 1. Why do I not need to call glInitFramebufferObjectEXT()?
>   
That function just checks for the presence of the extension, PyOpenGL 
will check for the extension the first time you try to call a function 
or check its boolean truth value, so the explicit check isn't needed any 
more.
> 2. Does glGenFramebuffersEXT(1) return a framebuffer identifier or a list of them? (When I try glGenFramebuffersEXT(1)[0], I get "TypeError: 'int' object is unsubscriptable".)
>   
This is, in retrospect, probably a poor choice.  I retained 
compatibility with PyOpenGL 1.x and 2.x scripts at the expense of the 
consistency of the interface.  The behaviour with all previous PyOpenGL 
releases (and PyOpenGL 3.x now) is to return a single-value rather than 
a list if you ask for a single item.

If you can run the script above instead of directly accessing the 
functions from the DLL we may be able to track down the problem further.

Good luck,
Mike

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