Hi,
I’m seeing GL usage errors when trying to enable multiple render targets. I have an FBO with 3 color attachments and a single depth attachment. I can slim the problem down to a single depth attachment and a single color attachment, but I see the same error. I’m not sure how to use the function ‘glDrawBuffersARB’. Can someone tell me what arguments I would need to give this function so that I can have a frag shader write to each of the color attachments? I’ve been trying to use it with an array of GLenums with values like ‘GL_DRAW_BUFFER0_ARB’. I found these values on the extension spec page, http://oss.sgi.com/projects/ogl-sample/registry/ARB/draw_buffers.txt
glReadBuffer (GL_NONE);
glWriteBuffer (GL_NONE);
Call one or both of them only if you don’t need such capabilities (reading from the buffer and/or writing to them).
If you need capabilities to be enabled (which is the default way) then use Read/WriteBuffer (GL_FRONT). Only this one is recognized under FBOs.
I simply know nothing about arb_draw_buffers… And I’m pretty sure you don’t need it.
Hope that helps.
Well, from further reading the spec, I think I should have been using ‘GL_AUX0’ and other variants. However, this seems strange. My header files only support up to GL_AUX3, which leads me to believe that only 4 attachments can be written to at once. Does anyone know if this is actually limited by the API or if I am still using the wrong values?
Hi Jide,
I have a fragment shader that writes to:
gl_FragData[i]
where ‘i’ is 0 to N buffers that I would like to write to each at once. I thought glDrawBuffers was needed to allow a shader to do this. In fact, my shader won’t compile if I don’t request this extension.
Well, things are working now. I started using values similar to ‘GL_COLOR_ATTACHMENT0_EXT’ and rendering to all my color attachments started working. It makes sense to me, but strange that this would work, since these are the values I thought I initially tried…oh well. If anyone is doing MRTs, then my advice is to use the color attachment [i] GLenum values.
from EXT_framebuffer_object spec (http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt):
If the GL is bound to an application-created framebuffer object,
<buf> must be one of the values listed in table 10.nnn, which
summarizes the constants and the buffers they indicate. In this
case, <buf> is a symbolic constant specifying a single color buffer
for writing. Specifying COLOR_ATTACHMENTi_EXT enables drawing only
to the image attached to the framebuffer at COLOR_ATTACHMENTi_EXT.
Each COLOR_ATTACHMENTi_EXT adheres to COLOR_ATTACHMENTi_EXT =
COLOR_ATTACHMENT0_EXT + i. The intial value of DRAW_BUFFER for
application-created framebuffer objects is COLOR_ATTACHMENT0_EXT.
Symbolic Constant Meaning
----------------- -------
NONE no buffer
COLOR_ATTACHMENT0 output fragment color to image attached
at color attachment point 0
COLOR_ATTACHMENT1 output fragment color to image attached
at color attachment point 1
... ...
COLOR_ATTACHMENTn output fragment color to image attached
at color attachment point n, where
n is MAX_COLOR_ATTACHMENTS - 1
-------------------------------------------------------------------
Table 10.nnn: Arguments to DrawBuffer(s) and ReadBuffer when the
context is bound to an application-created framebuffer object, and
the buffers they indicate
Search for issue 54 also:
(54) What should we name the logical buffer attachment points,
bearing in mind the relationship to ARB_draw_buffers?