I have some problems with this mode and I thought someone could help.
My application installed on certain Windows machines return 0 as the number of selection hits even though the selection buffer is not at all empty. Has anyone seen something like this? I am sorry I cannot be more specific. I installed the application on five different PCs all of them running XP Pro SP2. Picking works on three of them but not on the other two, where
SelectionHits=glRenderMode(GL_RENDER);
returns 0 even though the buffer has valid data and I definitely am clicking on an object.
There is a second - relatively minor - problem I can’t get rid of. Quite often names that represent geometry far from where I click with the mouse appear in the selection buffer as hits. These objects have identical minimum and maximum z-values in the buffer which also should not happen as these are 3D objects.
Is there any difference (graphic card vendor, driver version) between the working and nonworking computers? I seen programs having problems with picking on ATI cards with relatively recent drivers.
There is a second - relatively minor - problem I can’t get rid of. Quite often names that represent geometry far from where I click with the mouse appear in the selection buffer as hits. These objects have identical minimum and maximum z-values in the buffer which also should not happen as these are 3D objects.
I think that the content of the buffer is defined only for first SelectionHits hits. Anything beyond that might be remnants of temporary working data.
“I think that the content of the buffer is defined only for first SelectionHits hits. Anything beyond that might be remnants of temporary working data.”
I don’t really know what you mean. I used glLoadName for each geometry (object) rendered and I clear the selection buffer before switching to GL_SELECT mode.
I think selection is a relic of an earlier era in GL’s history… should probably be avoided in favor of more forward looking methods, like using an ID buffer of some kind or better still just casting rays. It’s not likely in high demand right now so it’s probably not a prime candidate for favoritism, and it’s going way completely in GL3 besides, afaik.
That does not help me much, I am afraid. There must be something wrong here. I am quite sure this mode is still used quite frequently and with some success otherwise I would have found a lot of complaints on the net.
What I meant is: If the glRenderMode returns X, the buffer might be changed even outside the part corresponding to the first X hits. However such changed bytes might contain anything.
I am quite sure this mode is still used quite frequently and with some success otherwise I would have found a lot of complaints on the net.
Look for complaints about incorrect selection inside the Maya on some newer ATI cards. Of course since all your cards are Nvidia one, this should be something different.
It looks like either I am doing something terribly wrong or the problem really is in the driver. I would like to put the blame of course on the latter, this behaviour that affects some PCs but not others even though the hardware is very similar if not almost identical is very strange.
But even on my PC I use for development, although glRenderMode returns something (>0), but depth values can be completely wrong. I tried to make a workaround by using the selection buffer only to identify possible hits without analyzing the depth values, then using gluProject to get the screen coordinates of the center of the possible objects and compare these to the mouse coordinates.
This is maybe a crude solution, but at least it is a definite improvement. If anyone has a better idea though, I would appreciate it.