PDA

View Full Version : Regarding render to texture



debonair
02-14-2013, 11:34 PM
i am implementing render to texture concept and have doubt regarding scope of a FBOs. After i am done with glDrawArrays call on default FBO with render to texture, i am deleting texture and non default FBO. Then i am calling glReadPixels to read contents on default FBO. So, my question is am i doing it right i mean should i call readpixel before deleting FBO and texture?

What i was assuming that after drawing it on default FBO we dont need non default FBO and texture but later some developer of OpenGL told me i am doing some strange things in my application referring to above. Please help me to understand this.

thokra
02-15-2013, 01:28 AM
[..]and have doubt regarding scope of a FBOs.

Objects in OpenGL, neither buffer objects nor texture objects nor framebuffer objects, aren't scoped in the sense objects (also basic types like int, not only user-defined) are in C/C++. If you create a framebuffer object, it will not be destroyed until you explicitly do so with glDeleteFramebuffers() or by simply destroying the whole context. Note that the latter version of cleaning up isn't good practice, although contexts clean up after themselves.


[..]default FBO[..]

It drives me up the wall that you simply won't adopt correct terminology even after having beentold so repeatedly. I will make a final attempt by showing you what the OpenGL specification has to say about your mysterious default FBO:


Initially, the GL uses the window-system provided default framebuffer. The storage, dimensions, allocation, and format of the images attached to this framebuffer are managed entirely by the window system. Consequently, the state of the default framebuffer, including its images, can not be changed by the GL, nor can the default framebuffer be deleted by the GL.


After i am done with glDrawArrays call on default FBO with render to texture, i am deleting texture and non default FBO.

Ok, let's make some sense out of this. First of all, here's the algorithm depicted in your sentence:

1) create a framebuffer object and attach a suitable texture as color attachment
2) unbind the FBO, render some primitives with glDrawArray into the default framebuffer
3) delete the FBO and the texture
4) read back contents of the default framebuffer
5) wonder what the hell just happened
6) goto 1

Honestly, that's what you say above. Does it make any sense? No, it doesn't. Here's what you were actually trying to do:

1) create a framebuffer object and attach a suitable texture as color attachment (and a depth attachment would be wise too)
2) bind and clear the FBO
3) render some primitives

IF rendering using texture is required:
4) unbind the FBO thus switiching back to the >>>>> default framebuffer <<<<<
5) clear the default framebuffer
6) bind the texture used as color attachment
7) render something to which the texture will be mapped
8) goto 2
ELSE
9) if not done yet, set the color attachment as the read buffer for read backs using glReadBuffer(GL_COLOR_ATTACHMENT_i)
10) read back texture (== color attachment) contents into system memory using glReadPixels
11) process data in some way
12) goto 2

As you can see, you neither need to delete FBO nor should you delete the texture object because otherwise there won't be nothing to read back from. You could delete the FBO because textures are separate objects and not affected by framebuffer deletion, but you'd have to re-create it for every frame which is simply wasteful. Plus, there are also ways of not even switching off the FBO at all when redering subsequent stuff but I think that's beyond the scope of your question.

Simply keep the FBO and keep the texture.

debonair
02-15-2013, 02:47 AM
Here are the steps i am following:
1) create a framebuffer object and attach a suitable texture as color attachment
2) bind and clear the FBO
3) render some primitives
4) unbind the FBO thus switiching back to the system FBO
5) bind the texture used as color attachment
6) Render on system FBO with texture created above.
7) delete texture and FBO created.
8) glReadpixel from system FBO.

Now, as i have rendered on system FBO and it. why do we still need that texture and other FBO which were used as textures?
@thokra : i guess you got my question wrong, i am not reading pixels from non default (other FBO created).
Please correct me if wrong.

thokra
02-15-2013, 02:55 AM
4) unbind the FBO thus switiching back to the system FBO

Ok, I give up ...


i guess you got my question wrong

I did, because nowhere in your post it says that you want to read back the results of the final rendering. It was misleading - at least for my taste.


7) delete texture and FBO created.

Why? What you gain from deleting the FBO and texture every frame?

debonair
02-15-2013, 03:01 AM
Ok, I give up ...


Ok, it is just a terminology i am using to distinguish between two FBOs.




I did, because nowhere in your post it says that you want to read back the results of the final rendering. It was misleading - at least for my taste.



Why? What you gain from deleting the FBO and texture every frame?

I don't have any loop to render it again and again, i am rendering it only once.

thokra
02-15-2013, 03:21 AM
Ok, it is just a terminology i am using to distinguish between two FBOs.

Yes, I realized that multiple threads ago. But the problem is that you call the other FBO the default FBO. There is no such thing. The only place where the word default can pop up when talking FBOs is turning FBOs off by binding 0 to the target. If you actually use two FBOs, simply call them FBO A and B or 1 and 2 or something. I never intended to be hard on you or something, I simply want to encourage you to use standard terminology that's correct and understood by everyone. Don't teach yourself incorrect things - old habits die hard.


I don't have any loop to render it again and again, i am rendering it only once.

Your intent wasn't clear at all when I read your question. Remember that most of the time people around here render more than a single frame. Please be accurate about what your application does.

If you're not destroying the GL context after rendering and there's a chance that you'll need to render later again, you don't need to. It's ok, but unecessary.

debonair
02-15-2013, 03:30 AM
If you're not destroying the GL context after rendering and there's a chance that you'll need to render later again, you don't need to. It's ok, but unecessary.

I am doing it just for cleanup purpose. I know its wise to do cleanup (delete texture and FBO) at the end but i just had question would it really make a difference.

thokra
02-15-2013, 05:09 AM
Nope, I doesn't make any difference for the purpose of reading back data. As soon as you rendered to FBO B or the default framebuffer, the texture isn't required anymore and so isn't the FBO. Plus, being thorough, you'd have to do cleanup when the GL context goes down. So you basically do what any good application does when it goes down.

Dark Photon
02-15-2013, 08:49 AM
4) unbind the FBO thus switiching back to the system FBOOk, I give up ...
Go easy on him. That's probably my fault. I like to call the default framebuffer the system framebuffer, window-system framebuffer, or whatever. No, it is not a framebuffer object, but you bind it just like it is (handle 0). So it's easy to lose the distinction.