<p>You have a bit of a misunderstanding there. The paragraph you quoted doesn't actually say anything about framebuffer objects yet. It just talks about a single <em>texture</em>. While we usually understand a texture as a single image, it is (or can be) <em>actually</em> comprised of a <em>set of images</em>. This might be because it is an <a href="https://www.khronos.org/opengl/wiki/Array_Texture" rel="nofollow noreferrer">Array Texture</a> or, even more common, it just has a set of <a href="https://www.khronos.org/opengl/wiki/Texture#Mip_maps" rel="nofollow noreferrer">Mip Map Levels</a> (basically increasingly smaller filtered versions of the base image, used for advanced texture filtering). And yes, within a single texture, all those images have the same format. However <em>one</em> such texture usually makes for <em>one</em> render target.</p>

<p>All this has nothing to do with multiple render targets yet. And you will notice that the later parts of that article that speak about the actual framebuffer attachments, specifically the part about <a href="https://www.khronos.org/opengl/wiki/Framebuffer_Object#Completeness_Rules" rel="nofollow noreferrer">Framebuffer Completeness</a> <strong>don't say anything of the sort of all attachments needing to have the same format, because there is no such restriction</strong>. They don't even need to have the same dimensions. The only thing that is required is that they all have the same number of samples (if they're multisampled at all).</p>

<p>It <em>is</em> possible that an implementation still doesn't support all kinds of image formats and combinations, but there are some that are required and a "reasonable" implementation will support a wide variety of format combinations, including ones with mixed pixel bit-depths.</p>

<p>There <em>was</em> a stricter limitation on the images in the original <a href="https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_framebuffer_object.txt" rel="nofollow noreferrer">GL_EXT_framebuffer_object extension</a>, namely that all attachments have the same size and internal format. However, since it has found its way into OpenGL 3.0+ core (and was from there exported back as the more advanced <a href="https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_framebuffer_object.txt" rel="nofollow noreferrer">GL_ARB_framebuffer_object extension</a>) they loosened these restrictions.</p>

CC BY-SA 4.0
2019-02-16T00:27:42.353Z
2019-02-16T00:27:42.353Z
Christian Rau
<p>I rely on this answer from Nathan Reed: <a href="https://computergraphics.stackexchange.com/questions/4969/how-much-precision-do-i-need-in-my-g-buffer/4971#4971?newreg=c82ae981d40148c1a38922de1b259a4c">How much precision do I need in my G-Buffer?</a></p>

<p>It is proposed to use two different texture formats for one Gbuffer. </p>

<p>However as far as I know, color texture attachments to framebuffer objects must have the same format: <a href="https://www.khronos.org/opengl/wiki/Framebuffer_Object" rel="nofollow noreferrer">https://www.khronos.org/opengl/wiki/Framebuffer_Object</a></p>

<blockquote>
  <p>Texture
      For the purposes of this article, a texture is an object that contains some number of images, as defined above. <strong>All of the images have the same format</strong>, but they do not have to have the same size (different mip-maps, for example). Textures can be accessed from Shaders via various methods.</p>
</blockquote>

<p>Is it possbile to use multiple render targets with different texture formats for a framebuffer? Or should just the lowest common format be choosen and manually pack and unpack the 16-Bit values in the shader?</p>

<opengl><deferred-rendering><frame-buffer>
GBuffer: Framebuffer with different texture format types?
MrRabbit
# GBuffer: Framebuffer with different texture format types?

(Asked by: username_0 on 2019-02-15)

I rely on this answer from Nathan Reed: [How much precision do I need in my G-Buffer?](https://computergraphics.stackexchange.com/questions/4969/how-much-precision-do-i-need-in-my-g-buffer/4971#4971?newreg=c82ae981d40148c1a38922de1b259a4c)

It is proposed to use two different texture formats for one Gbuffer.

However as far as I know, color texture attachments to framebuffer objects must have the same format: <https://www.khronos.org/opengl/wiki/Framebuffer_Object>

> Texture
> For the purposes of this article, a texture is an object that contains some number of images, as defined above. **All of the images have the same format**, but they do not have to have the same size (different mip-maps, for example). Textures can be accessed from Shaders via various methods.

Is it possbile to use multiple render targets with different texture formats for a framebuffer? Or should just the lowest common format be choosen and manually pack and unpack the 16-Bit values in the shader?

**Tags:** opengl, deferred-rendering, frame-buffer


---

## 1 answers

### Answer by username_1 on 2019-02-16. Score: 4 | Accepted answer

You have a bit of a misunderstanding there. The paragraph you quoted doesn't actually say anything about framebuffer objects yet. It just talks about a single *texture*. While we usually understand a texture as a single image, it is (or can be) *actually* comprised of a *set of images*. This might be because it is an [Array Texture](https://www.khronos.org/opengl/wiki/Array_Texture) or, even more common, it just has a set of [Mip Map Levels](https://www.khronos.org/opengl/wiki/Texture#Mip_maps) (basically increasingly smaller filtered versions of the base image, used for advanced texture filtering). And yes, within a single texture, all those images have the same format. However *one* such texture usually makes for *one* render target.

All this has nothing to do with multiple render targets yet. And you will notice that the later parts of that article that speak about the actual framebuffer attachments, specifically the part about [Framebuffer Completeness](https://www.khronos.org/opengl/wiki/Framebuffer_Object#Completeness_Rules) **don't say anything of the sort of all attachments needing to have the same format, because there is no such restriction**. They don't even need to have the same dimensions. The only thing that is required is that they all have the same number of samples (if they're multisampled at all).

It *is* possible that an implementation still doesn't support all kinds of image formats and combinations, but there are some that are required and a "reasonable" implementation will support a wide variety of format combinations, including ones with mixed pixel bit-depths.

There *was* a stricter limitation on the images in the original [GL\_EXT\_framebuffer\_object extension](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_framebuffer_object.txt), namely that all attachments have the same size and internal format. However, since it has found its way into OpenGL 3.0+ core (and was from there exported back as the more advanced [GL\_ARB\_framebuffer\_object extension](https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_framebuffer_object.txt)) they loosened these restrictions.


---

