Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

Thread: Regarding render to texture

  1. #1
    Junior Member Regular Contributor
    Join Date
    Jun 2012
    Posts
    207

    Regarding render to texture

    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.

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    [..]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:

    Quote Originally Posted by The GL Spec
    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.
    Last edited by thokra; 02-15-2013 at 01:30 AM. Reason: Wording.

  3. #3
    Junior Member Regular Contributor
    Join Date
    Jun 2012
    Posts
    207
    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.

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    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?

  5. #5
    Junior Member Regular Contributor
    Join Date
    Jun 2012
    Posts
    207
    Quote Originally Posted by thokra View Post
    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.

  6. #6
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    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.

  7. #7
    Junior Member Regular Contributor
    Join Date
    Jun 2012
    Posts
    207
    Quote Originally Posted by thokra View Post

    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.

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    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.

  9. #9
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,220
    Quote Originally Posted by thokra View Post
    4) unbind the FBO thus switiching back to the system FBO
    Ok, 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •