   gluUnProject is giving me unreliable results
  I'm working on a level builder currently.  I have a 3D scene, and am using textured quads to represent objects in the scene.  The game I am making this for is going to be a top down game set in space, so I have made the level builder from this point of view as well.I have gotten picking working fine in OpenGL, but I need to extend that functionality to allow the user to click and drag these textured quad icons in my scene.  I had it sort of working simply by moving based on mouse input, but the results were innaccurate and I'd like to do it the right way.Now I use gluUnProject to map my window-space mouse coords to my object-space coords.  However, The values returned from my gluUnProject are either enormous or way to small, and I can't seem to figure out why.  I've looked at multiple tutorials, one from NeHe, and a few others, and I don't see any significant differences in their procedures and mine.  Here is the code for my mouse handling:[source lang = "cpp"]// see if the left button is being heldif (nFlags == MK_LBUTTON){// if we don't have an object selected, just break outif (m_pRender->GetCurObject() == -1)return;double x, y, z;GLfloat winZ;GLdouble modelMatrix[16];GLdouble projMatrix[16];int viewport[4];glGetDoublev(GL_MODELVIEW_MATRIX, modelMatrix);glGetDoublev(GL_PROJECTION_MATRIX, projMatrix);glGetIntegerv(GL_VIEWPORT, viewport);glReadPixels(point.x, point.y, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &winZ);// since we are viewing the scene from a top-down perspective, our z-axis is acting// like the window-space y-coordinate, hence why we are assigning our fMin and fMax.z's to y gluUnProject(point.x, point.y, winZ, modelMatrix, projMatrix, viewport, &x, &y, &z); m_pRender->GetObject(m_pRender->GetCurObject())->fMin.x = x; m_pRender->GetObject(m_pRender->GetCurObject())->fMin.z = y;m_pRender->GetObject(m_pRender->GetCurObject())->fMax.x = x + 2.0f; m_pRender->GetObject(m_pRender->GetCurObject())->fMax.z = y + 2.0f;}I've tried passing '0' as the third parameter to gluUnProject(), as well as '1' both with varying results.  I'm never placing anything above or below the xz-plane (i.e. objects should have a constant y position of 0.0f) so I don't really care about the depth of things....which could be part of the problem.I've been struggling with this for a while now, any insight would really be appreciated, thanks.   
  Here s a piece of code of my gamedev library which works perfect so far.At least I didn t discover any bugs yet.Look at the iRealY part, you have to do a little adjustment there, thats due to the windows client space layout, the top left is (0,0) however in OpenGl you have a different setting (check you glViewport call)inline vector3d GetCameraPickDir(int32 x, int32 y, const vector3d& vecOrigin,const modelviewmatrix& mv, const projectionmatrix& pm, const viewport& vp){int32 iRealY;float64vecWorld[3];iRealY = vp[3] - y;gluUnProject((GLdouble)x,(GLdouble)iRealY,0.0,mv,pm,vp,&vecWorld[0],&vecWorld[1],&vecWorld[2]);vector3d pos(static_cast<float32>(vecWorld[0]),static_cast<float32>(vecWorld[1]),static_cast<float32>(vecWorld[2]));return (pos - vecOrigin);};;  Thanks Basiror, I tried what you suggested, but there was no noticeable change in my results.  Again, the x, y and z values (which are supposed to represent my object space coords) are still giving me undesireable results.  The values are either very small ( < 0.002 ) or very large ( > 9000).  The strange thing is that if I click at origin and look at the results, and then move really far away from origin and click again, the values are usually very close.  I can tell they are incorrect because I'll move a large distance from origin, click, and I get x, y and z values that are still less than zero.I saw one tutorial where someone was using gluUnProject twice, one for the near plane and one for the far plane, and then calculating a ray between the two, I've tried this method as well, but have had similar results.I'm really stumped on this one, any help is greatly appreciated.   ;  Try it with 0.0f as winZ as I did it in my example.I just normalize the vector and use this for picking that works fineAlso could you please post some logs (camera position, the unprojected vector..)   ;  I've tried using gluUnProject() with 0.0f, 1.0f, and even with a calculated winZ based on a glReadPixels() call.  None of them are giving the desired results.My camera is originally positioned at (0.0f, 15.0f, 0.0f) with a forward vector of (0.0f, 1.0f, 0.0f) meaning it's looking directly down the y-axis.The values I'm getting from gluUnProject vary depending on what I pass as the z portion of the window-space coordinates. Clicking at my world-space origin gives the following values for x,y and z:0 as third parameter to gluUnProject: x = 0.00175, y = -0.00525, z = -0.099999 1 as third parameter to gluUnProject: x = 17.5008, y = -52.50248, z = -999.93407winZ as third parameter to gluUnProject: x = .26253, y = -0.81259 , z = -15.00003  EDIT: This looks like the _most_ correct results, however if I drag more the mouse more then a few pixels, these numbers increase exponentially.  While debugging, these are the values I get the first frame, but in the second frame they jump to astronomical values in comparison, something like x = ~235, y = ~99, z = ~ 300 ... strangeNow, ideally, when I click in the center of my window (which initally is my origin in world-space) then I should be getting values of 0 returned for my object space x and y positions, and -15 for the z (remember I'm looking top down, translated up 15 in the y-axis), but clearly that's not happening.Thanks for your help so far Basiror, I'd really like to figure out what's going on here.   ;  The Z-buffer is normalized between 0 (nearplane) and 1 (farplane), right? If you are using a perspective view (not orthographic), the worldspace coordinate of any given pixel on the screen going only out to the nearplane is going to be very small. On the other hand, the farplane is likely well beyond what you are trying to click on, and so the coordinates become exagerated.Are your near and farplane set to 0.1 and 1000, respecitvely?That may explain the issue with z= 0, 1.When you use the winZ given by glReadPixels - is it always going to be reading something from the relevant plane that you want coords from? If not, the clear value for the z buffer is 1 (farplane), so the values will still be exagerated...I'm not very experienced, but I prefer selection (see glRenderMode(GL_SELECTION) ) to mouse picking. I don't even know if you can expect the plane you are looking straight down at to have a constant z-value or to be concave. But I'm sure it can work out alright.   ;  Thanks Bob, that clears up some things for me.  I am actually using glRenderMode(GL_SELECTION) currently for my picking, I am using the "built in" OpenGL picking to see which object in the scene I should be moving.  These objects are all aligned with the xz-plane, meaning their y position should always be 0.  However, I may have to do, as you suggested, something concerning the near and far planes, maybe cast a ray from near to far, then test for an intersection with my textured quads?  Anyone else have any ideas i can try out?  Thanks   ;  So you weren t doing a ray triangle intersection after all?I assumed you did .^^basically you can do it like this1. drag the objectgluUnproject(x,y.....)- you got the pickray now- trace to your object and get the hit position2. drop the object after moving- gluUnproject(x,y...)- do the same as in 1)3.  hitposition 2 - hitposition 1 = mv //movementvectorin order to get proper movement, I would find the dominant axis e.g.: X > Y > Zmeans you moved in the X,Y plane mainly so skip z movement.The radiant editors do it like this otherwise it would be kind of impossible to do vertex editing on convex brushes   