Re: [pygame] Collision Detection with Pygame/OpenGL Surfaces

[Michael George <mdgeorge@xxxxxxxxxxxxxx>]

Dave LeCompte (really) wrote:
> "Michael George" <mdgeorge@xxxxxxxxxxxxxx> 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.
>   
I don't think that the question of "given this point (x,y), what object 
is it touching" belongs in the controller at all.  The coordinate only 
makes sense in the context of some view.  My understanding was that the 
role of the controller is to specify "what happens when this action is 
performed on the model", while the view determines the user interface.
> - 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 don't have any real knowlege about it, but I imagine that part of the 
API is implemented the same way as everything else...I don't think that 
it would be done in main memory.  I mean, it's doing exactly the same 
computations as the graphics card normally has to do, and it's part of 
the openGL API, so why wouldn't it be done there?

If you have a well-organized spatial partition, you're using that to 
cull your rendering anyway, so I think it would be the same either way.
> - 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).
>
>   
Yes, but doing it on graphics hardware i'd wager is faster.  Also, if 
you want to enable fuzzy selection that's bigger than 1 pixel, you'd 
have to to do a more complicated ray casting strategy.
> - 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).
>
>   
I don't think it would be more than 10 or 15 lines of code, seems like 
less of a headache to me than implementing ray intersections for all of 
your various game objects...
> -Dave LeCompte
>   
Cheers,

Mike