Posted by gouessej on Dec 27, 2013; 1:28pm
URL: https://forum.jogamp.org/picking-tp4031052p4031067.html

I load a piece of a town in the suburbs of Paris with Ardor3D, the meshes are less complicated than a real artwork manually created by a computer artist but more than a scene with 1.4 million spheres and the picking is necessary to be able to use the guns of course. As it is interactive, the frame rate must be acceptable and it's obviously drawn in less than 0.1 seconds (even on an ATI Radeon 9250 Pro bought in 2004) especially when mesh instancing is enabled (this technique is used in the Ardor3D-based game "Caromble" too). An extremely naive implementation of software picking would give poor results, I don't deny that but this is not the case in several engines that use software picking including Ardor3D. It depends on your needs but in my case, I need to perform picking faster than drawing. Picking as fast as drawing is enough for you, I see the difference.

If you only perform a typical ray / triangle intersection test on each triangle of the meshes on the GPU or on the CPU, you won't take advantage of the hierarchy unlike what several engines do. If you just move the intersection test from the CPU to the GPU, where is the plus value? Yes it's doable in OpenGL with a tessellation shader (don't forget to send patches instead of triangles as explained here), the transform feedback buffer and preferably by discarding the rasterization but you might have to write several versions of the same shader and you'll need a fallback solution for the graphics cards with no support of this kind of shader (TES and TCS are only available in OpenGL 4 ~= Direct3D 11). It seems useful if you can use the result of the intersection test in the shaders. On my view, implementing picking on shaders requires much more plumbing especially when some computations are still done on the CPU outside shaders.

Edit.: You can even get the primitive id in the GLSL shader, maybe it could be useful for you.