On 8/2/07, Dave LeCompte (really) <[EMAIL PROTECTED]> wrote: > > "Michael George" <[EMAIL PROTECTED]> wrote: > > Just out of curiousity, have you compared your approach the gluPick and > > the selection buffer infrastructure in openGL? > > I haven't done performance tests, but several of my concerns about > glReadPixel from the color buffer remain valid with the selection buffer > approach: > > - I'm really nervous about having OpenGL code in my controller logic, that > seems like a really good clue my controller is relying on graphics code > too heavily. > > - the selection buffer is kept in main memory, right? That means I'd be > using OpenGL as a software renderer. The selection buffer wouldn't be the > entire screen, but still, it seems like if you've got a well organized > spacial partition, you can skip a lot of the work that OpenGL would be > doing to generate the selection buffer data.
I know nothing about selection buffers... - doing a ray/sphere intersection is pretty fast. Rendering a sphere to a > selection buffer seems like it would have to be slower (at absolute best, > your selection buffer would be a single pixel, in which case, it could be > as fast as the intersection test, but no faster). > > - doing all those state changes to set up the render properties for your > selection render pass and then switching back doesn't seem like it'd be > any fun to write. You could probably cut and paste the code from somewhere > else, and probably not have to do much maintenance on it, but still, it > seems like a lot of code (and potentially some slow operations on the > hardware). > > > -Dave LeCompte >
