-1

I noticed something strange when I was using frame buffers to do offscreen rendering. I am rendering a cube to a texture and then that texture onto a plane. It all worked and I decided to skip the depth buffer so I commented out block 1 & block 2 (see code below) and it also worked, however, if I leave block 1 intact and only comment out block 2 the plane gets black.

I would assume that by commenting out block2 the renderbuffer would just be a renderbuffer with no association to the framebuffer.

In every example I can find there is always a framebuffer bound before creating a renderbuffer but I can't find anything in the documentation that says it must. Should it work with just commenting out block2 and leaving block1?

// create render buffer to store depth, at this point the default framebuffer is bound
{ //BLOCK 1
    glGenRenderbuffers(1, &handle);
    glBindRenderbuffer(...);
    glRenderbufferStorage(...);
    glBindRenderbuffer(GL_RENDERBUFFER, 0);
}

If I let this code above run when BLOCK 2 is commented the offscreen texture gets black.

// create texture as a color attachment
glGenTextures(1, &handle);
glBindTexture(GL_TEXTURE_2D, handle);
glTexImage2D(...);
// filter, wrap omitted
glBindTexture(GL_TEXTURE_2D, 0);

The texture binding above is tested and works well when sampling.

// creating framebuffer
glGenFramebuffers(1, &handle);
glBindFramebuffer(GL_FRAMEBUFFER, handle);

// attach my render buffer as a depth attachment
{ // BLOCK 2
    glFramebufferRenderbuffer(...)
}

If I comment BLOCK 2 & BLOCK 1 it all works (like a framebuffer with just a color attachment)

// binding texture as an attachment to frame buffer
glFramebufferTexture2D(...);
glDrawBuffers(1, drawBuffers);
glBindFramebuffer(GL_FRAMEBUFFER, 0);

All the code above is executed in this order and no other OpenGL calls are in between.

nyvaken
  • 120
  • 1
  • 7
  • It would help if we could see how exactly you are attaching the renderbuffer and texture. As well as exactly when you bind the FBO (relative to the rest of the code). Also, why do you bind a texture, then attach a texture to the framebuffer, then unbind the texture? Binding textures to the context has nothing to do with FBOs. – Nicol Bolas Mar 13 '17 at 23:03
  • I added some clarification but will get back with a full list of the gl calls in my setup (everything is abstracted but I'm gonna implement a gl call logger). Thanks for pointing out the unnecessary binding of textures. I fail to see why the render buffer in block 1 can affect my frame buffer if its not attached. Thanks! – nyvaken Mar 14 '17 at 11:52

1 Answers1

-1

Found the error. Because of the abstraction of classes, a texture was deleted when a texture class went out of scope. This texture handle was set to 0 as default and another texture using this handle id got deleted.

nyvaken
  • 120
  • 1
  • 7