I would suggest that you take a look at the Ray Picking method which is detailed here..

http://www.opengl.org/resources/faq/technical/selection.htm

The method you are using is deprecated AFAIK in more recent OpenGL implementations, although it may be supported for some time to come.

But in any case doing selection on the CPU side is a better approach these days, and less complex really.

Whatever you decide the notes on the page linked above should lead you to your answer.

gafferuk

10-05-2009, 01:43 AM

Thanks, looking now.

knackered

10-05-2009, 08:45 AM

if your application is anything like mine, the CPU will only have access to approximations of the rendered geometry (bounding volumes), while the actual geometry will be stored on the GPU, or in fact procedurally generated on the GPU (displacement mapping, for example, or any kind of non-standard vertex/geometry shader).
Therefore ray picking on the CPU simply won't be an option (especially these days). I'm hard pressed to think of an application where CPU ray picking would be an option, to be honest. You store your geometry twice, scratt?! You run vertex shaders on the CPU to get the triangles for the picking?!
Collision detection is another thing entirely, and rarely requires the same resolution of geometry as drawn to the screen. Decent picking *always* requires the exact geometry as drawn to the screen. Therefore you should use something like the colour buffer encoding solution, where you do a render pass into a small viewport around the mouse position encoding the batch number into the colour of the batch, then read back the pixel under the mouse position.

scratt

10-05-2009, 07:32 PM

Therefore ray picking on the CPU simply won't be an option (especially these days). I'm hard pressed to think of an application where CPU ray picking would be an option, to be honest. You store your geometry twice, scratt?!

The OP's project looked sufficiently simple to me for ray picking to be more than adequate. It's certainly a step forward from deprecated GL picking name stacks.

As regards your question. I store geometry wherever it is best suited to be stored on a case by case basis. CPU side memory is cheap. Super cheap, and bounty-full. So a duplicate on the CPU side is not a problem at all. Of course if the geometry is on the GPU only then there are other methods. I didn't really see the point of going into that detail and offering that many options here. :)

But as knackered suggests, using the colour buffer is another option (assuming you are not on a device which has problems reading back from the colour buffer with any efficiency).

gafferuk

10-07-2009, 03:20 AM

I can't use color indexing for picking because of the amount of objects in my scene.

Does anyone know of a clean simple demo of shadow mapping and mouse picking?

Thanks.
Paul.

ZbuffeR

10-07-2009, 05:11 AM

You really need to pick among more that 16 million objects ?

knackered

10-07-2009, 08:51 AM

16 million objects visible in a 1x1 pixel viewport, too??!
You only need to store the batch number in the colour, not the....oh I don't know what you're thinking....the pointer to the scene object? Is that what you're thinking? (even if you are, then it's most likely a 32bit pointer, which will obviously fit into RGBA)
So you do your culling, with the frustum for that 1x1 pixel viewport (i.e. freekin tiny frustum), then go through each object that passed the cull test in a loop (for i=...) and the colour you use should just be that integer (i) cast to RGBA/UNSIGNED BYTE.
You'll be happy to discover, by the way, that using this method also gives you the correct picking through objects that have been alpha-tested out - i.e. a polygon with a net texture would allow the user to click on the object behind the net, through the net...in a natural way. To get that functionality on the CPU picking, you'd have to also have the textures stored in system memory, and go through the hassle of calculating the uv intersection etc.

Aleksandar

10-09-2009, 01:02 PM

You really need to pick among more that 16 million objects ?

16 million objects visible in a 1x1 pixel viewport, too??!
Lost of the GL_SELECTION render mode is one of the greatest lost of the new GL model. So far I didn't find enough efficient replacement (although I must admit that I didn't spend much time in the exploration, especially when realized that I didn't get any acceleration after turning one of my applications to GL 3.2 Core ... , and I lost a lot of functionality...) :(

A mechanism of picking using GL_SELECTION mode and name-stack enables hierarchical selection on a very simple and elegant way. Coloring does not!

knackered

10-11-2009, 03:48 PM

GL_SELECTION mode can easily be emulated with the colour buffer method, and also works with alpha-tested pixels - which GL_SELECTION does not.
If something can easily be emulated with existing API (or even improved) then it doesn't belong in the core. You should really be arguing for an update of GLU, not GL itself.

Aleksandar

10-13-2009, 02:20 AM

GL_SELECTION mode can easily be emulated with the colour buffer method...
May I ask you how it can be emulated?

You should really be arguing for an update of GLU, not GL itself.
As far as I know, GLU relies on GL (although I didn't have an opportunity to take a look at the source code). I'm not sure that GLU can offer some functionality that is not exposed in GL, but on the higher level.