Hmm, I think that was intentional. The intent was to get an outline of an object to use it in something like draw.lines or draw.polygon to turn a mask back into a Surface. If there were multiple objects, the outline would be meaningless. It would make sense to be able to get a list of lists of outlines though, I just haven't written that yet. Or a list of masks of connected components; also potentially a useful thing to have.
Nirav On Sat, Aug 9, 2008 at 2:04 PM, Michael George <[EMAIL PROTECTED]> wrote: > It looks like there's a bug in the outline code, in that it will only return > the outline of one connected component. Is that intentional? > > --Mike > > Nirav Patel wrote: >> >> Mike, >> >> I'm not sure if this is what you're looking for, but as of about a >> week ago, pygame SVN contains new functions in the Mask module to do >> pixel collisions. Some combination of the following could help you >> out: >> >> Mask.overlap_mask - Returns a mask of the overlapping pixels >> Mask.draw - Draws a mask onto another >> Mask.centroid - Returns the centroid of the pixels in a Mask >> Mask.outline - list of points outlining an object >> Mask.connected_component - Returns a mask of a connected region of pixels. >> >> I'm imagining something like making a mask the size of the window, >> drawing masks of all the objects you aren't dragging onto it, padding >> that mask by the radius of the object being dragged (for that, there >> isn't yet a function in Pygame, plus it could get difficult when the >> object isn't a circle), and then finding the point closest to the >> mouse that isn't in the mask. It reminds me of robotics stuff I've >> had to do to create a configuration space. >> >> Nirav >> >> On Sat, Aug 9, 2008 at 11:52 AM, Michael George <[EMAIL PROTECTED]> >> wrote: >> >>> >>> The scheme I've been working on is to compute what I call a "shadow", >>> which is the set of all points that would cause a collision if you placed >>> the object there. This is a minkowski sum if you're familiar with that >>> term. Then as the mouse moves, I compute the closest point that doesn't >>> fall in the shadow. So my scheme would handle this case by finding the >>> closest place where the object fits. If you press tab in the demo I sent >>> out earlier it shows the shadow. >>> >>> --Mike >>> >>> DR0ID wrote: >>> >>>> >>>> Hi >>>> >>>> Right, a special case I didnt think off (how often does it apply?). >>>> Anyway, it is the collision response that has to handle this. How would you >>>> handle this case? Slide it along one of the colliding objects until it >>>> 'fits'? >>>> >>>> ~DR0ID >>>> >>>> >>>> >>>> Michael George schrieb: >>>> >>>>> >>>>> I don't think that works. Consider an object smooshed between two >>>>> others. The collision from the one on the left would have a vector >>>>> pointing >>>>> to the right. The collision from the one on the right would have a vector >>>>> pointing left, and the sum would be zero (unless I'm misunderstanding). >>>>> >>>>> --Mike >>>>> >>>>> DR0ID wrote: >>>>> >>>>>> >>>>>> Hi >>>>>> >>>>>> Well, you can apply the 'axis separating theorem' to a 'multi >>>>>> collision (just test all potential colliding objects). As a result you >>>>>> get >>>>>> the penetration depth as a vector, which you could sum up to get a >>>>>> general >>>>>> direction to move you object (in Murmel I did this, IIRC). But probably >>>>>> you >>>>>> know that already. >>>>>> >>>>>> ~DR0ID >>>>>> >>>>>> Michael George schrieb: >>>>>> >>>>>>> >>>>>>> Thanks for the pointer. That looks like good stuff and I haven't >>>>>>> come across it before. I don't think it will apply to my game because >>>>>>> of >>>>>>> the common case where there's a cluster of objects that you need to >>>>>>> respond >>>>>>> to, but I will definitely read it through in more detail. >>>>>>> >>>>>>> --Mike >>>>>>> >>>>>>> DR0ID wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> here is a good tutorial about 2d collision (probably you already >>>>>>>> know): http://www.harveycartel.org/metanet/tutorials.html >>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> > >
