## gluProject &lt;-&gt; gluUnproject help please

szgezu
Unregistered

Post: #1
Dear All,
I would like to ask how can gluProject be used for giving the same result as gluUnProject would do it as I have only access of gluProject (this is because I code in perl with its opengl module and only the gluProject seems to work). I am not so good at the mathematical aspect of this so that's why I ask people more clever than me in this field.
(The end of this code would be a selection of an object in a 3d enviroment but I could find example codes only in C and I can get on very slowly with the conversion of the C code into perl, so if awhole code example would come I would be more impressed :-), but a simple answer for the quation would do the trick for a while ;-) )

Thanks a lot!

Regards,
Geza Szabo
Member
Posts: 114
Joined: 2005.03
Post: #2
You'd need the inverse matrix of the projection and view matrices. To calculate the inverse of a matrix, I found the following in the Newton tutorials:

Code:
```inline dMatrix dMatrix::Inverse () const {     return dMatrix (dVector (m_front.m_x, m_up.m_x, m_right.m_x, 0.0f),                     dVector (m_front.m_y, m_up.m_y, m_right.m_y, 0.0f),                     dVector (m_front.m_z, m_up.m_z, m_right.m_z, 0.0f),                     dVector (- (m_posit % m_front), - (m_posit % m_up), - (m_posit % m_right), 1.0f)); }```

You'll probably need to adapt it to your own way of storing matrices. The important part here is that the 3x3 part that describes the rotation is transposed and that the location parts are the negative dot product of the first, second and third column vector with the original location vector (horrible sentence, I know). If you feed these matrices into gluProject, you should get the same results as with gluUnProject. I haven't tested this, though. One thing that might be possible is that you need to swap the modelview and projection matrix, but my math skills aren't good enough to say whether this is right or wrong.
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
That's not a general inverse function. It'll only work for inverting orthonormal matrices, I think.
szgezu
Unregistered

Post: #4
Thank you the answer Cochrane! That is what I defintely need!
"You'd need the inverse matrix of the projection and view matrices."
Do you mean that I feed gluProject with
@projected=OpenGL::gluProject_p(mousex,mousey,z( (?) what should stay here? 1?)
invert(modelview),
invert(projection),
viewport)

Unfortunatley I do not understand even the names in the code sniplet you inserted:
"m_front.m_x, m_up.m_x, m_right.m_x, 0.0f" ...
What do m_fron, m_up, mean?
Can not be the explaining sentence following it written in more formal? I get more and more confused, the more times I read it. :-)
szgezu
Unregistered

Post: #5
Can someone explain it to me why it can happen that if I have a rotating object in the 3d enviroment, and if I always feed the gluProject function with the same object coordinates (but the viewport, modelview and projection matrix is always updated of course), the result of gluProject is always the same?
I see that modelview matrix is changing because of the rotation. How can that be that this not affect the result of gluProject?
Member
Posts: 151
Joined: 2002.09
Post: #6
You definately need to swap your matrices, and also you have to adjust your vertexes to the viewport calculations done by gluProject.
I'd suggest you multiply both matrices together and then take the inverse and get along fine without gluProject (do stuff the same way as gluUnProject does)

Code:
```2(winX - view[0])                                 -----------------  - 1                                      view[2]            objX                 2(winY - view[1])            objY   =  INV(PM)    -----------------  - 1            objZ                      view[3]             W                                      2(winZ)       - 1                                         1```

The projection matrix most probably isn't orthonormal so you'd have to use a different method for inversion. there's some methods here: http://www.gamedev.net/community/forums/..._id=365952

AnotherJake Wrote:gluProject changes the projection matrix, not the modelview matrix. They are separate and are used for different purposes in the rendering pipeline. If you keep feeding gluProject the same numbers every frame you'll get the same results, but it will always be unaffected by anything you do to the modelview matrix, like object rotations.

huh? gluProject isn't supposed to change any of those matrices. what are you talking about? it all depends on what you feed into gluProject, works fine for me at least.
Moderator
Posts: 3,591
Joined: 2003.06
Post: #7
Hog Wrote:huh? gluProject isn't supposed to change any of those matrices. what are you talking about?
Absolute crap is what I was talking about actually. I can't believe I brain-farted that badly. Sorry. I thought I was talking about gluPerspective, and for some God-only-knows-what reason I completely read it that way. Un-freakin'-believable... I deleted that message.
szgezu
Unregistered

Post: #8
Thanx all of you! This forum is the most usefull among a dozen other! This was the only where I got helpful answers, and smart people who know what they speak!
If I need help again with this I return here. Now I try to implement these suggestions!
Apprentice
Posts: 19
Joined: 2005.11
Post: #9
So just how slow is gluUnProject and gluProject?

In an RTS game, I see there being two ways of selecting units. One being get the X, Y Mouse coordinates, gluUnProject those onto the grid where your units are, get those X, Y, Z coordinates, then compare that position to all the units (in that grid/screen), and if it's less than some number select that unit.

Or you could get the XY mouse coordinates, and then call gluProject on all the units (in that grid/screen), and compare those results.

Which would probably be faster?
szgezu
Unregistered

Post: #10
I don'tknow exactly, because I have implemented the gluProject function after all, because it had weird things also. But thinking on this problem it is totally equal in the mentinoed cases, as the slow thing will be tha comparison between ALL of the units which you mentioned. I would recommend using gluPickMatrix (or sg like this) and gl_select mode, as that way is the most resouce saving method. (I didn't use it because it was also weird in perl (I tried but had a very bad weekend because of it, and hard to debug))