Understanding gluProject particular case

Hi!

I am using gluProject function and since I want to use not deprecated function I am trying to replace it.
Until now I use glm::Project function and I have also implemented gluProject as explain
here.

Everything works fine but in some cases I notice that gluProject outputs the input.

So if I do:

   gluProject( PObj.x, PObj.y, PObj.z,
               ModelMat, ProjMat, ViewportRect,
               &PWin.x, &PWin.y, &PWin.z) ;

I obtain in some cases the same PObj coordinates as result in PWin.
I cannot understand which cases make this happens.
What I noticed during debugging:

  • The matrix stacks contents are ok
  • I always perform orthographic projection (my w value is always 1.0)
  • The result I obtain with the same input but using glm::Project are always in my ViewportRect range
  • An example of strange input/bad PObj (which gives me the same output = input) is x = 530, y = 250, z = 0.54
  • It seems to me that bad PObjs have always z in [0,1] could be possible?

Thanks for every helps/explanation :slight_smile:

gluProject returns GLU_TRUE upon success and GLU_FALSE for failure. Failure occurs if the clip-space (after transformation by the model-view and projection matrices) W coordinate is zero. If it fails, no values are written via the winX/winY/winZ pointers, so PWin will retain its previous value.

The online reference page you linked omits to mention the projective division step. After v’’ is computed but before it is converted to window coordinates, the X/Y/Z coordinates are divided by the W coordinate (unless W=0, which results in failure).

glm::project doesn’t bother checking W, so W=0 will result in infinity or NaN.

The above comments are based upon the source code for GLU 9.0.0 and GLM 0.9.9.5.

1 Like

Thanks for your answer, unfortunatelly I have already tried all you describe:

gluProject returns GLU_TRUE upon success and GLU_FALSE for failure. Failure occurs if the clip-space (after transformation by the model-view and projection matrices) W coordinate is zero. If it fails, no values are written via the winX / winY / winZ pointers, so PWin will retain its previous value.

I checked it and I never have back a GL_FALSE

The online reference page you linked omits to mention the projective division step. After v’’ is computed but before it is converted to window coordinates, the X/Y/Z coordinates are divided by the W coordinate (unless W=0, which results in failure).

Actually I change it and follow here, so I divide for W coordinate but also here I never obtain a zero for W :frowning:

glm::project doesn’t bother checking W, so W=0 will result in infinity or NaN.

At the moment I am not using anymore glm::project but the implementation at the link I gave. I only obtain wrong value when the gluProject give me back PObj = PWin

Any other suggestions are really appreciated :smiley: