OpenGL 4 - Can we still not specify a texture attachment index for blending

If you have a gbuffer for a deferred renderer like this:

Texture 0

R: Diffuse.r
G: Diffuse.g
B: Diffuse.b
A: Diffuse.a

Texture 1

R: Normal.x
G: Normal.y
B: Normal.z
A: Diffuse.a

Texture 2

R: Specular
G: Gloss
B: <empty>
A: Diffuse.a

Texture 3

R: Emission.x
G: Emission.y
B: Emission.z
A: Diffuse.a

For alpha-blended decals that are rendered prior to lighting, the alpha channel in each texture attachment has to hold the same value. If each attachment could be told to blend with the alpha channel of attachment 0, the data could be compressed as follows:

Texture 0

R: Diffuse.r
G: Diffuse.g
B: Diffuse.b
A: Diffuse.a

Texture 1

R: Normal.x
G: Normal.y
B: Normal.z
A: Specular

Texture 2

R: Emission.x
G: Emission.y
B: Emission.z
A: Gloss

I just wanted to check if this is this possible yet in OpenGL 4? I found the documentation for draw_buffers_blend, but it doesn’t appear to be what I’m after:
http://www.opengl.org/registry/specs/ARB/draw_buffers_blend.txt

You don’t have to have diffuse.a in all 4 textures’ Alpha component. I have a deferred renderer where the alpha channels store other data, like your second setup. All you need to do is draw to Texture 0 only (glDrawBuffer(GL_COLOR_ATTACHMENT0)) when drawing your decals.

Now translucent objects are a bit of a problem in a deferred renderer, unless you do a stencil-routed k-buffer approach, but that can quite resource intensive on lower-end cards.

[QUOTE=malexander;1256786]You don’t have to have diffuse.a in all 4 textures’ Alpha component. I have a deferred renderer where the alpha channels store other data, like your second setup. All you need to do is draw to Texture 0 only (glDrawBuffer(GL_COLOR_ATTACHMENT0)) when drawing your decals.

Now translucent objects are a bit of a problem in a deferred renderer, unless you do a stencil-routed k-buffer approach, but that can quite resource intensive on lower-end cards.[/QUOTE]
If you want the decal normals and other properties to blend with the underlying normals, the additional texture attachments each need to store an alpha value. If you use that alpha channel to store an alpha value for blending, it is no longer available for whatever else you were planning to put there. At the very least, decals definitely need to affect the screen normals, because they look so much better that way.

Ah, I was thinking you were blending a diffuse decal.

In that case, you might draw glBlendFuncSeparate(), where you could blend the RGB components using (Sa, 1-Sa) and A using either (0, 1) or (1, 0), depending on whether your decal replaces or leaves the destination A component alone. You can also specify the equation separately as well (add, subtract, min, max).

If you need to also blend in gloss and specular, you’re out of luck. You’d need to use your first approach.

Well, the decal needs to write to a different normal texture anyways, since it needs to read the underlying normal lookup to calculate texcoords on the surface. So I suppose I can perform that blend in the shader, and just allow the other values to be acceptable errors.