The Red Book (GL 3.0 / 3.1) states that all of the selection / picking routines discussed in chapter 13 are deprecated. That's fine, but it doesn't explain what they are superseded by. Can someone point me in the right direction for how we are expected to perform picking in OpenGL >= 3.1?
It is a very interesting question!
There are other posts on this forum discussing that topic, but none of them gives a satisfying answer.
Until you develop some efficient method of your own, I suggest you to switch to GL 3.2 Compatibility mode, and you'll have all deprecated functionality along with the core.
By the way, I have recently tested GL 3.2 Core against GL 1.5 on the same driver (geforce 190.89) and the speed gain is about 5%. The scene is very complex and there are tens of thousands VBOs, and special traversal algorithm. So, GL 3.2 Core is faster, but application is not only drawing, and switching to new model does not mean a speed boost for sure.
What happened to colour-tagging?
Not good enough!
Disadvantages of color-tagging:
1. Drawing has to be reorganized with lighting and texturing and fogging and EVERYTHING ELSE switched off.
2. No hierarchical organization. This is the most important issue! In the "standard" way of picking I know, for example, that I have picked a window, belongs to the particular building, reside in particular terrain block. It cannot be achieved (or to be more precise, not easily) by coloring.
I can quote other disadvantages if those are not enough, but ... I think they are.
The problem is that picking is horribly slow on most drivers, because it is done in software. That means, you shouldn't use it, AT ALL, no matter what version of GL you are using.
The best way to replace it, is to use color-picking or however it is called. Basically you give every object a unique ID and then render it with the ID packed into its color. Then you read the color from the framebuffer (glReadPixels) and thus have the object ID at the pixels position.
Of course you need to implement all that yourself via shaders etc.
Jan.
GLIM - Immediate Mode Emulation for GL3
32-bit or 64-bit values: instead of colors, you put pointers; a fbo without MSAA/CSAA. What fogging, lighting? You code one shader to write the group, and one shader to write the triangleIDX. First you draw the groups with shader_1, until you find the precise one; then you draw that group with shader_2 to find the triangleIDX. With a shader_3 and rgba32f fbo you could also output up to 16 or 32 float varyings that the VBO provides.
Right?
Actually since in 3.0 you always have to supply your own shaders to render, this is a moot point, just insert a basic color pass trough shader and your good for the entire pass.Originally Posted by Aleksandar
Not good enough!
Disadvantages of color-tagging:
1. Drawing has to be reorganized with lighting and texturing and fogging and EVERYTHING ELSE switched off.
Well you do have 4294967296 different colors to choose from and using a simple lookup table or even encode it in the color itself will fix that
the largest one is that it requires glReadPixels that has the effect of stalling the CPU, though there are ways around this.I can quote other disadvantages if those are not enough, but ... I think they are.
Another one is that your using rendering resources as opposed to if you where using a ray tracing method instead, though that problem can be minimized.
However i would like to see a extension or two to make this easier, basically something like occlusion testing that gives you a list of the closest few fragments rendered on a certain position and a integer/object ID rendering buffer (that is if no such thing exists, haven't checked)
Reading from the framebuffer is also slow. I have never experienced a performance issue, because picking can happen once per few seconds.
Yes, it can be useful, but you need a hierarchy in RAM and efficient algorithm to traverse that structure to find appropriate part of the hierarchy. If I have tens of thousands terrain blocks with tens of buildings, each with tens of windows, I need to traverse that tree to find appropriate. How if I only have a pointer to the window?
Having a just coloring shader is OK! I agree with that. But if I have to support a fixed functionality too, it can be more complicated. Nevertheless, I agree that disabling everything except colors is not difficult at all with shaders.
The number of values that can be represented is not an issue. But, as you have already mentioned, you need additional structure to map it (if they are not IDs or pointers), and the problem of hierarchy stays.
An alternative to color picking is to use the depth buffer. First, shrink the view frustum so it just fits around the picked pixel(s). Make sure you render the scene with view frustum culling for best performance. Before you render an object clear the depth buffer and after you render an object read the depth buffer. If it wrote depth, the object was picked. If multiple objects were picked, you can sort them based on depth.
Assuming your objects write depth, this algorithm doesn't require any changes to your rendering code. Although, as an optimization you will probably want to change your rendering code. For example, I usually trim multi-pass algorithms down to a single pass when rendering an object for picking.
I wrote a blog about this algorithm a while back: Picking using the Depth Buffer.
With all this said, I still really like the simplicity and speed of color picking. I'm surprised no one has mentioned ray casting yet.
Regards,
Patrick
"Reading from the framebuffer is also slow. I have never experienced a performance issue, because picking can happen once per few seconds."
You have never done picking on a scene with millions of triangles, have you? I tell you it is HORRIBLY slow in a detailed scene, when it has to go through a software-renderer (taking SECONDS). The read-back from an FBO is nothing compared to that. Of course this method is supposed to be done in editors and such, where you really want to pick pixel-precise, and a minor lag is no problem, but people get pretty cranky, when they have to wait 2-3 seconds every time they (accidentally) click somewhere.
On small scenes this is not an issue, but then simply doing a brute force raycast on every triangle wouldn't be a problem either...
Jan.
GLIM - Immediate Mode Emulation for GL3
Posting Permissions
