depth values in picking

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

depth values in picking

Mathieu Blossier
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
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

Mathieu Blossier
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
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

Mathieu Blossier
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
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

Mathieu Blossier
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
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

gouessej
Administrator
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
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

Mathieu Blossier
Hi,

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

Thanks for the link to nehe.

Cheers,
Mathieu
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

Mathieu Blossier
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
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

gouessej
Administrator
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 :)
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: depth values in picking

Mathieu Blossier
Thanks for your help and good advices ;)

All the best,
Mathieu