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…

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.

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:

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

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 :
[b]

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.
[/b]

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.

WoW man how do you have all this knowledge ___ thanks a lot

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. :wink:

[QUOTE=Osbios;1285721]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. ;)[/QUOTE]

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

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: [noparse]“your search phrase site:opengl.org inurl:discussion_boards”[/noparse].

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.