   Picking (gluUnproject) and Framebuffers
  Hi guys!I've hit a roadblock mentally with something and I can't get my head around it by myself.  I think it might be pretty simple, but I'm pretty simple so that's how I've gotten stuck.I've been working on building a simple editor and I was gluUnproject (or similar) to achieve mouseclick-to-map stuff.  However in order for it to work I have to disable HDR and SSAO.. two post-process effects that force the depth buffer to be stored in a framebuffer (therefore with them on the depth is always 0 from the screen, as it's all rendered back to a quad anyway).So my question is how (without disabling all post-process effects) do I access the depth buffer for "picking" purposes?Cheers guys!   
  I'm really quite stuck on this, I'd really appreciate even some ideas that anyone has even if they aren't sure they'll work! :)   ;  Do the gluUnProject before you do the post-processing effects, using the correct depth-buffer. Then after picking is done, do post-processing.(Or you could do the whole picking thing in a separate pass, that you never display to the screen).   ;  I don't quite follow how I could do the post processing after picking is done, unless I'm saving the click position(s) until the next render pass?  Which I guess could work.  However the scene is always drawn straight to framebuffers, including the depth.Your second suggestion was one I had thought about, but wasn't sure if it was worth the extra set of draw calls.  I'll give this way a try I guess.Thanks for the suggestions!Any other ideas or even suggestions on how best to go about the above methods are greatly appreciated!   ;  I usually use Eriks second suggestion, rendering the objects bounding boxes or other low-poly representation (after culling) and use GL_SELECT / GL_RENDER or manual color-encoded picking. If it's not too much work in your app, it's a really nice way to separate the picking code from the render code.   ;  Yea, you should use the color buffer for picking, since it would get executed between 2 rendered frame, it will just be erased by you're next Render() function call, and it's way faster than using the opengl built-in picking method.   ;  Thanks for the info Vortez, I didn't know that GL_SELECT was particularly slow on some implementations. OpenGL.org even says not to use it.. newsflash for me!   ;  I was planning on using the method you mentioned Vortez, as I'd seen that it was faster (which makes sense when you look at it) than the standard OpenGL picking.Thanks for all the input guys!  I'm sure I'll get stuck again and be back to request more advice!   