setting up multiple render targets

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?