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.
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.
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?
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?
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?
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.