I’m trying to test for vertex buffer objects using the gl.isExtensionAvailable(…) method with GL_EXT_pixel_buffer_object or GL_ARB_vertex_buffer_object, but I get false in both cases with a GeForce2 7950 card. The gl.glGetString(GL.GL_EXTENSIONS) gives:
I notice that I don’t see that extension listed, however running glxinfo from the command line I see both GL_EXT_pixel_buffer_object and GL_ARB_vertex_buffer_object are listed. Am I doing something wrong. I’m using the Java Bindings for OpenGL API Specification, Version = 1.1.0-rc2.
For the output of your Java program, I’m looking for the output saying “glXChooseVisual recommended 0x…” indicating what visual was chosen for a given GLCanvas. It should be printed as long as you have a GLCanvas visible on-screen. That’s the only configuration in which you should be able to validly call glGetString(GL_EXTENSIONS) anyway.
It looks like I need to ask you for the output of glxinfo -t -v as well. (No -b.)
As you see the XXX_pixel_buffer_object is not in the list to be choosen but it is available with glxinfo. Also in case it is importatnt I’m using the lastest NVIDIA drivers 1.0-9746.
Can you also post the output of demos.printext.PrintExt from the jogl-demos workspace? I’m trying to understand whether this is somehow related to the use of pbuffers.
Note that the above list contains the extensions you’re interested in. The PrintExt demo uses a heavyweight GLCanvas to create its temporary OpenGL context. I don’t understand why, but it looks like when you’re rendering to an off-screen surface you’re getting a different set of available extensions.
It looks like you’re using a GLJPanel which is using pbuffers internally. Is there a specific reason you’re using that component instead of a GLCanvas? Have you tried using the heavyweight component, and does it improve things at all?
I figured out (just after I posted the last entry) that the pbuffers was probably in use by the GLJPanel which I’m using the GLJPanel. I need the panel because I have some overlapping transparent JInternalFrames, some of which use jogl and some of which use Java2D.
Can you point me to where I could look in the source to see why I’m getting a subset of the capabilities.
One other matter, I’m not sure if its related. Is the OpenGL/Java2D pipeline enabled by default, or do I still need to enable it. When I put
in the jnlp file I get the attached jvm crash report. When I put it in the j2se tag:
The GLXFBConfig selection code for pbuffers on X11 platforms is in src/classes/com/sun/opengl/impl/x11/X11PbufferDrawable.java. You could try playing with which one gets selected (currently the code only allows selection of the first of potentially multiple matching configs). Once the OpenGL context is created you should be able to use glGetString to see what the available extensions are.
I’d also recommend you write a small test case (similar to PrintExt) which creates a small 1x1 pbuffer and a context on it in order to query the available extensions, just to see whether something strange is going on in the GLJPanel implementation. I noticed the creation of a 0x0 pbuffer in your earlier log output which might be a bug in the GLJPanel.
You still need to enable it. It’s probably a bug in NVidia’s drivers that you’re getting a crash in the Java 2D code when you try to enable it. Maybe Chris Campbell from the Java 2D team can shed some light on this.
Ok. I will try this. In the mean time I’ve just found an earlier version of my code that used the 1.0.0 version of jogl before (as I remember it) the gluegen stuff was separated out. In this version I am able to have access to vertex buffer objects and pixel buffer objects in my GLJPanel. I’m gonna try and download the earliest jogl with the gluegen code separated to see if the problem started then.
OK. problem solved. I had downloaded the latest jogl 1.1.0.rc2 but I didn’t use the matching gluegen-rt.jar. It was probably the gluegen-rt-1.0b03 release. When I downloaded the 1.0b04 for January 23 it works. All is good, and I can get all the extensions. However the Java2D/OpenGL pipeline still crashes. Guess I’ll leave that for another day.
Glad to hear things are working. Even knowing what the implementation differences were between the two GlueGen runtime versions, that’s a pretty strange failure mode I don’t understand. Anyway, glad we don’t have to dig further.
