Collision Detection

[Clayton]

Wow! This is amazing, this amount of effort deserves some more bits! +400 bits sounds good for now

[richcash]

Thanks Freakman

Well, it's not as amazing as I thought it would be before I made it. It's actually quite a bit slower than checking a point at every angle on one ellipse to be inside of the second ellipse.

However, when it comes to ellipses that are almost as big as the screen and bigger, that method becomes inaccurate. Or, if you start checking a point at every 0.1 degrees or 0.01 degrees to increase the precision, then that method becomes much slower than mine. Mine can also be used in conjuction with time-based collision, if you want to do some crazy math.

There still might be a really effiecient way to do it using geometric proprties (like I did with similar ellipses), but I can't think of one.

More sections to come.

[Skynet]

Options I can think of:
-Approximate the ellipses with polygons
-Split your plane up into discrete parts (maybe integers mapped to screen pixels) and see if a coordinate is hit twice (Use Bresenham's line algorithm to fill the interior once you have the values of the points on the perimeter...it's really fast)
-Similar to the last, approximate perimeter of ellipses on a integer/fixed precision plane, then flood fill from the center of each ellipse. Compare result to the sum of the area of both ellipses.

I may be talking out of my ass, but these ideas seem to make sense. Of course, they're all approximations. I believe you're 100% correct in saying that the equations Maple spit out run the risk of incurring huge truncation errors, and I'd hazard a guess that approximating an ellipse in integer or fixed-point precision would produce better results. (Unless you're using something like Maple, which is powered by black magic)

[richcash]

Skynet wrote:

Options I can think of:
-Approximate the ellipses with polygons
-Split your plane up into discrete parts (maybe integers mapped to screen pixels) and see if a coordinate is hit twice (Use Bresenham's line algorithm to fill the interior once you have the values of the points on the perimeter...it's really fast)
-Similar to the last, approximate perimeter of ellipses on a integer/fixed precision plane, then flood fill from the center of each ellipse. Compare result to the sum of the area of both ellipses.

... but these ideas seem to make sense. Of course, they're all approximations.

What you're saying does make sense, and it would be smarter to use an approximation for ellipses that are realistic sizes (can fit on the screen). Your methods are similar in performance to checking several points on one ellipse to be inside of the other ellipse (you can do this by plugging in theta at, say, every degree into the parametric equations of one ellipse). I call these collision detection by induction (I like naming things!).

Like I said before, the rounding errors occur when the ellipses are too skinny (say that one ellipse's major axis is 20 times larger than its minor axis) or if the ellipses are too small (have radii under 10). But for huge ellipses, my function thrives. I tried out my function on two ellipses : one was 3000(x-radius) X 800(y-radius) and the other was 2000 X 500. It detected the collision perfectly with no loss of speed. Any above methods would become much worse than my function with these ellipses and larger.

It's possible that there is an effiecient function out there using geometric properties, but I can't think of one and a quick internet search resulted in nothing. So I say just use my long function only for massive ellipses.

[Flipmc]

Wow! Thanks for this!
I'll need it sooner or later.

[DanielG]

massive necro, good tutorial though.