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 10 of 10

Thread: glFramebufferTexture Vs glFramebufferTexture2D for CUBE_MAP

  1. #1
    Junior Member Newbie
    Join Date
    Jan 2017
    Posts
    27

    glFramebufferTexture Vs glFramebufferTexture2D for CUBE_MAP

    Hello i 'm wondering what is the difference between glFramebufferTexture and glFramebufferTexture2D when using cubemap texture..according to some experiments i did it seems that glFramebufferTexture attach only the first layer of the cube map and some how the geometry shader will dynamically allocate the rest of faces on the fly. while glFramebufferTexture2D manually attach all the 6 faces...

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,418
    Quote Originally Posted by Hellice View Post
    what is the difference between glFramebufferTexture and glFramebufferTexture2D when using cubemap texture
    According to the spec, glFramebufferTexture attaches all cube map faces of a specific MIP level as an array of images (layered framebuffer), and glFramebufferTexture2D only attaches a single face of a specific MIP level.

    it seems that glFramebufferTexture attach only the first layer of the cube map and some how the geometry shader will dynamically allocate the rest of faces on the fly.
    These calls attach pre-allocated texture storage to a framebuffer for rendering, not allocate storage for the texture (AFAIK). You should allocate texture storage before calling these functions.

  3. #3
    Junior Member Newbie
    Join Date
    Jan 2017
    Posts
    27
    Quote Originally Posted by Dark Photon View Post
    According to the spec, glFramebufferTexture attaches all cube map faces of a specific MIP level as an array of images (layered framebuffer), and glFramebufferTexture2D only attaches a single face of a specific MIP level.
    is calling glFramebufferTexture2D 6 times each call attach one of the faces equivalent to calling glFramebufferTexture ?

  4. #4
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,418
    Quote Originally Posted by Hellice View Post
    is calling glFramebufferTexture2D 6 times each call attach one of the faces equivalent to calling glFramebufferTexture ?
    No. Each call completely re-specifies the settings for that FBO attachment point.

    For details, click on this spec link:

    * OpenGL 4.5 Compatibility Spec

    and search for "Effects of Attaching a Texture Image" which describes the effect of calling any of the glFrameBufferTexture* calls.

  5. #5
    Junior Member Newbie
    Join Date
    Jan 2017
    Posts
    27
    Cool i have some stuff clear now thank you Dark Photon.. just an other last question. when i was reading the spec about Framebuffer i found this :
    When commands such as ReadPixels or CopyPixels read from a layered
    framebuffer, the image at layer zero of the selected attachment is always used to
    obtain pixel values.


    is it possible todo otherwise i mean reading from different layers ?

  6. #6
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,418
    Quote Originally Posted by Hellice View Post
    ReadPixels or CopyPixels ... is it possible todo otherwise i mean reading from different layers ?
    Sure. You've got several options. For instance you could rebind that specific layer to the framebuffer attachment and then get it via glReadPixel/glCopyPixels/etc. (either through a PBO or not) or glBlitFramebuffer. Or if it's in a texture, whether it's bound to an FBO or not, you can get it via glGetTexImage (through a PBO or not). There are probably more ways than that, but that's what comes to mind.

  7. #7
    Junior Member Newbie
    Join Date
    Jan 2017
    Posts
    27
    WoW man how do you have all this knowledge *___* thanks a lot

  8. #8
    Junior Member Regular Contributor
    Join Date
    May 2013
    Posts
    136
    FBOs have several slots for attachments. So you also could just bind each side to one attachment slot and switch the color read source via glReadBuffer​.

    The fun part is to find out what way is not buggy in the driver you use.

  9. #9
    Junior Member Newbie
    Join Date
    Jan 2017
    Posts
    27
    Quote Originally Posted by Osbios View Post
    FBOs have several slots for attachments. So you also could just bind each side to one attachment slot and switch the color read source via glReadBuffer​.
    The fun part is to find out what way is not buggy in the driver you use.
    XD i thought about it but i didn't know that we can switch attachment via glReadBuffer​..x') guys how long it took you to know all this stuff and memorize it.

    ROFL man i used 2 different drivers and i had the same result..after long search i found that is a bug with glGetTexImage and how drivers use it.. funny thing is that it was only me and some other guy in the net who run to that particular problem in the whole world XD

  10. #10
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,418
    Quote Originally Posted by Hellice View Post
    guys how long it took you to know all this stuff and memorize it.
    Glad to help. We all start in the same place. Some folks here have just had the benefit of solving a bunch of different problems using OpenGL for years. That teaches you alot. It's not that it's all memorized. It's just that you get to know the lay-of-the-land and can recall what's possible, what's efficient, and why. And you already know where to look when you're trying to recall how to do something.

    A recommendation: Over the years, searching these forums has been really useful to me in learning and using GL (e.g. finding out how how something works, or whether anyone else has hit the same problem before). You may already know how, but in case not, try typing this in Google when you've got an OpenGL question: "your search phrase site:opengl.org inurl:discussion_boards".

    You can use the same to search the wiki (just replace "discussion_boards" with "wiki"). But it's easier to just go to the wiki and use its built-in search function (which works well).

    ROFL man i used 2 different drivers and i had the same result..after long search i found that is a bug with glGetTexImage and how drivers use it.. funny thing is that it was only me and some other guy in the net who run to that particular problem in the whole world XD
    That stinks. Out of curiosity, which drivers (vendor and version)?

    I'm not sure what you're using for development, but if you're interested in a recommendation, I'd suggest developing on an NVidia GPU with NVidia GL drivers. That'll result in the least amount of "head smacking" when you realize you're fighting some bug in the driver rather than a hole in your understanding. In my 15 years experience with NVidia OpenGL drivers, they've always had great driver quality. It's rare to trip over a bug. Then, if you need your software to work on other vendor's drivers/GPUs, regression test on them. I say that because while NVidia's driver quality is great, they also tend to do "reasonable" things in areas where the spec says the behavior is undefined. You may find some of these cases when testing with other drivers.

Tags for this Thread

Posting Permissions

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