The size requirement isn't a horrible problem, often you want lots of buffers the same size. However, the requirement for the same format, while understandable due to hardware constraints, is still slightly bothersome.
When working on the final year project for my degree I ran into this problem when wanting to only render a single channel to one texture, but at the same time multiple data to another. In the end I just ended up reworking things for the project.
Still, it was bothersome and for things such as deferred rendering the wasted bandwidth can be a problem.
A few months back I brought a 8800GT 512Meg card as my ATI X1900XT was slowly dying. Having installed it I had a look at the explosion of OpenGL extensions, and in this list one perticular one stood out; GL_EXTX_framebuffer_mixed_formats.
I believe at the time I passed comment about this however a change in life stopped me investigating further.
Fast forward to yesterday and a question in the OpenGL forum about why a framebuffer was considered incomplete when the person in question had attached two different format types to the FBO. At the time I pointed out the problem but this got me thinking about the extension.
So, this afternoon I finally bothered to see if the goodness I suspected that extension would allow worked.
In the end I settled on a simple test; create two very different formats, attach both to an FBO, render to them and then display them as two side by side quads.
In the end I settled for a conventional RGBA and a 32bit floating Luminance texture.
First test first; create textures, create FBO, attach textures, set output to two buffers and test for completeness.
One run and check later, yes, the setup was considered complete.
So far I'm [smile] about.
Now, a rendering test.
Again, nice and simple; just draw a fullscreen quad to the FBO using a simple vertex and fragment/pixel shader. Then, render the two quads to test the ouput.
const char * vertexshader = "#version 110\nvoid main(void) { gl_Position = ftransform(); }";const char * fragshader = "#version 110\nvoid main(void) { gl_FragData[0] = vec4(1.0, 0.0, 1.0, 1.0); gl_FragData[1] = vec4(1.0, 0.0, 0.0, 0.5); }";The two GLSL shaders in question; output just 'red' to the RGBA texture and output 1.0 to the Lum32F texture.
One test later and half my framebuffer was red, half was white; just what I expected to see, so now I'm [grin].
Next I changed it so that the Lum output was (0.0, 1.0, 0.0, 0.5), which gave a black half instead of white on the Lum. side; [grin] still.
Finally I decided to test two component rendering, so swapped the 2nd texture to a 32bit floating point Luminace Alpha texture and reran the tests, first with (1.0, 0.0, 0.0, 1.0) which gave me the expected white with blending enabled. Then, still with blending enabled, I tried (1.0, 0.0, 0.0, 0.5) which gave me the expected result of a slightly faded colour.
[grin][grin][grin]
I still haven't decided that I'm going to do with this; maybe I'll finally be bothered to write a deferred renderer or something, when combined with GL_drawbuffers2 to control blending on/off per target intresting things might be possible... well, on NV cards at least *chuckles*
(Even if completely limited to people who own 8800's).