Thread: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes
Brought to you by:
mcfletch
From: Joshua R. D. <jd...@ca...> - 2009-01-15 04:43:46
|
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 |
From: Mike C. F. <mcf...@vr...> - 2009-02-14 23:30:12
|
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 |