View Full Version : GL_SELECT and software fallback
gedalia
11-10-2006, 03:08 PM
Hi
I'm wondering if anyone's been having performance problems with using GL_SELECT for picking. I'm using NVidia's instrumented openGL driver, and getting a message that it's falling back to software rendering every time glRenderMode(GL_SELECT) is called ie when I try and do a 3d pick operation.
On some cards I'm still getting acceptable performance, on others it's just totally tanking. Is this something that geForces are just not optimized for anymore? Is there a proper way to invoke GL_SELECT that doesn't cause the fall back? I realize that doing this all on the cpu via a BSP/Octtree would be simpler but I'd have to gut a ton of code.
thanks
-g
Reedbeta
11-10-2006, 03:29 PM
I suspect that very few people use GL_SELECT for picking. Rendering everything and asking what fell within a particular area of the screen is just not an efficient method for determining what was clicked on. Consider that if you have N triangles, GL_SELECT picking takes O(n) time while picking via an octree takes O(log n) time if you do it properly. That's a huge difference, so I'm sure the graphics card manufacturers do not consider it worthwhile to optimize GL_SELECT. In fact it is probably only included for the sake of holding to the OpenGL standard.
gedalia
12-28-2006, 07:11 PM
Hi Reed
Thanks for the input, to some degree I agree with you, but the 90.xx nvidia drivers are definitely broken. Take a look at http://discussion.autodesk.com/thread.jspa?threadID=511660. Maya uses GL_SELECT for clicking on things and appears to be hosed on 7900s. You're right I don’t think many games use GL_SELECT for picking, instead they fall back to their octree/bsp tree collision detection pathways. This might be an intentional choice by nvidia to cripple gaming cards and force content developers to trade up to quartos. If memory serves, ray tracers like mental ray, do create a octtree per frame but that's accelerating millions of ray intersection test.
As for your point about “Consider that if you have N triangles, GL_SELECT picking takes O(n)” that’s only true if you have a very naïve picking algorithm, you can use frustum culling with an exceedingly small frustum. If your culling code is good testing against the scene should reduce to a big O much closer to testing against an octree.
There's another advantage to GL_SELECT, with vertex/geometry shaders or just morphing geometry it's pretty hard or just downright impossible to keep your octtree up to date. With GL_SELECT on the other hand anything you can draw you can pick. A decent conceptual equivalent is shadow maps vs stencil shadows. Anything that's drawable can be shadowed with shadow maps, stencil shadows and octrees on the other hand need lots of infrastructure to make them work.
-Gedalia
vBulletin, Copyright ©2000-2010, Jelsoft Enterprises Ltd.