MRT + multisampling only 1 of the RT's


Does anyone know how to multi sample only the FIRST color attachment of a multiple color attachment FBO.

Thanks in advance.

PS: Whenever I do this, I get the first color attachment’s pixel’s
in the second color attachment. But obviously working fine without MSAA.

All attachements of a FBO must have the same sample count.

What I do is, I create a regular FBO with a few color attachments. It works fine. I create another FBO (for MSAA), and create the same number of renderbuffers. I multisample using the glBlitFramebufferEXT function. But somehow the second color attachment gets the first color attachments image.

My procedure is like this:

glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, fbo.getFBO());

glBlitFramebufferEXT(0, 0, this->mWidth, this->mHeight, 0, 0, this->mWidth, this->mHeight, GL_COLOR_BUFFER_BIT, GL_LINEAR);

Perhaps you’re not aware of how multisampling works. In order to have a multisampled result, you should render your scene in the multisampled FBO. If you’re rendering into the single sample FBO and then blit this one into the multisample FBO, it will replicate the value of the single sample FBO to all samples in the multisample FBO. In this case, there’s no benefit in having a multisample FBO since, after resolving it to display on screen, you will get exactly the same result as the single sample FBO.

FYI, when blitting from/to MRT targets you also need to specify the attachments you’re reading from and blitting to with glReadBuffer and glDrawBuffer.

Hello Nico,

Yes, I’m doing the multisampling the way you told already. Right now, I’m setting glDrawBuffer with the color attachments, but I haven’t done so for glReadBuffer, since I’m only drawing in the FBO, I’ll only need to set glDrawBuffer right?

Blitting means that you read values from one framebuffer and write them to another (or the same) one. So you need to specify both the attachment you’re reading from and writing to:


glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, readfbo.getFBO());
glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, drawfbo.getFBO());

glBlitFramebufferEXT(0, 0, this->mWidth, this->mHeight, 0, 0, this->mWidth, this->mHeight, GL_COLOR_BUFFER_BIT, GL_LINEAR);

I’m using the same FBO for the blitting. My read buffer is color attachment 0 and my draw buffer is actually set using glDrawBuffers because of the multiple color attachments (I’ve put 2 color attachments), my first attachment is fine, but my second now, is all black.

Should I set the read and draw buffers to only the zero eth color attachment?

I’ll just dive into this a bit for a while, and post if I still don’t get it. If I get it working, I’ll post how I got it working. But as always, any suggestions are welcome

The Multiple color attachments are working with MSAA now. The problem was that the Draw buffers weren’t appropriately set.

But now I still have an issue, I’m unable to Multisample the color attachment 0 alone. OpenGL is multisampling both color attachments.

I tried using only the color attachment 0 and blitting with GL_LINEAR, and then using only color attachment 1 and blitting with GL_NEAREST to disable MSAA, but this doesn’t seem to work.

Why is that? Is there anything I’m doing wrong? Or should I just draw to an un multisampled FBO and then blit it into a MSAA fbo and do the same as mentioned above? But I doubt if that will work.

Anyway answers are welcome!

Thanks in advance

I’ve read your posts over and over and I’m still confused about what you’re trying to do…

If you’re talking about MSAA I’m assuming you created the color attachments using glRenderbufferStorageMultisampleEXT(), right?

GL_LINEAR and GL_NEAREST are filtering modes, they have nothing to do with MSAA at all.

Hey NickelCobalt :D,

First off, thanks a ton for re reading my posts, I really appreciate that,

onwards to the post,

Sorry man, I’m finding it a bit difficult putting down what I’m doing into words.

Ok, lets assume that MSAA works fine with a 2 color attachment FBO.
Now I’m not making a deferred renderer a such yet. But in the event I was building one, I’d need the normal data etc in the other color attachments not MSAA’d right? But right now, the 2nd color attachment is getting MSAA’d with the first. For me,

0th Color attachment contains the scene (colors),
1st Color attachment contains eyespace distances (only R component)

The deal is, I’m trying to MSAA the 0th Color attachment Alone,
and at the same time get the second color attachment un-changed (Not MSAA’d), I want to do this without any fancy stuff, multiple FBO’s etc. Is it impossible? Or am I just doing something totally wrong?

Well, like Zengar said, all attachments in an FBO must have the same sample count. So if your FBO is multisampled, you 2nd color attachment needs to be multisampled too. If you’re doing deferred rendering than you will need to access the data in the 2nd attachment in a subsequent pass, meaning that it has to be converted into a single sample texture first. This in turn means that you need a separate texture to store the single sample version. Resolving the 2nd attachment to a single sample texture is easily done by binding the single sample texture to another FBO and blitting th 2nd attachment into that FBO. Don’t be afraid of using multiple FBO’s, they’re just objects that keep track of whats being attached to them, etc. so they don’t take up much space.

Correct me if I’m wrong, but aren’t most deferred rendering techniques based on processing single sample data and then drawing the result of the final shader pass into a multisample buffer?

Thanks a ton man!

That cleared up stuff for me. Well your right about deferred rendering techniques, but actually I was trying this with Screen Space AO, and I needed some data untouched in the 2nd color attachment and I needed it in that pass itself and I needed the scene rendered multi sampled though. Ofcourse the obvious workaround was there, as is in deferred rendering but I was just curious about this, and I didn’t quite follow what Zengar said about same sample counts. I now understand what he meant. I wanted to play around with multisampled scene data with un multisampled ‘other’ data at the same time in a post process.

Anyway, Its very clear now. I must’ve been high on disorder thinking about my System Software lab exams tomorrow.

Thanks again NiCo
and Zengar

Glad I could help. Good luck with your exams tomorrow :slight_smile: