Hi All,
I’m a Developer of a CAD Software House.
In our CAD, like most CAD, we need to pick all entites under the cursor, not only the topmost (so the colour picking don’t works fine for us). We always used old deprecated GL_SELECT render method, but in new OpenGL 3.0 this feature will be cancelled.
We have to create a self-made picking like line-box3d intersection, or exist an “hardware accelerated” solution ?
Thanks for help 
You can use occlusion query results to find if any pixel of your rendered geometry has been inside a picking rectangle.
You just need to setup occlusion queries for the individual objects you want to pick and render them in a mode where they are not depth tested against each other.
The occlusion query results will tell you which objects where inside your selection rectangle.
This will only work for primitives which actually render geometry, e.g. triangles which do not hit a raster point will fall through the cracks. If that is a problem you could render the geometry in two passes, the second with points, because points will always render.
This is a good method, thank you.
Probably we can use the occlusion instead make always a depth buffer query, because we also need the Z-Order of entities.
In that case it would be recommended to use a stencil routed algorithm with a multi sampling render target. Each pass captures one layer per sample. It is limited by the number of stencil bits. A 8 bit Stencilbuffer would be able to capture up to 255 layers (in 16 passes with a 16x MS rendertarget). The results are ordered in drawing order.
Unfortunately this can’t be implemented with the current version of OpenGL, because there is no extension to access the samples without a mixing down blitt.
Another possible solution would be depth peeling it works on current graphic cards, but n captured layers need n passes, but the results are ordered by depth, so this algorithm is recommended if the scene has a high overdraw and only a few of the firsts planes should be captured.
A third solution could use stream out and a geometry shader that takes all triangles of the scene as input. Only the triangles with a positive ray/triangle test will be written into the point output stream. The result is very similar to the current selection mode, but can be extended to store also the exact hit position (including texture coordinates, normal… but also the primitive ID)
With these possibilities the old software based picking mode is really outdated…
I was in the same case than nicjedi.
We choose to add a color Buffer (a fbo). Each object has a unique id. The scene is rendered into the fbo and the object’s color is the ID. Of course, the id is limited to 32bits.
To pick something, glReadPixel on the fbo give one or more id, from which we know the selected entities.
In your case, you could use a fbo with a depth attachment to keep the z value.
Thanks to all 
,
we will evaluate all solution, to find the better for us.
Fortunately seem that we don’t need to make a self-made selection method
I don’t want to spread bad mood here, but OpenGL 3.0 doesn’t exist yet and it doesn’t look like it will be ever released.
Just my two cents…
Also if openGL 3.0 will be never released, seems to me that using deprecated method is a bad solution…the day that the support company want to remove it, the software will not works.
Very bad solution if you want to sell your software…
I don’t think driver makers will remove piking, it is still part of the spec and easy to implement. But you are right, using other methods will be faster in many situations.
I can assure you, Zengar, than GL_SELECT mode has been removed from recent drivers in both Ati and Nvidia in mass market products (but still in Quadro/FireGL gpu). I don’t know if it’s consciously or due to temporary issues.
Actually, The OpenGL picking is not disabled but performed in software, which causes amazing drop in performance. Of course, to notice this, the scene has to be big.
There are other threads that confirm that.
For test, see http://www.it.usyd.edu.au/~tapted/slow_glselect.html
It has been performed in software for years, and I am usually the one who keeps telling it to people that go whining about how slow their picking is (just searh the forums). But it is not removed, as the driver still supports it (albeit in software).
ok, I trust in your knowledge of OpenGL, but I encourage you to test to by yourself to notice the performance issues (that didn’t exist few months ago), wherever it comes from (soft or hard).
Anyway, to come back to the point of this topic, does anyone could tell me which picking method is faster between Occlusion query picking and color buffer picking ?
There shouldn’t be a big difference, but colorpicking is more flexible…
Occlusion queries would be slightly faster since it doesn’t have to render anything. But the difference is negligible.
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.