Antialiasing in OpenGL With Accumulation Buffer

Does anyone have experience using jitter with the accumulation buffer to antialias an image, and succeeded in getting it to work? I see the jitter displacement happening just fine. But no matter how I tinker, the OpenGL.glAccum( OpenGL.GL_RETURN, 1.0 ) command simply does not show anything but the last pass with the jitter I used.

I know; pretty obscure. Any suggestions welcome.

I’ve tried to use the accumulation buffer to make ghosting/motion-blur and had problems. At first it would work, but resizing the view the accumulation buffer doesn’t change size with it and I couldn’t find any way to update it. I wonder if it’s deprecated or something.

Looking at my code you need to specify the accumulation bit depth in the Configure event.

Thanks Will. Actually, I’m using your code. I got a copy of ezgl version 1k3 from another post you made in the forums here. It has been an invaluable tool both for coding, but especially for learning. I largely code direct to OpenGL, or rather have my own object hierarchy for doing so. But your comprehensive set of methods makes it so easy for me to lookup the right code, or just call upon it at need. I’m especially impressed with the quality and consistency of the code you’ve written and the very generous use of comments. There is very little obscurity.

It’s heartening to hear you got some clue that glAccum is even alive and willing to pay attention at all. I’ve not even been able to see that. I read some obscure reference on the web last night suggesting that the glAccum facility wasn’t supported on ATI Chips; and the MacMini I use has a built in AMD Radeon HD 6630M; so I’m suspicious but not convinced. Right now I’m writing a little app that will read a lot of the Implementation-Dependent Values with glGetIntegerv() to see if I can learn more. I hope I do.

I’ve also tried using the blending technique for antialiasing polygons and have had no success there either. Antialiasing lines works like a charm; but the polygons seem to be a real hangup for me.

If you’re willing to contact me directly, please do so at


Sure enough. A few queries reveal:


Anyone know if this is a hardware limitation, or whether there’s a way configure OpenGL differently?

Many thanks, this is what I was hoping for :slight_smile:

I’ve found mention that accumulation is removed from OpenGL 3.2 Core. It should be part of OpenGL Legacy (Xojo’s default) but maybe hardware vendors just aren’t supporting it anyways.

This works for me: specify the accumulation bit size in OpenGLSurface.Configure and then GL_ACCUM_RED_BITS returns that value. Test this in 32bit mode as I don’t know if 64bit mode should use UInt64Value.

(edit: this is Mac code, Windows is Configured differently I believe)

[code]Function Configure() As MemoryBlock

dim m As new MemoryBlock(32)

//profile legacy
m.UInt32Value(0) = 99
m.UInt32Value(4) = &h1000

//all renderers
m.UInt32Value(8) = 1

//size depth
m.UInt32Value(12) = 12
m.UInt32Value(16) = 16

//size accum
m.UInt32Value(20) = 14
m.UInt32Value(24) = 8

return m

End Function[/code]

Using that Configure code the accumulation buffer is used to save and draw the last render at 95% while dragging a single cube which makes trails. This is the initial window size.

The problem I have is resizing the window the accumulation buffer doesn’t grow with it. The accumulation effect continues only in the lower left area that’s the same size as the initial view, elsewhere it’s garbage.

I’ve read that the accumulation buffer isn’t particularly efficient and it’s better to use Frame Buffer Objects (FBOs). I’m not familiar enough with FBOs to do a quick test.

[quote]This works for me: specify the accumulation bit size in OpenGLSurface.Configure and then GL_ACCUM_RED_BITS returns that value. Test this in 32bit mode as I don’t know if 64bit mode should use UInt64Value.

(edit: this is Mac code, Windows is Configured differently I believe)[/quote]

Sadly I added the code, but I still get

I did download Xojo to a Windows machine, ran the program, worked first time, and sure enough got perfect jitter-based anti-aliasing. Cuts frame rate draw time to 4 times slower – as one would expect with 4 jitter points – but boy does it look gorgeous. The fact that it just plain worked is a great testament to both Xojo and your code. On the other hand, the blended antialias approach I tried doesn’t appear to do so on the Mac, and is simply solid black on Windows. That one however is possibly my code.

Speaking of which, is there a newer version than 1k3?

Also, any hints on where I can find the documentation for using the Configure facility?

Thanks so much!

Hi Ed,

Here is a quick example that was put together which uses the glAccum blur code and is able to be resized:

Maybe there is something which can be added to your code to help with resizing? Here is the code with no addons with Xojo OpenGLSurface:

Example 24-2 - from Xojo OpenGL Book

This was tested on Windows 10 and Xojo 2016 r4.1

Edit: To increase the Frames-Per-Second speed, increase the TargetFPS variable in Window1 Open Event Handler.

Huh, maybe it’s a Mac thing. That project doesn’t work for me (mac) unless I add the Configure code whereupon it works but suffers the same resize problem. Or maybe my old hardware is fried :frowning:

Also, for my Configure code to work it should have…

dim m As new MemoryBlock(36) //36 instead of 32 ... m.UInt32Value(28) = 5 //doublebuffer

There may be other things needed specifying in Configure but I’m getting away with just these on my system.

There’s one newer version but the only real addition is support for HiDPI; never heard confirmation if it works on Windows though. I’ve been using it instead of building it lately.

That’s interesting. I just fired up my Mac Mini (Late 2012) with Sierra (10.12.2), 2.3 GHz intel Core i7, 16 GB 1600 MHz DDR3 and the example ran with no issues on Xojo 2016 r3. I am updating Xojo to 2016 r4.1 and will provide an update as to how this goes.

Xojo was updated to 2016 r4.1 and the example works as expected. It seems to work on my systems, which makes me wonder if there is something that I haven’t configured?

Are you sure? I found the example so quick it’s hard to tell and had to clear the frame after the loop to make sure the return of accum is what I was seeing.

[code] Next i

OpenGL.glClearColor(1,1,1,1) //added these 2 lines

OpenGL.glAccum(OpenGL.GL_RETURN, 1.0)[/code]

Thanks Eugene, but Nope. I see the same thing as with other programs. Works fine on windows, no antialiasing on my Mac Mini 2011. Difference between the 2011 and 2012 Mac Minis is that 2012 has an Intel HD Graphics 4000, whereas my Mini has a AMD Radeon HD 6630M. I’ve read on the Web that that some non-Intel chips simply don’t support the GL_ACCUM commands.

Same results on both Xojo 2016r4 and r4.1

I just tested this on another Mac Mini (2009) with Yosemite (10.10.5) with an intel 2.53 GHz intel core duo and GL_ACCUM works. It could be the difference between an AMD and Intel chip that you mentioned.

I haven’t added antialias to my example, and this was a blurring GL_ACCUM example that can be resized. I’ll see if I can add antialias to the example.

On Windows when the mouse button is pressed on Window1, then the OpenGLSurface1 motion stops and it is easy to see the 4 accumulated lines.

To see the difference, change the For-Next loop in OpenGLRender1 code to:

For i = 0 to 0 //Take 1 snapshots to remove blur OpenGL.glPushMatrix() OpenGL.glScaled(0.35,0.35,0.35) ' scale at 35% OpenGL.glRotated(25, 1,0,0) 'Rotate cube Downward 'X-axis' OpenGL.glRotated(AnAngle+i*1,0,1,0) 'Continually Rotate cube call DrawCube 'Draw a cube OpenGL.glPopMatrix() OpenGL.glAccum(OpenGL.GL_ACCUM, 1.0) //removed blur Next i

The edges of the cube will no longer blur.

I’ll see what I can do about antialiasing…

Hmm… antialiasing lines seems to be pretty easy… antialiasing polygons are a whole other matter… No solution for antialiasing polygons yet…

The mouse button doesn’t stop motion for me. But I could see the lines before, I just couldn’t tell if they were at 25% intensity. The problem is that the loop draws 4 cubes on screen, ostensibly copying each to the accum buffer then draws the accum buffer back to screen. But if the Accum functionality isn’t actually working then you still see the 4 cubes drawn in the loop. That’s why I cleared the drawing after the loop to make sure the Accum Return is what I see, and it wasn’t until I added the Configure code.

Anyways I think this is a hardware issue as I’ve found more mentions that AMD Radeon (which I have too) doesn’t support Accum well or at all. I’m befuddled though that it does work for me except for resizing, and that your Accum code works on your Mac without a Configure because Apples docs say Accum has to be specified but it’s like your system has one by default.

Ahh yes, my mistake. I overlooked that part of the code and the 4 cubes are redrawn if the Accum works or not. Below is a screen grab from Example 24-02a: Example 24-02a Download

This example has the code you suggested adding:

[code]OpenGL.glClearColor(1,1,1,1) //added these 2 lines

OpenGL.glAccum(OpenGL.GL_RETURN, 1.0) //Return the blur at 100%[/code]

…and also has each accumulation at 15% (15%x4=60%), which shows the darkness of the Windows screen because the accumulated drawing is not at 100%, and has no effect on my OSX intel machines. The glaccum code appears to be working as expected on Windows, and not on OSX, as you correctly wrote.

Do you happen to have a link where it explains the addition of the Configure code that you wrote to make glAccum work?
Edit: Found your code… working on this example for OSX now.
Edit#2: I updated the OSX example with your code that is wrapped in a #If TargetMacOS-#EndIf wrapper and both work as expected with the screen grab on the left side at a lower intensity.

Thanks for your patience and sorry for my misunderstanding. Did you want to create a Feedback report or should I?

Hey Will,

In EulerCamera.mouseDrag there is code for dragging the XZplane while shift is held down. Unfortunately it does so relative to the assumption that the camera is still looking forward toward the XY plane. Thus if you swing the camera around 90 or 180 degrees, shift-mouseDrag moves the camera around in totally non-intuitive ways. I’ve been staring at, and tinkering with, the method for over a day and still can’t get the vector math right on this. You have any suggestions?

Yeah, I never really finished the cameras. There’s a orthographic and gimbal camera I’ve been wanting to make and the modifying mousedrag features were added as an after thought just to have those abilities possible, if not pretty.

The way the EulerCamera works it should be easy add. Here’s how its oriented… start with the camera point a distance out from the origin, specifically at <0, 0, dolly>, and looking in the -Z direction (pretty sure :stuck_out_tongue: ) with the cameras up vector being +Y. Then spin this camera point/orientation about the X axis by angleX, then about the Y axis by angle Y. Finally translate the camera by <lookAtX, lookAtY, lookAtZ>.

The whole change with respect to the XZplane happens when rotating about the Y axis, by the amount angleY. So I think by adding or subtracting that angle to the mousedrag vectors it’ll move relative to the cameras orientation. Ok I try that… here’s some initial code.

[code] if Keyboard.AsyncShiftKey then //shift + xy = move lookat in XZ
//moveLookAt(dolly / 400 * dx, 0, dolly / 400 * dy)

dim uxX, uxY, uyX, uyY As double
uxX = -dx * Cos(-angleY)  //rotated X axis drag vector
uxY = -dx * Sin(-angleY)
uyX = -dy * Cos(-angleY+1.5707) //rotated Y axis drag vector
uyY = -dy * Sin(-angleY+1.5707)
moveLookAt(dolly / 400 * (uxX+uyX), 0, dolly / 400 * (uxY+uyY))  //add vectors and scale[/code]

I’m not sure if the - signs can be factored out, that was guess work until it moved correctly.

Did the Mac have the resizing problem?

I think this is Apples or hardware vendors problem. I’d have to build an OpenGL accum app in something non-Xojo to know better. But turning it on in Configure is how it should be and is working. My license isn’t current anyways…