Posted by ul on Dec 27, 2013; 10:34pm
URL: https://forum.jogamp.org/picking-tp4031052p4031071.html

He he gouessej, I didn't expect my question would end me up in a discussion about the merits of my approach, but okay! :)

In my view you're stuck in the old thinking where you have the "software" running on the CPU controlling a fixed graphics pipeline implemented in hardware.

But the trend is that the graphics hardware is becoming a general processing unit able of massive parallelism. This is what shaders and OpenGL of late and OpenCL is all about. This means that the CPU "software" of yesteryear is getting distributed and more and more is dedicated to the GPU. Hence my approach.

Now if Ardor3D is supposed to be general it cannot rely on a specific structure of the graphics data to be efficient. It should also be able to efficiently pick in the structure-free 3D scene I was talking about, namely 1.4 million spheres. I can draw that in 0.1 seconds and that's a sufficient frame rate for my application because I draw on demand only. I don't have continuous frame production, I redraw when necessary only.

But lets lower the stakes. Lets say you have 170.000 spheres only. I draw them in 10 milliseconds and pick them in 4 milliseconds. That's a frame rate that would be very acceptable also in a continuous frame rate situation.

How does Ardor3D perform in this situation? I'm curious because you claim the "software" approach is so efficient but can you back that up with actual performance data?