glGetIntegerv(GL_VIEWPORT) returns inconsistent values

Started by
5 comments, last by Kalidor 18 years, 5 months ago
I'm sure there is a solution to this somewhere, but I can't find it--and I'm tired of looking for hours and hours, so here goes. I'm trying to convert window to graph coordinates. Yes, I've seen the tutorial, and the tons of posts on this same issue. But I think my problem is rooted in the fact that the values returned in the call to
glGetIntegerv(GL_VIEWPORT, viewport);
are inconsistent (they mostly switch back and forth between a few different sets of values), and I have yet to see anyone post about this problem. My code is very short, and I'm doing 2D so that should make it simpler. If it makes any difference, this is in a QT opengl widget. And if anyone knows of a post that addresses this issue, feel free to just point me in that direction instead of explaining everything again.

resize function:
	glViewport(0, 0, Width, Height);
	glMatrixMode(GL_PROJECTION);
	glLoadIdentity();
	gluOrtho2D(0, Width, 0, Height);
	glMatrixMode(GL_MODELVIEW);
	glLoadIdentity();

On click function (straight out of NeHe tutorial):
	glLoadIdentity();
	GLint viewport[4];
	GLdouble modelview[16];
	GLdouble projection[16];
	GLfloat winX, winY, winZ;
	GLdouble posX, posY, posZ;

	glGetDoublev( GL_MODELVIEW_MATRIX, modelview );
	glGetDoublev( GL_PROJECTION_MATRIX, projection );
	glGetIntegerv( GL_VIEWPORT, viewport );

	winX = (float)event->pos().x();
	winY = (float)viewport[3] - (float)event->pos().y();
	glReadPixels(event->pos().x(), int(winY), 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &winZ );
	gluUnProject( winX, winY, winZ, modelview, projection, viewport, &posX, &posY, &posZ);


My data looks like this (first 4 values is viewport array, last 3 are posX, posY, and posZ):

0 0 239 191 1.83224 -0.355086 -6.54942
0 0 240 191 1.72944 -0.337781 -6.23023
0 0 1250 28 -0.45097 -0.0961251 -0.0345631
0 0 239 191 1.50305 -0.291288 -5.37269
0 0 240 191 1.82233 -0.355923 -6.56485
0 0 240 191 1.78512 -0.348657 -6.43084
Thanks
Advertisement
At first glance, your code seems coherent. Have you tried checking glGetError() ?
"I am a donut! Ask not how many tris/batch, but rather how many batches/frame!" -- Matthias Wloka & Richard Huddy, (GDC, DirectX 9 Performance)

http://www.silvermace.com/ -- My personal website
Quote:Original post by silvermace
At first glance, your code seems coherent. Have you tried checking glGetError() ?

After calling gluUnProject, glGetError() returns 0.
Each OpenGL call can reset the glGetError flag to zero, so you need to check glGetError after the key op's in your code; maybe just after you call gluOrtho2D, glViewPort and glGetIntegerv ?
"I am a donut! Ask not how many tris/batch, but rather how many batches/frame!" -- Matthias Wloka & Richard Huddy, (GDC, DirectX 9 Performance)

http://www.silvermace.com/ -- My personal website
I tried outputting the return value after every glut function call--all zeros.
I discovered the problem (but not the solution):

As I said, this is in a QT app as an opengl widget. There are two other opengl widgets, currently displaying rotating triangles (for no apparent reason). I discovered when I delete those two widgets from the window, the viewport array is now constant, and the (x,y,z) values only vary in the 5th and 6th decimal place. These values are wrong (x and y are always negative fractions like -0.39483), but that's a whole separate issue.
Quote:Original post by hokietoner
I discovered the problem (but not the solution):

As I said, this is in a QT app as an opengl widget. There are two other opengl widgets, currently displaying rotating triangles (for no apparent reason). I discovered when I delete those two widgets from the window, the viewport array is now constant, and the (x,y,z) values only vary in the 5th and 6th decimal place. These values are wrong (x and y are always negative fractions like -0.39483), but that's a whole separate issue.
I've never used QT before so this might not be applicable, but does each widget have it's own rendering context? If so you need to make sure that the correct widget's rendering context is current when you call your mouse click function. You can use wglMakeCurrent to switch rendering contexts, but QT probably wraps that up into it's own functions for each widget.

This topic is closed to new replies.

Advertisement