Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Selection / Picking in OpenGL 3.2

  1. #1
    Member Newbie Kip Warner's Avatar
    Join Date
    Dec 2007
    Posts
    47

    Selection / Picking in OpenGL 3.2

    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?

  2. #2
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,214

    Re: Selection / Picking in OpenGL 3.2

    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.

  3. #3
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,294

    Re: Selection / Picking in OpenGL 3.2

    What happened to colour-tagging ?

  4. #4
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,214

    Re: Selection / Picking in OpenGL 3.2

    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.

  5. #5
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Selection / Picking in OpenGL 3.2

    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

  6. #6
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,294

    Re: Selection / Picking in OpenGL 3.2

    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?

  7. #7
    Senior Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Selection / Picking in OpenGL 3.2

    Quote 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.
    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.


    Quote Originally Posted by Aleksandar
    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.
    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


    Quote Originally Posted by Aleksandar
    I can quote other disadvantages if those are not enough, but ... I think they are.
    the largest one is that it requires glReadPixels that has the effect of stalling the CPU, though there are ways around this.
    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)

  8. #8
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,214

    Re: Selection / Picking in OpenGL 3.2

    Quote Originally Posted by Jan
    The problem is that picking is horribly slow on most drivers, because it is done in software... Then you read the color from the framebuffer (glReadPixels) and thus have the object ID at the pixels position.
    Reading from the framebuffer is also slow. I have never experienced a performance issue, because picking can happen once per few seconds.

    Quote Originally Posted by Ilian Dinev
    32-bit or 64-bit values: instead of colors, you put pointers
    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.

    Quote Originally Posted by zeoverlord
    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 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.

  9. #9
    Senior Member Regular Contributor imported_pjcozzi's Avatar
    Join Date
    Jun 2004
    Location
    Philadelphia, PA
    Posts
    196

    Re: Selection / Picking in OpenGL 3.2

    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

  10. #10
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Selection / Picking in OpenGL 3.2

    "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

Page 1 of 2 12 LastLast

Similar Threads

  1. Picking and Selection
    By chalamov in forum OpenGL: Advanced Coding
    Replies: 2
    Last Post: 03-31-2008, 01:40 AM
  2. opengl picking and selection issue
    By in forum OpenGL: User Software
    Replies: 0
    Last Post: 11-29-2005, 12:29 PM
  3. OpenGL Selection Picking Fails
    By JohnWesterman in forum OpenGL: Advanced Coding
    Replies: 1
    Last Post: 06-26-2002, 02:28 AM
  4. help - selection and picking
    By sadhu in forum OpenGL: Basic Coding
    Replies: 0
    Last Post: 01-02-2002, 12:02 AM
  5. Is using selection buffer for selection or picking slow?
    By mohsin in forum OpenGL: Basic Coding
    Replies: 5
    Last Post: 04-11-2001, 03:56 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean