Reputation: 1087
I have the following OpenGL setup for troubleshooting frame buffer issues:
This works OK when both stages of the process are done in the same context, but breaks if stage 1 is done in a different context to stage 2 (note that these contexts are both shared and both on the same thread). In this case, I only ever see the cube displayed when I resize my viewport (which recreates my frame buffer). The cube is sometimes corrupted or fragmented, which leads me to believe that all I'm seeing is parts of memory that were used by the texture before it was resized, and that nothing is ever displayed properly.
The reason I have to have this setup is that in my actual application I'm using Qt OpenGL widgets, which are forced to use their own individual contexts, so I have to render my scene in its own dedicated context and then copy it to the relevant viewports using shareable OpenGL resources. If I don't do this, I get errors caused by VAOs being bound/used in other contexts.
I've tried the following unsuccessful combinations (where the primary context is where I use the texture to draw the quad, and the secondary context where the "offscreen" rendering of the cube into the frame buffer takes place):
In addition, I can't use glBlitFramebuffer()
as I don't have access to the frame buffer the QOpenGLWidget
uses in the application (as far as I've tried, QOpenGLWidget::defaultFramebufferObject()
returns 0 which causes glBlitFramebuffer
to give me errors).
The only way I have managed to get the rendering to work is to use a QOpenGLFrameBuffer
and call takeTexture()
when I want to use the texture with the quad. However, doing it this way means that the QOpenGLFrameBuffer
creates itself a new texture and I have to destroy the old one once I've used it, which seems very inefficient.
Is there anything I can do to solve this problem?
Upvotes: 1
Views: 605
Reputation: 7582
I've got a project that uses a texture like that. You need to call glFinish()
after drawing and before using the texture from QOpenGLFramebufferObject::texture()
. That was our problem on some of the OSes.
Upvotes: 2