Antialias and glAccum slowness (Just me?)

OpenGL Development JOGL Development
#1

Hello,

Sorry for the terribly noob-esque inquiry, but I was just playing with glAccum in my jogl program, to implement an antialiasing solution, 'cause why not, and I noticed it’s VERY slow indeed. I am rendering simply 4 shaped cubes each frame, and using 4 to 8 passes with the accumulation buffer (using the example code from the red book, 3rd edition) slows me down to right about 6/8 FPS on my brand new intel iMac.

2.0 GHz Intel Core Duo
1 GB RAM
ATI Radeon X1600 256MB
PCI Express

The standard upgraded one.

I ran also Apple’s OpenGL Profiler, and it’s spending about 90+ percent of the OpenGL time in glAccum(…). So, then is this an expectable drop for any situation, a slowdown due to the binding of native code to Java, an artifact of the build to Intel code, a known JOGL bug, or perhaps I’m just being stupid and trying for antialiasing the entirely wrong way…?

Anyhow, let me know what you think of, so’s I can stop wandering around ignorant.

–Scott

#2

Accumulation buffers are only supported in hardware on some really shiny new cards, I’m not sure if yours comes under that or not. If it’s not supported in hardware you’ll get the software fallback with is (unsurprisingly) very slow.

To get antialiasing you usually need to create a framebuffer with a specified number of samples (usually 2/4/6/8) and everything is pretty much automatic after that point. In LWJGL this just means setting the samples param at display creation, but I’m not sure how Jogl handles this (or even if it’s supported yet).

#3

JOGL does support FSAA. Take a look at setSampleBuffers and setNumSamples in GLCapabilities.

#4

Cool. FWIW, this was actually the first thing I tried, but I must’ve missed something on the way. All I could figure out how to do was:

GLCapabilities caps = new GLCapabilities();
caps.setSampleBuffers( true );
caps.setNumSamples( 4 );

…and to then use this capabilities in GLCanvas canvas = new GLCanvas( caps );… But it wasn’t doing any antialiasing, so I went back to the Red Book… ^^;;

What should I be putting elsewhere in the code to either get FSAA turned on or to draw into a framebuffer to do it by hand? I couldn’t find anything on this online or here on the forum, though I’ll look again.

–edit— I saw some suggestions to do:
gl.glEnable( GL.GL_MULTISAMPLE_ARB );
…render
gl.glDisabe( GL.GL_MULTISAMPLE_ARB );

but I could not find a reference for that in the javadocs, and my compiler can’t find it either…
–/edit—

–Scott

#5

Did you check out the demos.multisample.Multisample demo in the jogl-demos workspace? Does it work on your machine?

#6

Thanks for that tip. Apparently, no, it doesn’t work. I checked the demo and the source, and the source is what I’ve been trying, and the demo doesn’t run correctly, because there’s no AA in the one that’s supposed to have it. Has anyone seen this on MacOS X before? Seems like someone ought to address this, either at Apple or elsewhere… Now I guess I’d better write a Cocoa app to check whether or not my mac will do it at all… I checked the OpenGL Driver Monitor, and it says that Multisample is available, Max Sample Buffers = 1, and Max Samples = 6…

That seems like it should be able to do it, yes? Also, I know that WoW can do some kind of AA that they call MSAA…? Any idea how that’s done, perhaps? Or why Blizzard doesn’t use FSAA?

–Scott

#7

Well, if nothing works you can always do Wu’s algorithm. :wink:

There’s a link to one of Micheal Abrash’s articles on that page that explains it exquisitly.

This is, of course, all in jest. But it’s kind of fun if you enjoy doing that kind of stuff.

#8

I just tried the JOGL multisample demo on my office Mac (G5, NVidia GeForce 6800) and it works fine. What JOGL are you running on your Intel-based Mac? Have you set things up to build JOGL out of the CVS repository? I don’t know how up-to-date gziemski’s Universal JOGL binaries are and we aren’t yet set up to provide Universal binaries in JOGL’s nightly builds.

#9

I think the build of his (I didn’t make it myself, though will try when I get home) was from a couple of weeks ago. There’s a new one I might try, but I’ll look into grabbing the CVS source and building it myself.

I know FSAA works, though, as I recently downloaded the (PPC) build of GLQuake which newly supports FSAA, and it runs beautifully, barring rosetta input slowdowns.

I’ll let you know.

–Scott

#10

Okay, I went and compiled everything by hand, and the demos RUN, but the multisample demos still does not do any antialiasing. >.<

sigh Any more suggestions…? Maybe it’s an Apple or ATI problem?

–Scott

#11

Hi,
I’m embarking on learning JOGL too and just to confuse things I’ve got some questions. After seeing these problems with simple anti-aliasing I’m worried.

I am moving away from Java2D in games because its only good when its accelerated and its acceleration is incredibly moody (scaling and too much anti-aliasing destroys acceleration). I only want to use JOGL for 2D graphics (ortho mode).

I’ve got 2 questions:
Q1 Is JOGL finished & reliable and is it possible for a beginner to do things like anti-aliasing, scaling & texture painting without spending months learning the API?

Q2 What proportion of computers have OpenGL and can interface with JOGL? (I’m suspicious because on some computers that I’ve run my Java2D game using the OGL pipeline there was no hardware acceleration). If OpenGL isn’t supported, is my JOGL-coded game stuffed?

Thanks,
Keith

#12

Are you 100% sure about this based on the visual output, or from some message being printed to stdout? The GLCapabilitiesChooser functionality isn’t all there on OS X so any messages printed by the demo to stdout aren’t likely to be correct.

What JDK version are you running? If the current 5.0 developer preview, have you tried 1.4.2?

Do you have another Mac to test on? Things work fine on my PPC based Mac with NVidia hardware, but there are obviously two major differences between this configuration and yours.

#13

I just tried Java 1.4.2, and I get the same result. Also, I am 100% sure (visually) that there is no AA going on in the multisample demo on my machine. All pixels are only WHITE or BLACK. There is no gray along the edges of the lines whatsoever. This is using JVM 1.4.2, also.

Should I go into something to print out capabilities? I know that GL_ARB_multisample is available, as I’ve checked for that one on my machine already. (using gl.isExtensionAvailable( “GL_ARB_multisample” ):wink:

–Scott

#14

Hmm. I wonder whether there’s a stupid bug in the Multisample demo. Could you try calling gl.glEnable(GL.GL_MULTISAMPLE) in Listener.init() in Multisample.java? It looks like it assumes GL_MULTISAMPLE is enabled by default which probably isn’t guaranteed. (Ideally Listener’s constructor would take a boolean indicating whether to enable GL_MULTISAMPLE, but this should at least test whether FSAA is working through JOGL on your machine.)

#15

Just tried that, (sorry it took so long) and it doesn’t seem to work still. Also, I tried my same code (same build and everything) on another Mac (12" PoerBook from a year ago), and I got the antialiasing just fine.

–Scott

#16

Since you have the ability to build the source tree could you try modifying MacOSWindowSystemInterface.m (in jogl/src/native/jogl/)? In the arm reading “if (sampleBuffers != 0)”, try adding some code setting the NSOpenGLPFAMultisample attribute to YES, rebuild and see whether that changes the Multisample demo’s results.

#17

I tried adding that as you said, but I get a compile-time error, and ant doesn’t seem to want to give me more detailed info on gcc’s compile-error. >.<

Here’s the code arm you’re talking about:

if (sampleBuffers != 0)
{
	NSOpenGLPFAMultisample = YES;
	attribs[idx++] =	NSOpenGLPFASampleBuffers; attribs[idx++] = sampleBuffers;
	attribs[idx++] =	NSOpenGLPFASamples;       attribs[idx++] = numSamples;
}

I noticed in XCode that there’s no auto-complete option for NSOpenGLPFAMultisample, though there is for several other things, so it looks like it’s seeing connections. I also tried adding

#import <AppKit/NSOpenGL.h>

to the top, as that’s where it seems to be refferenced, but that didn’t work either. I’m sure it’s just a simple thing I’ve missed.

–Scott

#18

No, it should look like

if (sampleBuffers != 0)
{
	attribs[idx++] =	NSOpenGLPFASampleBuffers; attribs[idx++] = sampleBuffers;
	attribs[idx++] =	NSOpenGLPFASamples;       attribs[idx++] = numSamples;
	attribs[idx++] =	NSOpenGLPFAMultisample ;
	attribs[idx++] =	YES;
}
#19

Okay, sorry 'bout the mustake. I made the change and still nothing changes in the multisample demo…

–Scott

PS: Sorry for being so difficult… T_T

#20

OK, thanks for trying this. I really don’t know what’s going on; I would think that if you are getting full-screen antialiasing with other OpenGL programs then JOGL’s support for this should just work. If you have a small example of a Cocoa app which achieves antialiasing on your machine then please post it and we can try to diagnose further what’s going on. Unfortunately I don’t have the time at the moment to go to Apple’s Compatibility Lab in Cupertino to try to work on the same kind of machine you’re on. You may also want to post on the mac-opengl mailing list since this appears to be an issue specific to the Intel-based Macs.