Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualTrienco

Posted 08 October 2012 - 10:57 PM

Black-Rook, look at his posts again. He already gave an example and explanation why this is wrong. Blocks have corners and balls aren't limited to moving purely vertical or horizontal. The width and height of a block is irrelevant, because you can always just slightly brush a corner, even moving just a single pixel (diagonally) can be too much.


[]
[][][][]
[]
[]



Red is the "corner pixel" of the balls rectangle before, orange is the same pixel after. It should be obvious that during that movement, this pixel would intersect the corner of the box. No matter how many "snapshots" or "sub steps" you make, no matter how small your movement, you can _always_ miss collision if you only check for static intersections. The term "corner case" very much applies.

The simple point is this: collisions are dynamic and involve motion. If your collision detection ignores the objects motion, you're not doing collision detection. Sometimes you won't care, but usually you should.


Since break out is using neatly axis aligned boxes and is in 2D, I would highly recommend using this as a chance to learn how to "do it right", rather than waiting with it until you need to do arbitrary geometry in 3D, where some basic concepts might be the same, but their implementation will become a lot more complicated by having to handle the "generic case". "Right" in this case can either mean diving into the lovely world of collision physics (at least a simple sub set, to get the hang of it) or picking a good physics engine and just not worry about the mathy details.


The typical approach is to determine the time of (potential) intersection (t) for each potential edge, then sort by t and determine if they do in fact intersect.

This is were it becomes important to not randomly talk about "lines" when you mean "line segment". Lines are of infinite length and you typically check against a block edge's "line" first, then see if the intersection with that line is actually on the "line segment" (this is why you might want to consider treating the ball as a point, rather than a sphere, as it's making things a "lot" simpler, especially where hitting corners is involved).

To determine if the ball has any chance of hitting one edge, if it was on one side before and on the other after, you need to see if the point of intersection is on the actual edge of the box. If it was intersecting before, you probably have a bug (or are discovering why floats should never be compared with ==), if it is intersection after, treat it like being on the other side.

There are lots of things that make it easier. For example, knowing the balls velocity has positive x, you never need to check against a blocks right side. Knowing the box is convex, you never need to worry about hitting an edge at a right angle (as it is then covered by another edge), etc.

#4Trienco

Posted 08 October 2012 - 10:57 PM

Black-Rook, look at his posts again. He already gave an example and explanation why this is wrong. Blocks have corners and balls aren't limited to moving purely vertical or horizontal. The width and height of a block is irrelevant, because you can always just slightly brush a corner, even moving just a single pixel (diagonally) can be too much.


[]
[][][][]
[]
[]



Red is the "corner pixel" of the balls rectangle before, orange is the same pixel after. It should be obvious that during that movement, this pixel would intersect the corner of the box. No matter how many "snapshots" or "sub steps" you make, no matter how small your movement, you can _always_ miss collision if you only check for static intersections. The term "corner case" very much applies.

The simple point is this: collisions are dynamic and involve motion. If your collision detection ignores the objects motion, you're not doing collision detection. Sometimes you won't care, but usually you should.


Since break out is using neatly axis aligned boxes and is in 2D, I would highly recommend using this as a chance to learn how to "do it right", rather than waiting with it until you need to do arbitrary geometry in 3D, where some basic concepts might be the same, but their implementation will become a lot more complicated by having to handle the "generic case". "Right" in this case can either mean diving into the lovely world of collision physics (at least a simple sub set, to get the hang of it) or picking a good physics engine and just not worry about the mathy details.


The typical approach is to determine the time of (potential) intersection (t) for each potential edge, then sort by t and determine if they do in fact intersect.

This is were it becomes important to not randomly talk about "lines" when you mean "line segment". Lines are of infinite length and you typically check against a block edge's "line" first, then see if the intersection with that line is actually on the "line segment" (this is why you might want to consider treating the ball as a point, rather than a sphere, as it's making things a "lot" simpler, especially where hitting corners is involved).

To determine if the ball has any chance of hitting one edge, if it was on one side before and on the other after, you need to see if the point of intersection is on the actual edge of the box. If it was intersecting before, you probably have a bug (or are discovering why floats should never be compared with ==), if it is intersection after, treat it like being on the other side.

There are lots of things that make it easier. For example, knowing the balls velocity has positive x, you never need to check against a blocks right side. Knowing the box is convex, you never need to worry about hitting an edge at a right angle (as it is then covered by another edge), etc.

#3Trienco

Posted 08 October 2012 - 10:56 PM

Black-Rook, look at his posts again. He already gave an example and explanation why this is wrong. Blocks have corners and balls aren't limited to moving purely vertical or horizontal. The width and height of a block is irrelevant, because you can always just slightly brush a corner, even moving just a single pixel (diagonally) can be too much.


[]
[][][][]
[]
[]


Red is the "corner pixel" of the balls rectangle before, orange is the same pixel after. It should be obvious that during that movement, this pixel would intersect the corner of the box. No matter how many "snapshots" or "sub steps" you make, no matter how small your movement, you can _always_ miss collision if you only check for static intersections. The term "corner case" very much applies.

The simple point is this: collisions are dynamic and involve motion. If your collision detection ignores the objects motion, you're not doing collision detection. Sometimes you won't care, but usually you should.


Since break out is using neatly axis aligned boxes and is in 2D, I would highly recommend using this as a chance to learn how to "do it right", rather than waiting with it until you need to do arbitrary geometry in 3D, where some basic concepts might be the same, but their implementation will become a lot more complicated by having to handle the "generic case". "Right" in this case can either mean diving into the lovely world of collision physics (at least a simple sub set, to get the hang of it) or picking a good physics engine and just not worry about the mathy details.


The typical approach is to determine the time of (potential) intersection (t) for each potential edge, then sort by t and determine if they do in fact intersect.

This is were it becomes important to not randomly talk about "lines" when you mean "line segment". Lines are of infinite length and you typically check against a block edge's "line" first, then see if the intersection with that line is actually on the "line segment" (this is why you might want to consider treating the ball as a point, rather than a sphere, as it's making things a "lot" simpler, especially where hitting corners is involved).

To determine if the ball has any chance of hitting one edge, if it was on one side before and on the other after, you need to see if the point of intersection is on the actual edge of the box. If it was intersecting before, you probably have a bug (or are discovering why floats should never be compared with ==), if it is intersection after, treat it like being on the other side.

There are lots of things that make it easier. For example, knowing the balls velocity has positive x, you never need to check against a blocks right side. Knowing the box is convex, you never need to worry about hitting an edge at a right angle (as it is then covered by another edge), etc.

#2Trienco

Posted 08 October 2012 - 10:55 PM

Black-Rook, look at his posts again. He already gave an example and explanation why this is wrong. Blocks have corners and balls aren't limited to moving purely vertical or horizontal. The width and height of a block is irrelevant, because you can always just slightly brush a corner, even moving just a single pixel (diagonally) can be too much.

    [color=#ffa500][][/color]
  [color=#ff0000][][/color][][][]
    []
    []

Red is the "corner pixel" of the balls rectangle before, orange is the same pixel after. It should be obvious that during that movement, this pixel would intersect the corner of the box. No matter how many "snapshots" or "sub steps" you make, no matter how small your movement, you can _always_ miss collision if you only check for static intersections. The term "corner case" very much applies.

The simple point is this: collisions are dynamic and involve motion. If your collision detection ignores the objects motion, you're not doing collision detection. Sometimes you won't care, but usually you should.


Since break out is using neatly axis aligned boxes and is in 2D, I would highly recommend using this as a chance to learn how to "do it right", rather than waiting with it until you need to do arbitrary geometry in 3D, where some basic concepts might be the same, but their implementation will become a lot more complicated by having to handle the "generic case". "Right" in this case can either mean diving into the lovely world of collision physics (at least a simple sub set, to get the hang of it) or picking a good physics engine and just not worry about the mathy details.


The typical approach is to determine the time of (potential) intersection (t) for each potential edge, then sort by t and determine if they do in fact intersect.

This is were it becomes important to not randomly talk about "lines" when you mean "line segment". Lines are of infinite length and you typically check against a block edge's "line" first, then see if the intersection with that line is actually on the "line segment" (this is why you might want to consider treating the ball as a point, rather than a sphere, as it's making things a "lot" simpler, especially where hitting corners is involved).

To determine if the ball has any chance of hitting one edge, if it was on one side before and on the other after, you need to see if the point of intersection is on the actual edge of the box. If it was intersecting before, you probably have a bug (or are discovering why floats should never be compared with ==), if it is intersection after, treat it like being on the other side.

There are lots of things that make it easier. For example, knowing the balls velocity has positive x, you never need to check against a blocks right side. Knowing the box is convex, you never need to worry about hitting an edge at a right angle (as it is then covered by another edge), etc.

#1Trienco

Posted 08 October 2012 - 10:45 PM

The simple point is this: collision involves motion. If your collision detection ignores the objects motion, you're not doing collision detection.

Since break out is using neatly axis aligned boxes and is in 2D, I would highly recommend using this as a chance to learn how to do it right, rather than waiting with it until you need to do arbitrary geometry in 3D, where some basic concepts might be the same, but their implementation will become a lot more complicated by having to handle the "generic case".

The typical approach is to determine the time of (potential) intersection (t) for each potential edge, then sort by t and determine if they do in fact intersect.

This is were it becomes important to not randomly talk about "lines" when you mean "line segment". Lines are of infinite length and you typically check against a block edges "line" first, then see if the intersection with that line is actually on the "line segment" (this is why you might want to consider treating the ball as a point, rather than a sphere, as it's making things a lot simpler).

To determine if the ball has any chance of hitting one edge, if it was on one side before and on the other after, you need to see if the point of intersection is on the actual edge of the box. If it was intersecting before, you probably have a bug (or are discovering why floats should never be compared with ==), if it is intersection after, treat it like being on the other side.

There are lots of things that make it easier. For example, knowing the balls velocity has positive x, you never need to check against a blocks right side. Knowing the box is convex, you never need to worry about hitting an edge at a right angle (as it is then covered by another edge), etc.

PARTNERS