GBuffer: Framebuffer with different texture format types?

Question

I rely on this answer from Nathan Reed: How much precision do I need in my G-Buffer?

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?

Answer 1

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 or, even more common, it just has a set of Mip Map Levels (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 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, 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) they loosened these restrictions.