Looking at NV_float_buffer I see that deferred shading is one of the possible uses of the extension. However, how would this be realized in practice as ARB_render_texture doesn’t allow writing to one color buffer of the pbuffer if another is bound to a texture. Did I miss something in the spec or is this simply allowed now ? What about on ATI hardware ? Could this limitation not simply be removed from the ARB_render_texture spec ?
Edit: I want to sum lights in one of the floating point buffers while reading from another ( previous sum of lights ) to maintain precision and range.
[This message has been edited by PH (edited 01-07-2003).]
Rendering to non-bound buffers of a pbuffer works correctly on the Radeon 9700. So for instance you can bind the front buffer as a texture and render to the back buffer.
Originally posted by ehart:
Rendering to non-bound buffers of a pbuffer works correctly on the Radeon 9700. So for instance you can bind the front buffer as a texture and render to the back buffer.
It might not work on other ( future ) hardware then. The ARB_render_texture spec says the result is undefined in that case ( issue 14 ). Is it possible to change a spec at this point ? I was hoping that NV_float_buffer and ATI_draw_buffers somehow would make this sort of approach possible ( and guaranteed ). I know Matt from NVIDIA thinks issue 14 doesn’t make much sense ( he even suggested using the read/write ping-pong approach, as did jwatte ). What is the effect of this on 8500 ( non-floating point of course ) ?
It just occured to me that all of this is impossible to implement in OpenGL due to issue 11 in the ARB_render_texture spec ( in addition to 14 ). That is, releasing the color buffer from the texture back to the pbuffer might not preserve its contents.
[This message has been edited by PH (edited 01-07-2003).]
None of our extensions explicitly guarantee this. I don’t think it belongs in any of them, but I think it might make sense to add one that states that rendering to non-bound buffers provides consistent results.
Thanks. Yes, you’re right, it doesn’t really belong in any of those other specs. Could you ( or someone else ), clarify the following regarding issue 11,
When the color buffer is released from the texture (back to the pbuffer)
should the contents be preserved?
No, this may prove difficult to implement on some architectures.
That means the contents of the pbuffer is undefined, correct ? Or is it the contents of the texture ?
Edit: Ok, it seems both are undefined after calling release…
[This message has been edited by PH (edited 01-07-2003).]
ehart:
None of our extensions explicitly guarantee this. I don’t think it belongs in any of them, but I think it might make sense to add one that states that rendering to non-bound buffers provides consistent results.
If you are considering adding new extension, I’d rather suggest going all the way and bringing DirectX 8/9 SetRenderTarget() flexiblity to GL.
The whole goal of color-buffer-switching hack was to get single depth&stencil-buffer shared for multiple color-buffers. Besides the specification problems, the hack is quite limited, as it can only work if all color buffers have the same pixel-format (all fixed-point or all float)
In DirectX 8 we have:
pD3DDevice->SetRenderTarget(color_surface, depth_and_stencil_surface);
In DirectX 9 we have:
pD3DDevice->SetRenderTarget(color_surface);
pD3DDevice->SetDepthStencilSurface(depth_and_stencil_surface);
Notice the interesting fact - retaining current depth&stencil buffer when switching to new color render-target has really become default behaviour in DirectX 9 ! It is really high time to bring it to GL.
This could be as simple as: (DX9 style: retain current other-than-color buffers)
wglMakeCurrentColor(HDC hDC, HGLRC hglrc);
or this: (DX8 style, taking WGL_make_current_read as a pattern)
wglMakeCurrentXXX(HDC hColorOnlyDC, HDC hDepthStencilAndAllTheRestDC, HGLRC hglrc);
NV_float_buffer allows using single-channel (FLOAT_R) and dual-channel (FLOAT_RG) formats for pbuffer, besides the full RGBA.
Can the same be done with WGL_ATI_pixel_format_float ?
[This message has been edited by MZ (edited 01-07-2003).]
For PH’s particular situation, what would be the advantage of using a double-buffered pbuffer? Why not just use two single-buffered ones? I implemented deferred shading using a single float buffer, but I summed my lights in the visible framebuffer because I didn’t really care about precision and range. If I did want to preserve dynamic range, all I’d have to do is create a second float buffer and sum the lights in there, yes?
That said, I agree that the whole pbuffer and RTT mechanism needs work. One of the DX9 features that I really wish we could have in GL is “multiple rendertargets”, i.e. the ability to write to multiple color buffers from a fragment program.
If you wanted to sum the lights in a second float buffer, you would need two buffers. One to read from ( sum_of_previous_lights ) and one to write to ( sum_of_previous_lights + this_light ). These buffers would switch roles for each additional light. However, this switching requires calling wglReleaseTexImageARB and according to the spec, the contents of the pbuffer becomes undefined. Of course, if simple additive blending was possible with float buffers, then it wouldn’t be a problem.
Regarding MRT - this is what ATI_draw_buffers allows. I was planning on using that and storing per-pixel normals and position data and then rendering a screen aligned quad for each light.
I really don’t want to wait for GL2 to be able to do this - it’ll take months before the ARB has designed and approved a new extension.
I’ve been using D3D9 for about a week or so now but would prefer to use GL . The HLSL is great btw and the compiler generates very efficient code .
