Posted by gouessej on Dec 27, 2013; 9:12am
URL: https://forum.jogamp.org/picking-tp4031052p4031064.html

ul wrote

But on the other hand if you do it high-level you basically take on to implement the ray-tracing approach to graphics. And that's no cakewalk. I found it better to tap into the triangulation based graphics you find in the majority of graphics cards today.

Regarding the use of compute shaders, the advantage with my approach is that you don't need to treat lots of special cases, like picking spheres. picking cones, picking this or picking that. It works on any surface as long as it's triangulated and that's the beauty of it. If you can draw it you can pick it. In 3D graphics the triangle is a primitive data type like say a floating point number. Both are independent of what you draw or calculate respectively.

It's not specific to your approach. Some engines manage only triangles and when they deal with picking, they don't have special cases to treat. Moreover, don't expect a huge speedup when performing the equivalent of the intersection test between a ray and a triangle on the GPU. If you need to use this result on the CPU, you'll have to transfer it. When I use software picking in Ardor3D, there are several intermediary steps that allow to skip heavy computation when there is obviously no chance of picking something, it uses bounding volumes before testing on the mesh. If your mesh doesn't change, you don't even have to recompute its bounding volume.

There is an example using GL_TRANSFORM_FEEDBACK_BUFFER here:
http://github.prideout.net/modern-opengl-prezo/

I like this one because the author takes care of discarding the rasterization.

Edit.: Your approach is less flexible but maybe it fits better into your particular needs. For example, it is nice if you don't have any hierarchical mesh data.