PDA

View Full Version : Enabling/Disabling Writes to Color Attachments at Runtime



Geoeoeo
01-05-2017, 05:00 PM
Hello,

I am trying to implement a very simple way of handling transparency with deferred shading.

Essentially I have 3 render passes:

1) Render background

2) Enable Blending / Render into diffuse texture

3) Disable Blending / Render Normals etc. into remaining textures

The problem is I want disable writes into everything expect diffuse textures during step 2.
An elegant solution would be to disable the writes to the specific attachments.
However I cant get it to work.

I looked at 2 methods:

glNamedFramebufferDrawBuffer
Which I am using as such : glNamedFramebufferDrawBuffer(FBO,GL_COLOR_ATTACHME NT3)
However, this gives me an expection at runtime :/


glColorMaski
Which I am using as such :
glColorMaks(GL_FALSE,GL_FALSE,GL_FALSE,GL_FALSE);
glColorMaski(GL_COLOR_ATTACHMENT3,GL_TRUE,GL_TRUE, GL_TRUE,GL_TRUE)
code runs, but nothing get rendered i.e. the second instruction gets ignored?

How can I enable/disable color attachments during the render loop? (If it is possible at all)

Best,

Marc

Silence
01-06-2017, 06:04 AM
According to this (https://www.opengl.org/sdk/docs/man4/html/glDrawBuffers.xhtml), glNamedFramebufferDrawBuffers is available in OpenGL 4.5 only. Is this your case ? I would personally use glDrawBuffers described in the same page.

Geoeoeo
01-06-2017, 03:41 PM
Thanks for the reply. Actually even if the enabling/disabling of color attachments would work, my method wont :p

The problem is that even if color is not written, depth will be. Therefore, I get z-fighting issues in the next pass.

The naive way im going to do this, is to use two different FBO. One for blending the albedo colors, and one for writing all the other properties.

I think that should work.

Best,

Marc

Dark Photon
01-06-2017, 08:50 PM
Ok, I have a couple things. First, to your specific questions:



glColorMaski
Which I am using as such :
glColorMaks(GL_FALSE,GL_FALSE,GL_FALSE,GL_FALSE);
glColorMaski(GL_COLOR_ATTACHMENT3,GL_TRUE,GL_TRUE, GL_TRUE,GL_TRUE)
code runs, but nothing get rendered i.e. the second instruction gets ignored?


Check the glColorMaski entry in the wiki (https://www.khronos.org/opengl/wiki/GLAPI/glColorMask), the man page (https://www.opengl.org/sdk/docs/man/html/glColorMask.xhtml[/url), or the spec (https://www.opengl.org/registry/doc/glspec45.compatibility.pdf). Notice that the 1st argument "buf" is the draw buffer index "i" (in DRAW_BUFFERi), not the value you've set for that draw buffer index (e.g. GL_COLOR_ATTACHMENT3). See glDrawBuffers (https://www.khronos.org/opengl/wiki/GLAPI/glDrawBuffers) for details.



glNamedFramebufferDrawBuffer
Which I am using as such : glNamedFramebufferDrawBuffer(FBO,GL_COLOR_ATTACHME NT3)
However, this gives me an expection at runtime :/

You might provide more detail. For instance, what do you mean by exception? Is a GL error being thrown? What is it? What is the value of GL_MAX_COLOR_ATTACHMENTS on your system? etc.


The problem is that even if color is not written, depth will be. Therefore, I get z-fighting issues in the next pass.

You do have glDepthMask, glDepthFunc, and GL_DEPTH_TEST.

Now for a question on your overall approach:


I am trying to implement a very simple way of handling transparency with deferred shading.

Essentially I have 3 render passes:

1) Render background
2) Enable Blending / Render into diffuse texture
3) Disable Blending / Render Normals etc. into remaining textures


I don't understand why you're doing this. Could you explain? Basic deferred shading samples the front-most opaque fragments into a multi-channel G-Buffer (normal, diffuse, specular, depth, etc.) using MRT. It then goes back and lights/shades these channels into a single lighting buffer. Following that, translucent surfaces are often handled by rendering them on top of the lighting buffer with forward shading in (at least conceptually) one pass.

What are you doing in step 2 and 3? Step 2 sounds like rendering translucents onto the lighting buffer. However, step 3 sounds like we're way back in the G-buffer rasterization pass sampling normals for opaque surfaces. What am I missing?