I’m trying to figure out selection mode. I think I’ve got the basics down, but a few things are still fuzzy.
For basic selection, it seems that there is no need to call glPushName() more than once; glLoadName() will suffice. If the name stack contains only one name at any given time, and all drawing is done on the z=0 plane with glOrtho, then each hit record in the selection matrix will contain 4 unsigned ints: 1 0 0 <name>.
Is that correct?
Is there a way to mark certain primitives as ignored, so that they won’t generate hits? (Other than glPopNames to 0, since that isn’t a great practice.) I could load in a special name for such, perhaps 0, but this still seems like it could fill the selection buffer unnecessarily.
Another question. I’m seeing gluPickMatrix suggested as the easiest way of limiting the drawn volume to an area just around the mouse. However, everything I’ve looked at says that this needs to be called before glOrtho (or gluLookAt, etc) on the projection matrix.
This is slightly annoying, because it means I need to track the current projection in my code if I don’t want to resort to glGets (usually slow?). I can’t just push/pick/pop like I’d prefer to.
Anyone know an easy way around this?
May I ask: why do you want to use the selection mode in the first place?
I’m creating a tool which will display 2D representations of graphs, and allow selection of graph nodes using the mouse. I’m working in GTK, but drawing the actual figure in OpenGL (using gtkglext).
I had wondered whether selection mode was the best way to do this, but none of the other options (for instance: coloring each primitive uniquely) that I’ve seen seems as scalable. You hit the 255-primitive limit pretty fast when using colors, unless you bring float buffers into the equation, and I’d prefer not to do that for now. It’s an option, though.
255? RGBA gives you 32 bits, 8 bit per channel. Selection mode is slow and deprecated. I strongly advice you against it. But then, also, I am a big enemy of selection and feedback modes
Somehow that slipped my mind. That approach does have the issue of not being able to cycle through overlapping nodes if they happen to share the pixel you’re clicking on, but since I added a zoom control, that shouldn’t be too much of a problem.
Why don’t you just use ray picking / ordinary hit testing with bounding shapes? (circles, rectangles, shape composites, or even complete pixelmasks)
Far more flexible, easier to implement, and you don’t have to track all the OpenGL stuff.
(altough shooting rays for 2d graphs is a bit useless, I guess )