Does anyone have any examples of working code for OpenGL selection - use of glSelectBuffer, etc. - that runs on JOGL on OS 10.3?
I’ve been trying to do this and I get a very ugly error:
Java dies and leaves a log file, indicating that there was a problem in libGL.dylib that blew up when i called gl.glSelectBuffer().
I’m using java 1.4.1 and Gerard Ziemski’s JOGL build from November. Do I need to update?
Any feedback would be appreciated. thanks.
Unless the code has change, GL selection on OSX simply doesn’t work because the code is not designed to allow the selection of different buffer types - it is in fact hard coded. Perhaps I don’t understand what you’re trying to do, but if I do - its not going to work.
You may want to check out the latest build on this site.
I’ve been having the same problem. The problem is that I get a crash whenever I make a gl call in the event thread. I’ll try the code out in other machines.
[quote]I’ve been having the same problem. The problem is that I get a crash whenever I make a gl call in the event thread. I’ll try the code out in other machines.
[/quote]
Describe what you’re trying to do. What do you mean by trying to call gl methods in the event thread. You may be doing something illegal for JOGl altogether.
For what it’s worth, I was simply trying to do 3d selection, straight out of the OpenGL redbook, chapter 13:
GL gl = canvas.getGL();
gl.glSelectBuffer(256,selectBuf);
gl.glRenderMode(GL.GL_SELECT);
gl.glInitNames();
gl.glPushName(-1);
the gl.glSelecdtBuffer() call is where things blew up
Whenever I try to make a gl call during a mouse callback, i crash:
ex:
in the class that implements GLEventListener and MouseEventListener:
public void mousePressed(MouseEvent e) {
System.out.println("mouse pressed");
int x = e.getX();
int y = e.getY();
double point[] = new double[3];
renderer.getPoint(x,y,point);
}
in renderer:
public boolean getPoint(int x, int y, double[]xyz) {
float [] d = new float[1];
System.out.println("about to call read pixel “+x+” "+y);
gl.glReadPixels(x,y,1,1,GL.GL_DEPTH_COMPONENT, GL.GL_FLOAT, d);
int error = gl.glGetError();
if (error != GL.GL_NO_ERROR) {
System.out.println("Error: "+glu.gluErrorString(error));
}
System.out.print("got d is it: ");
System.out.println(d[0]);
return true;
}
The program will crash even when I make what I think is a harmless call like:
gl.glGenTextures(…)
the method that renders the scene is also synchronized…
Thanks
What’s the exception you guys are seeing. I’m not seeing it and right now I’m pushing a significant amout of data through the pipeline. I don’t ever call glSelectBuffer() however. I would suggest that before you report your error you grab either the latest nightly from the site of the binaries - both of which are from 2004.
Take another look at the User’s Guide (on the main Jogl page). You aren’t supposed to make any OpenGL calls except within the context of the calls in GLEventListener.
From the guide:
[quote]It is generally recommended that applications perform as little work as possible inside their mouse and keyboard handlers to keep the GUI responsive. However, since OpenGL commands can not be run from directly within the mouse or keyboard event listener, the best practice is to store off state when the listener is entered and retrieve this state during the next call to GLEventListener.display().
[/quote]
If you want to get a display() call, you can call display() on the GLCanvas, or repaint() (so that AWT will call display on the GLCanvas).
You pretty much need to decide what you’re going to do when display() is called, then do it when you’re told you can. How that’s supposed to work for things like reading pixels, I don’t know.
An issue for you here is that you don’t need the buffers to be swapped when you try to get display() to run just so you can have OpenGL correctly setup. There have been requests to be able to turn off swap buffers. I could see possibly having another method on GLEventListener, which would be be called to do things like what you are doing, without intending to swap.
andy