Posted by gouessej on Dec 29, 2013; 12:16am
URL: https://forum.jogamp.org/picking-tp4031052p4031075.html

I'm not stuck in an old thinking, I just say that shader based picking is only worth in a fully shader based architecture. Moving an operation into a shader doesn't drive it magically faster. JMonkeyEngine 3 has a fully shader based renderer and it does NOT use shaders for the picking as far as I know. You admit it yourself, you talk about parallelism, shaders and OpenCL are better for algorithm that can be parallelized, it doesn't mean that just moving the execution of an algorithm is enough to benefit of parallelism. However, you basically move a ray intersection test into a shader, how can you expect a speedup from that?

Ardor3D and my game are open source, feel free to check your claims by running your picking on the WaveFront OBJ file I generated from an OpenStreetMap file:
http://svn.code.sf.net/p/tuer/code/pre_beta/obj/planet_2.413_48.853_f55ff5ae.osm.obj

A non naive software picking used with some complementary checks to avoid heavy computations can be efficient, the same in shaders too, I just think that you would spend a lot of time in implementing the same thing in shaders and it wouldn't be more efficient. Do you know at least one engine performing frustum culling and intersection tests with bounding volumes in shaders?

Ardor3D is quite flexible, you can even use a render delegate with some raw JOGL code in it, it doesn't prevent you from doing whatever you want with JOGL but I know that tons of developers prefer reinventing the wheel in worse. Each time I enter a new job I find a new "private" scenegraph with some poorly implemented algorithms (with a very few exceptions) :s