Re: [PyOpenGL-Users] glSelectBuffer problems

[David B. <whi...@gm...>]

On Dec 16, 2007 12:32 PM, Mike C. Fletcher <mcf...@vr...> wrote:

> 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
> reported.
> > 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.
>
> Good luck,
> Mike
>
> --
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>


-- 
David H. Bronke
Vice President of Project Development
G33X Nexus Entertainment
http://www.g33xnexus.com/

v3sw5/7Hhw5/6ln4pr6Ock3ma7u7+8Lw3/7Tm3l6+7Gi2e4t4Mb7Hen5g8+9ORPa22s6MSr7p6
hackerkey.com
Support Web Standards! http://www.webstandards.org/