We have a perfect looking 4x FSAA viewport but when is the time to make a bitmap for it we get a strange result: a bitmap of the screne not antialiased but with some strange artifacts along the lines (simply wireframe GL_LINES drawing). Basically the image is the right one but during the glReadPixel the FSAA is working wrong.
We had no problem when using FBO texture to make the bitmap but recently we switched to glReadPixel as suggested on this forum and the problem arised.
I wanted to discuss the following more in details:
Since you can’t read the multisample buffer directly with glReadPixels since it would raise an error flag (GL_INVALID_OPERATION), what should you do?
You need to blit to another surface so that the GPU can do a downsample. You could blit to the backbuffer, but there is the problem of the “pixel owner ship test”. It is best to make another FBO.
Let’s assume you made another FBO and now you want blit.
This requires GL_EXT_framebuffer_blit. Typically, when your driver supports GL_EXT_framebuffer_multisample, it also supports GL_EXT_framebuffer_blit, for example the nVidia Geforce 8 series.
Now I have FBO -> glReadPixel working perfectly without FSAA to add FSAA support I need:
create a new framebuffer_multisample in the case FSAA is available and active
make the blit between the framebuffer_multisample and the regular_framebuffer
use glReadPixel on the regular_multisample
In the case the FSAA is active go directly to point (3)
//Delete resources
glDeleteTextures(1, &ColorBufferID);
glDeleteRenderbuffersEXT(1, &DepthBufferID);
//Bind 0, which means render to back buffer, as a result, fb is unbound
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
glDeleteFramebuffersEXT(1, &fboID);
It is a wiki, it’s not any official source from ARB.
ColorBufferID is ID of render buffer so it must be destroyed by
glDeleteRenderbuffersEXT. But the author made a mistake and destroyed some texture with that ID.