View Full Version : OpenGL 2.0, is the accumulation buffer being improved?

02-25-2002, 08:35 PM

at the moment accumulation buffer architecture seems to be very difficult to implement in hardware therefore no consumer level board has implemented it in hardware. Implementing features like Motionblur which can be implemented in hardware using Accumulation buffer can hence be not performed in realtime due to software fallbacks. While D3D implements accumulation buffer functionality in a different way (without using accumulation buffers ..)therefore implementing hardware level motionblurr seems to be not so much performance intensive in D3D. Is there a proposal to add such functionality in OpenGL 2.0 or is there a suggestion to improve the design of Acc. Buffer so that it can be easily and cheaply implemented in hardware?

I couldn't find such a discussion on 3Dlabs site.


[This message has been edited by Fastian (edited 02-25-2002).]

02-26-2002, 02:02 AM
I do not know about OpenGL 2.0 or D3D but multisampling is already supported with hardware support for the more expensive cards. Recently was this discussed here http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005506.html

02-27-2002, 02:11 AM
Accumulation buffers is a whole different story than multisampling. Multisampling is just a special case of accumulation buffers. No PC hardware (that I know of) supports hardware accumulation buffers, except for some 3Dlabs cards (I saw one of them having 64-bit accumulation buffers).

Accumulation buffers are used to "accumulate" several frames into one frame. That way you can do FSAA (several frames with distributed pixel offset), motion blur (distributed time), depth of field (distributed camera position looking through a constant point in space?).

You can probably use it for some other interesting effects too, such as image filtering etc.

With the speed of todays hardware, accumulation buffer effects would actually be useful for realtime rendering. Dropping from 200 fps to 50-30 fps for combining four-six frames could be acceptable for some applications.

[This message has been edited by marcus256 (edited 02-27-2002).]