On Mon, Dec 6, 2010 at 2:46 PM, Derakon <derakon@gmail.com> 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 <derakon@gmail.com> 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 <mcfletch@vrplumber.com> 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
>> PyOpenGL-Users@lists.sourceforge.net
>> 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
PyOpenGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyopengl-users



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