depth values in picking

Hi,

I don't understand how values are set for depth in picking mode.

I use
(float) (selectBuffer.get(ptr)& 0xffffffffL) / 0x7fffffff;
and get a float between 0 and 2.

Objects on the near plane gets z = 0, and objects on the far plane gets z = 2, which I assume is correct. But for an object in the middle between near and far planes, I don't get z = 1, unless I use an orthographic projection.

I can't find the explanation for this in openGL documentation, so any help is welcomed :)

Thanks,
Mathieu

Hi

Depth values (which are in the range [0,1]) are multiplied by 2^32 - 1, before being placed in the hit record.

http://www.manpagez.com/man/3/glSelectBuffer/

I assume you use the code I fixed several years ago:
http://forum.jogamp.org/bad-use-of-depths-in-Picking-java-td1446213.html

The distribution is not linear, that's why you don't get exactly 1 in the middle.

Hi,

Yes, I use your code :
(float) (selectBuffer.get(ptr)& 0xffffffffL) / 0x7fffffff;

Ok, distribution is not linear, but is there a way to calculate "real" z value to the depth value recorded (using frustum values and eye position) ?

Thanks,
Mathieu

There is no consistent way to achieve that but anyway, the use of OpenGL picking is not recommended, it can cause big slowdowns on some machines, especially when using shaders and/or when drawing lines. Color picking is even less reliable as some colors are simulated on some laptops (then some colored objects can never be "picked"). Rather use software picking.

Edit.: There are some informations about OpenGL picking here.

Hi,

I know that picking is deprecated, but I've never noticed any problem with it. Furthermore, for my use, it always takes less than a frame rendering, so it's ok.

About depth, I think I've found a quite correct function to map values returned to screen z value :

f(z)=eyeToScreenDistance*(z-1-d/eyeToScreenDistance)/(z-1-eyeToScreenDistance/d);

where :
* z is the min/max value returned, 0 for near plane and 2 for far plane
* eyeToScreenDistance is the distance from eye to the screen, which for me is in the middle between near and far planes
* d is half the distance between near and far planes

I've tested it and got good results (error less than 0.001), to improve it I think the function needs something like sqrt((z-a)²+b²) corresponding to some normalization.

I've tested it only in cases where the screen is in the middle between near and far planes ; and where d is also equal to screen view width.

Cheers,
Mathieu

Hi

Mathieu Blossier wrote

I know that picking is deprecated, but I've never noticed any problem with it. Furthermore, for my use, it always takes less than a frame rendering, so it's ok.

Use it at your own risk. As long as it is only for a tiny project, if it works for you, why not? However, I wouldn't use it in a "serious" application. The fact that on a particular machine you have never noticed any problem with it doesn't mean that there is no problem. For example, color picking isn't a viable approach on lots of Lenovo laptops.

Mathieu Blossier wrote

About depth, I think I've found a quite correct function to map values returned to screen z value :

f(z)=eyeToScreenDistance*(z-1-d/eyeToScreenDistance)/(z-1-eyeToScreenDistance/d);

where :
* z is the min/max value returned, 0 for near plane and 2 for far plane
* eyeToScreenDistance is the distance from eye to the screen, which for me is in the middle between near and far planes
* d is half the distance between near and far planes

I've tested it and got good results (error less than 0.001), to improve it I think the function needs something like sqrt((z-a)²+b²) corresponding to some normalization.

I've tested it only in cases where the screen is in the middle between near and far planes ; and where d is also equal to screen view width.

Cheers,
Mathieu

Thank you for the tip. What do you mean by "screen z value"? I just want to ensure that you can't use glUnproject or something similar in your case.

Hi,

The picking has been tested on hundreds of machine, and it seems to work :)

I don't think I use color picking : I just set the gluPickMatrix, then render a part of my scene, and get objects that are in the selected rectangle.


"screen z value" is the location of a point in z from the screen, in pixels unit. glUnproject may do what I want, but I don't understand how to make it works with gluPickMatrix.

Cheers,
Mathieu

Mathieu Blossier wrote

The picking has been tested on hundreds of machine, and it seems to work :)

I worked with an OpenGL expert who collaborated with Previznet on the software PlayViz used by But and showcased on France 2 (French public TV channel) and (with me) at the French institute of petroleum and new energy (IFPEN), I told him to avoid using the OpenGL picking and he stopped using it when he noticed some very important slowdowns by using it with shaders in its own CAD software. If you don't use any shader, it "should" work. Moreover, the OpenGL picking is in the compatibility profile which means that you'll have to find another solution in the future except if you don't plan to support the Core profile but you may not have the choice. Keep in mind that some fixed functions are emulated in recent drivers, especially those not deserving to be "in the metal". I know zero OpenGL-based Java engine using it, there should be a reason. Use it at your own risk, again.

Mathieu Blossier wrote

"screen z value" is the location of a point in z from the screen, in pixels unit. glUnproject may do what I want, but I don't understand how to make it works with gluPickMatrix.

Look at Nehe tutorials, especially the one using glReadPixels and gluUnproject:
http://nehe.gamedev.net/article/using_gluunproject/16013/
http://dmi.uib.es/~josemaria/files/OpenGLFAQ/glu.htm

Hi,

Ok, thanks for the advices ! I'll reconsider picking when I'll have time.

Thanks for the link to nehe.

Cheers,
Mathieu

Edit : I've started the project I'm working on before 2008, so it was jogl1 with openGL 1 or 2... that's why I'm using picking and no shaders :)

Cheers,
Mathieu

I understand your position, my main project doesn't use shaders except the JogAmp build-in ones under the hood when someone tries to run it under Linux ARM with OpenGL-ES 2 and I started using JOGL in 2006 (JOGL 1 at this time). I had to port most of the tools to JOGL 2 by myself, it was epic. Good luck :)

Thanks for your help and good advices ;)

All the best,
Mathieu