PDA

View Full Version : am I using gluUnProject properly?



dvm
03-09-2005, 09:20 AM
Hi to everyone. I'm creating an orthographic projection with:
gl.glOrtho(-750, 750, -500, 500, -10, 10);
Later on I try to proccess some mouse clicks. I want to get the mouse world coordinates and I do it through this function:

public void makeTransform(int x, int y, double[] worldXY) {
GL gl = glDrawable.getGL();
GLU glu = glDrawable.getGLU();

int[] viewport = new int[4];
double[] mvmatrix = new double[16];
double[] projmatrix = new double[16];
int realy;
double[] worldCoords = new double[4];
/*double[] wy = new double[1];
double[] wz = new double[1];*/

gl.glGetIntegerv(GL.GL_VIEWPORT, viewport);
gl.glGetDoublev(GL.GL_MODELVIEW_MATRIX, mvmatrix);
gl.glGetDoublev(GL.GL_PROJECTION_MATRIX, projmatrix);
realy = viewport[3] - y - 1;
System.out.println("Coordinates at cursor: (" + x + ", " + realy + ")");

glu.gluUnProject4((double)x, (double)realy, 0.0, 1.0,
mvmatrix, projmatrix, viewport, -10, 10,
worldCoords);
worldXY[0] = worldCoords[0];
worldXY[1] = worldCoords[1];
System.out.println("Coordinates at world: (" + worldCoords[0] + ", " + worldCoords[1] + ")");
}Now the problem is I don't get proper world coordinates. For example, if I click on the four corners of the window, these are the window coordinates (which are correct)

0, 600 900, 600


0, 0 900, 0and these are the world coordinates (approximately):

-1240, 740 245, 740


-1240, -230 245, -230There is some logic in them but they require some biasing to get correct results. But how come this is happening? Is gluUnProject4 not supposed to work with orthographic projections? By the way I wrote this in JOGL(java bindings for opengl).

Aeluned
03-09-2005, 10:36 AM
Did you try to play around with the zWin parameter?

I've found that the results of unproject are very sensitive to the zWin value that is passed in.

Also, since you don't really have a perspective divide in glOrtho, I'm not sure you're going to get the results that you want...

just as a minor aside, your function is causing memory leaks; you don't need to get the mvmatrix[16] variables off of the heap, you can allocate them off of the stack - either that or be sure to delete them at the end of your function.

dvm
03-09-2005, 10:56 AM
That's what I'm afraid, that gluUnProject is only for perspective viewing, not for orthographic. Can someone else confirm this?
I'll try playing around with the z and w values.
Don't worry about the memory leak. If you read more carefully you'd see I'm deveoping in Java right now, so...
I kind of miss C++ though. But I have no choice, it's for my work :(

Aeluned
03-09-2005, 11:35 AM
right you are Ken! I must have missed that detail, sorry.

Bob
03-09-2005, 11:15 PM
Originally posted by moucard:
That's what I'm afraid, that gluUnProject is only for perspective viewing, not for orthographic. Can someone else confirm this?
gluUnProject doesn't care what type of projection it is. Heck, it doesn't even have to be a projection at all. All it does is reverse the operation performed by the OpenGL pipeline, which involves multiplication by the modelview and projection matrix, perspective division and viewport transform. As long as the matrices are invertable, gluUnProject will reverse the operation, without caring what kind of matrices it is.

dvm
03-10-2005, 03:15 AM
Then it must be something I'm missing with the Java platform. I don't know. Anyway, since I know the window and world coordinates I do the transformation myself now. Because of issues with threads, I have to deal with everything (for example key processing) inside display. I gotta get used to writing classes. The old way (as in glut) is way to ugly for this. Thanks for the help guys.

pedrodx
03-14-2005, 03:37 AM
Hi!! I don't know much of Opengl for Java, but I think your code:

glu.gluUnProject4((double)x, (double)realy, 0.0, 1.0, mvmatrix, projmatrix, viewport, -10, 10, worldCoords);

might be messing, cause possibly there are implementations of Opengl for Java, kinda like the Interface OGLStuff that the last three parameters of the method are references!!! and not values!!! and so in C/C++... I thought that in here could be the mess up... Just thought, remember... :)
In OGLStuff, the last three parameters are double [] arrays, referencing objX, objY and objZ values... Try it!! See ya later...