Framebuffer object initialization

I have a (Qt) window with OpenGL context, to draw my geometry. Scene with one light and materials.

I have a OpenGL framebuffer object to make some mathematical calculations. Nothing to display on screen. There is no need for lights and materials. Not even color.

I realize when output the framebuffer object to a TGA image, that inherits the real window framebuffer characteristics. So there is light and materials.

This is not what I want. I want the new framebuffer object to start from scratch, totally independent with real window’s framebuffer. Is there a way for this?

If I disable the lighting or if I change the projection matrix in framebuffer object, it will affect real window framebuffer?

Thanks for your time.

I may be wrong, but I think that yes, it affects, but the lighting state is not associated to the FBO (it’s a OpenGL independent state). You have to specify that lighting is off when rendering to the FBO and activate it when drawing to the window’s buffers.
The same applies for material.

After testing, I realize that even glViewport, glClearColor and changes to projection and modelview matrices, affect both framebuffers (object and screen).

What a mess. I must re-init every framebuffer every time I reuse it.
And of course, I cannot use both together. Threads are forbidden.

Is there a way to unlink one framebuffer from another?
Or another approach?

Yep! Use the old WGL_ARB_render_texture extensions. But be warned: they are too clumsy.

I am thinking to create a new context.
So, I switch between contexts.

Any thoughts?

Yes, that’s the idea with WGL_ARB_render_texture. WGL_ARB_render_texture uses a pbuffer context bound to a texture(read the specs but I warn you, it’s complicated). So all state is context specific and you have to set it once. Actually, framebuffer objects are cheaper to swap than contexts, plus,they are platform independent. Plus usually you want to keep your viewport and the projection/view matrix the same when doing multiple passes so it does have some sense behind it, especially if you’re working on a game engine, where the context/framebuffer paradigm means a lot of resetting the aforementioned properties. In your case however maybe this alternative is more intuitive. Threading this workflow does not make too much sense because all work must be done by the GPU anyway, so in fact it is never ‘idle’.