PDA

View Full Version : Ray Picking vertices



sevenfold
05-16-2017, 12:04 AM
When ray picking vertices in OpenGL, how does one exclude hidden vertices?

I always pick the closest vertex, but this vertex may be hidden from view (e.g. behind other objects).
How can I tell if this picked vertex is hidden or not?

Ray picking reference:
http://schabby.de/picking-opengl-ray-tracing/

Dark Photon
05-16-2017, 06:59 AM
In that article, "ray picking" is independent of OpenGL. So you just exclude the hidden vertices from your search. It even says to intersect "the picking ray with all your visible objects in your scene".

Now if you mean OpenGL selection mode, that's long-since deprecated and you're better off to use a picking technique implemented on the CPU in your app (such as the "ray picking" approach the articles discusses).

sevenfold
05-16-2017, 12:57 PM
Yes, I'm using ray-tracing to pick vertices, not OpenGL selection mode. I'm not using octrees any other kind of spatial partitioning hierarchy to store my scene.

My problem is determining whether the vertex I picked is visible or not. This vertex can either be hidden behind another object, or it can be on the backside of a visible object, like a sphere. That article explains the ray-tracing part, but it skips these important details.

Do people use ray-tracing to solve this problem, or do they use something else, like reading pixels from the color/depth buffer, after the scene has been rendered?

sevenfold
05-16-2017, 03:54 PM
I think I'm just going to use color picking for simplicity. It solves my visibility problem, which means I can throw the whole ray-tracing code out.

GClements
05-16-2017, 05:10 PM
Do people use ray-tracing to solve this problem, or do they use something else, like reading pixels from the color/depth buffer, after the scene has been rendered?
It depends. On the frequency of picking (on-click versus on-move), the complexity of the scene, and the extent to which the rendered scene is appropriate for picking.

Neither approach is unambiguously preferable.

Note that modern OpenGL gives you more options with the rendered approach, as you can render to multiple buffers simultaneously, and also render to integer buffers (so you can store IDs directly, rather than having to encode them as R,G,B triples and hope that they don't get garbled by precision issues).

sevenfold
05-17-2017, 02:31 PM
Note that modern OpenGL gives you more options with the rendered approach, as you can render to multiple buffers simultaneously, and also render to integer buffers (so you can store IDs directly, rather than having to encode them as R,G,B triples and hope that they don't get garbled by precision issues).

Integer buffers sound interesting, but I've never had a problem with picking colors. Using integer buffers would require a OpenGL 3.0 context.

If I set glColor3f to (1/255, 2/255, 3/255), then I get back (1,2,3) as bytes. Color precision seems adequate.