I created a little openGL game that used picking to manipulate objects in it. I had used openGL''s inbuilt picking, but found this was totally useless as it only works on a handfull of graphics cards. I have implemented another method where i color each polygon a different color and then reference them by reading the buffer. unfortunately as my program uses double buffering, i cannot use the popular method of drawing my selection test to the back buffer whilst my rendered image goes to the front buffer. so instead i am clearing buffers, rendering my selection test reading pixels, then clearing all buffers again. this means clearing buffers twice which is very costly. has anyone managed picking in a double buffered system before? i have considered using the auxilliary buffers, but am not sure how well supported they are... any help appreciated thanks...

How about using glUnproject() ?

thanks for replying... not sure what you mean though, i thought that was used to reverse a projection matrix or something.

EVERY card that supports opengl can do picking a couple of examples of how to use it come with the glut distribution

http://members.xoom.com/myBollux

Yeah I''m doing picking this way as well ... just out of interest why are you clearing the buffer the second time . With the exception of transparent polys shouldnt the second drawing to the buffer over write the first one? Also extending this, shouldnt you be able to do the depth buffer drawing in the first and then use that in the second color buffer drawing?
Just a rough idea..

-Darkness

zedzeek: im meaning opengl''s built in picking system, this isnt supported by many graphics cards. cards by nvidia and most high end cards are fine, but most peoples graphics cards cant handle this inbuilt system very well.

darkastaroth: im basically clearing all buffers at the start of the displayloop (as usual) then im drawing the objects that should be pickable in rainbow of colors. then i clear all buffers and draw the objects as usual. if i dont clear the depth buffer things mess up because the previous pickable object shared the same 3d space as the render object i guess.

Can a card that doesn''t support OpenGL''s picking mechanism claim to support OpenGL?

I was under the impression that in order to claim OpenGL support a card/driver must implement everything in the OpenGL-specification.

not sure, but i think cards can claim to support opengl without supporting every single feature.

put it this way i copied an exmple program from the opengl red book that did picking, ran it on mine and 4 friends pc (all nvidia cards -geforce or tnt) worked fine. then ran it on 15+ different uni pcs most opengl stuff was fine but messed up on picking (mainly ati type cards etc). it worked on all sgi''s at uni though because they are fitted with high end cards.

tried on uncles pc (bought recently from top manufacturer- but not nvidia card) and picking messed up)

that way i dont think its safe to use inbuilt picking unless you are only using program yourself

Nope you just have to support SOME OpenGL to claim that. For example my card doesn''t support cube mapping and many cards don''t supoort the stencil buffer.

---

Open mouth, insert foot

every card supports picking + a stencil buffer (sometimes though the later aint in hardware) it has to otherwise it isn''t opengl 1.1 compliant.
stuff like cube mapping aint part of the standard yet at the moment its an extension.
another example is multitexture which was added to the opengl 1.2.1 spec.
cards can be opengl 1.2 compliant and not support multitexturing but thats not the case with 1.2.1


http://members.xoom.com/myBollux