Re: [pygame] Physics, collision detection etc?

[Peter Gebauer <peter.gebauer@xxxxxxxxxxxxxxxxxxxxx>]

Hello Nirav!

Instead of letting the graphics represent collidable areas I can draw 
virtual geometric shapes in the background, this takes less CPU and memory.
Another thing is, I don't need the pixel perfect collision testing, I would 
still be testing against rather simple shapes.
With high resolutions, like 1600x1200, even one tile could consist of as 
many pixels as 800x800, I would have to create a mask of a subsurface from 
that surface, all this takes more time than geometric tests.

Ofcourse, none of this matters since I'll be using OpenGL for my first 
renderer so reading pixels is suboptimal to begin with and keeping a huge 
mask of the entire world is out of the question.
IMO, pixel perfect collisions are neet for sprite to sprite collisions that 
need to be exact, but is no good for large geometric shape collision tests.

Thanks for your input, Nirav!

/Peter

On 2008-10-09 (Thu) 14:52, Nirav Patel wrote:
> Peter,
> 
> The idea isn't to make a mask of the entire world.  You make a mask of
> each individual Surface and provide the offset of where it is in the
> world relative to the Surface you're checking collision with to the
> Mask overlap functions.  This is quite fast, even checking dozens of
> objects against each other, because in the very common case that the
> offsets make it so the objects can't overlap, it doesnt bother
> calculating it and just returns false.
> 
> Nirav
> 
> On Thu, Oct 9, 2008 at 11:46 AM, Peter Gebauer
> <peter.gebauer@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > Hello René.
> >
> > The thing is, in a large world spanning 16000x10000 pixels that will be a
> > huge mask. Even if I reduce the resolution of the mask alone it will be
> > either top inprecise or still too large.
> >
> > I don't want to write for OpenGL alone even though the plan is to use OpenGL
> > as test output. My plan is to build a large world of 3 or 4-sided
> > convex polygons that could be used to detect colliding with large shapes in
> > that world.
> >
> > The best way to do this is probably to expose some of Zhang Fan's physics
> > code, much of the math involved is already there, it just lacks
> > non-rectangular shapes and a nice Python API to access it.
> >
> > /Peter
> >
> > On 2008-10-09 (Thu) 11:41, René Dudfield wrote:
> >> hi,
> >>
> >> Note, that you can find contact normals with the mask module. See mask example.
> >>
> >> For some types of games, per pixel collision detection is fast enough.
> >>  It uses rect bounding boxes as a first pass, so mostly it's not much
> >> slower than rect collision detection.  Assuming you are working in 2d,
> >> and you cache the mask(not regenerating it every frame) that is.
> >> However the mask.from_surface routine is fairly fast, it could do with
> >> some more optimization.
> >>
> >> For opengl, it'd be interesting to do it in a shader too... since then
> >> you could just reuse your drawing routines to draw your
> >> objects(sprites) into a buffer (each with a different color), then use
> >> a shader to find all of the contact normals.  That way your collision
> >> could be pixel perfect, even with different methods of
> >> drawing(cartoon, glow, and other shaders) where the polygon
> >> representation is not correct.
> >>
> >>
> >> cheers,
> >>
> >>
> >>
> >>
> >> On Wed, Oct 8, 2008 at 9:46 PM, Greg Ewing <greg.ewing@xxxxxxxxxxxxxxxx> wrote:
> >> > Nirav Patel wrote:
> >> >
> >> >> If the polygons are Surfaces or can be turned into Surfaces, they can
> >> >> be turned into Masks to do pixel collision.
> >> >>
> >> >> On Tue, Oct 7, 2008 at 11:21 AM, Peter Gebauer
> >> >> <peter.gebauer@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >> >>
> >> >> > Yep, but as I said, I need to find colliding polygons, not pixels.
> >> >
> >> > Pixel collision isn't suitable for all purposes,
> >> > e.g. if you need to find contact normals for
> >> > physics calculations.
> >> >
> >>
> >
>