On Dec 16, 2007 12:32 PM, Mike C. Fletcher <email@example.com
David Bronke wrote:...
> I'm using GL_SELECT to select objects in my application, and I'm
> getting some strange behavior. It seems that the selection buffer is
> never reset, even though I am calling glRenderMode (GL_RENDER) after
> selection, and am calling glSelectBuffer () before each selection.
> Here's my code:
> GL.glRenderMode (mode)
That's the line that should reset the internal counter inside your
OpenGL implementation that determines how many results should be returned:
An internal index into buffer is reset to 0 whenever selection mode
is entered. Each time a hit record is copied into buffer, the index
is incremented to point to the cell just past the end of the block
of names - that is, to the next available cell. If the hit record is
larger than the number of remaining locations in buffer, as much
data as can fit is copied, and the overflow flag is set. If the name
stack is empty when a hit record is copied, that record consists of
0 followed by the minimum and maximum depth values.
We do a little bit of custom code, but AFAICS we should not be able to
influence the number of hits returned by the selection buffer (see
OpenGL/GL/selection.py and OpenGL/GL/pointers.py for the actual code).
That is, when you enter the mode the count should be reset. When you
exit the mode it returns the internal count.
The buffer remaining the same should *not* be a problem, incidentally,
even if it were. We copy the reported number of records out of the
buffer, and GL should be writing new records for every record it reports
as having been copied in, so though there might be "garbage" at the end
of the array, it should *not* affect your results or the number of them
> Any ideas what I'm doing wrong?
It might be easiest to debug if you printed out the names of each
element you are seeing in the buffer. Stop after the first few frames
and check to see *how* those names are getting added. If you can
disable the display-list usage (i.e. call the rendering code each time)
Actually, I don't use display lists for the actual geometry at all; that's all done in immediate mode, as are the glLoadName calls. I'm not using Push/Pop, because I don't really have any nested geometry... would it be advisable to switch over to Push/Pop anyway?
I was missing the closing glPopName() call in paintGL() though, so I put that back in, and realized that my way of calculating the names needed to change. I was trying to coerce the signed int object ids generated by python's id() call into unsigned ints so I could use them as names, and then get them back as valid ids... instead I just switched to an auto-increment ID for the objects, which seems to work great.
I'm pretty sure the root of the problem was the lack of a glPopName() at the end of paintGL(), since effectively the name stack was simply growing without bound until it overflowed the select buffer.
Thanks for the help!
you should be able to trace through and see each call to glPushName and
glPopName. If you are not balancing those two you may be getting a
run-away stack of names that are left on the stacks between runs. You
could use an assert that GL_NAME_STACK_DEPTH is 0 to be sure you've done
it, if you don't want to disable display lists.
Mike C. Fletcher
Designer, VR Plumber, Coder