Alternatives to OpenGL picking...

I am trying to implement a ray based picking system instead of having OpenGL do it using name stacks… I have lots of cores, and my GPU is quite busy!!

I have tried this method…

One way to generate a pick ray is to call gluUnProject() twice for the mouse location, first with winz of 0.0 (at the near plane), then with winz of 1.0 (at the far plane). Subtract the near plane call’s results from the far plane call’s results to obtain the XYZ direction vector of your ray. The ray origin is the view location, of course.

But it seems very inaccurate, even when using double precision.

Am I missing something, or is this generally accepted as being inaccurate?
Unfortunately the link to the SGI FAQ is dead.

UPDATE : Just wondering if this rings a bell with anyone.

The weirdness I am seeing appears to be related to some kind of coordinate range…

If I am stationary then picking simply does not work, unless I am in exactly the correct position.

However, if I am moving it has an about 50% success rate, and is superbly accurate when it hits. I am able to hit tiny objects very easily, and the correct one every time, even when objects are relatively close together and a few pixels wide onscreen.

Basically all I am doing is some simple trig to shoot a ray out to the same visual distance as each object I am checking for a hit against. Then I am doing a bounding sphere check.

Hand tracing the matrix maths when it hits the maths is spot on.
However, when it missed the ray direction vector seems to be slightly skewy on one axis. Sometimes the sign is even reversed.

Does gluUnProject fail often on certain permutations?
I have to admit to being a little confused.

Hilarious! Ok. Solved it. So I’ll add a note here for anyone who has the same problem…

gluUnProject was failing pretty consistently on the second ‘farz’ call.
By reducing the depth range I was requesting it now functions 99.9999% of the time.

If anyone can explain why that is to me I’d be really interested.

Cheers,
scratt.

Hmm, it should be fairly accurate. I have not ever have accuracy problems with this function (but that doesn’t tell anything).

You may want to code your own gluUnproject function to rule out accuracy problems, or avoid out loss of accuracy when passing/converting coordinates. I got my code from:

http://www.mesa3d.org/

Download the source, and search for the function name.

Thanks for the link. That is useful.

Ultimately I do intend to add these functions to my own Maths/CGI library.