Thread: [PyOpenGL-Users] Odd framebuffer error
Brought to you by:
mcfletch
From: Derakon <de...@gm...> - 2010-11-30 19:40:56
|
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 |
From: Alejandro S. <as...@gm...> - 2010-11-30 20:17:45
|
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 |
From: Derakon <de...@gm...> - 2010-11-30 20:50:53
|
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 |
From: Derakon <de...@gm...> - 2010-12-01 17:44:37
|
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 |
From: Alejandro S. <as...@gm...> - 2010-12-01 18:12:13
|
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 |
From: Derakon <de...@gm...> - 2010-12-01 18:29:56
|
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 |
From: Mike C. F. <mcf...@vr...> - 2010-12-02 13:16:23
|
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 |
From: Derakon <de...@gm...> - 2010-12-02 16:38:00
|
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 > |
From: Derakon <de...@gm...> - 2010-12-06 16:46:34
|
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 >> > |
From: Alejandro S. <as...@gm...> - 2010-12-06 17:31:31
|
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 |