OpenGL accumulation buffer

Hey,

I want to ani-alias a scene, but the only things I am using now is the glEnable(GL_POINT_SMOOTH etc. all these functions. Now I read that OpenGL was planning to remove this way of anti-aliasing, and that some new driver will stop supporting this method. And because of some other reasons, I want to use multi-sampling as a way to perfomr this action. Could anyone explain this method to me? I read some tutorials, but I couldn’t comprehend the whole story.

Dardan

What does multisampling and point smoothing have to do with accumulation buffers?

I don’t know either but if you want full scene anti-aliasing, then you need to chose a pixelformat that supports full scene anti-aliasing. This is something that is OS specific.

Here is the Windows version
http://www.opengl.org/wiki/Multisampling

well, what i said is that I used this pointsmooth system to anti-alias now. But i heard that there is a technique called 'multisampling" or sth. So i wanted to know how you perfomr this and do this.

ok, seems quite complex…
maybe you can give some tips or sth before I try this out? So maybe you know how to find the suitable pixelformat easily?

Dardan

well, what i said is that I used this pointsmooth system to anti-alias now. But i heard that there is a technique called 'multisampling" or sth. So i wanted to know how you perfomr this and do this.

The title of this post is “OpenGL accumulation buffer”. Multisampling has nothing to do with accumulation buffers, and neither does point smoothing.

I thought you needed the accumulation buffer for multisampling??? So it’s not??
oh terrible mistake…

No, you don’t need a accumulation buffer.

Nothing is going away. You can always create an old GL context and use the old features.

For GL3 context and above, you can create a compatible context and mix and match old and new features. nVidia and AMD support it on Windows.
On the Mac, GL3 context is a forward compatible context.

If you want to quickly see how it would look, then go into your windows control panel, activate FSAA from your nvidia or AMD thingy.

On the Mac, GL3 context is a forward compatible context.

NO IT ISN’T!

I’m so sick of people talking about forward-compatible as though it’s synonymous with core. It’s not. They are two different things.

A core context implements the core OpenGL specification. A forward-compatible context (which you should never use) is one created via the forward compatibility setting. It implements the core specification minus any functionality still marked deprecated.

Not the same thing. MacOSX implements GL 3.2 core, not forward compatibility. Please stop spreading disinformation.

Minus functionality still marked deprecated?

I’m confused. There are 2 possibilities, right?
Core = which has the old stuff removed (this is what I meant for the Mac)
Forward compatible = this is the backward compatible one. Not sure why they call it forward compatible.

There are 2 possibilities, right?

No. There are three.

1: The OpenGL Core Specification. You get this by passing CONTEXT_CORE_PROFILE_BIT_ARB to the CONTEXT_PROFILE_MASK_ARB field.

2: The OpenGL Compatibility Specification. You get this by passing CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB to the CONTEXT_PROFILE_MASK_ARB field.

3: The OpenGL Core Specification, minus references to any functionality in Appendix E.2.1. IE: That which was deprecated but never removed. This is what you get when you pass the CONTEXT_FORWARD_COMPATIBLE_BIT_ARB to the CONTEXT_FLAGS_ARB field and you create a core context (as above).

That last one is called “forward compatibility”, because it was how you checked to see if your code would be compatible with GL versions that eventually remove the deprecated stuff.

I think you’re right about the core, the old functions removed.
But I’m not sure what you said about forward compatibility…
Though I really find this FSAA technique difficult to realyl comrpehend…

For forward compatible, you can look here. There is an example of its effects
http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts

For 3.1, this means that any remaining deprecated functionality (things deprecated in 3.0 but not removed in 3.1) will be removed. Basically, wide-lines. Also, you’re not likely to see implementations offer ARB_compatibility if you pass forward compatibility

Or you can just not use forward compatibility. There’s no point to it nowadays, since very little remains deprecated in core and what is deprecated is clearly not going to be removed.

ok.

Now I really need to learn this multi-sampling technique…