|
![](/i/fill.gif) |
>
> distSq < radius1Sq + radius2Sq + 2 * max( radius1Sq, radius2Sq )
>
> So now we have a test that doesn't require taking any square roots, but it
> isn't as "tight" as it could be - it will return true sometimes when the
> circles aren't intersecting.
>
> Can this be improved?
>
> - Slime
> [ http://www.slimeland.com/ ]
>
>
If the loose test indicates possible intersection then perform the more
expensive exact test using Sqrt(). If you can eliminate the majority of
cases cheaply then the higher cost is amortised.
In a similar case but where I have radius1, radius2 I do the following
to reduce the number of cases requiring more arithmetic operations:
float rSum = radius1 + radius2;
float xDiff = x1 - x2;
if (xDiff > rSum) return false;
float yDiff = y1 - y2;
if (yDiff > rSum) return false;
if (xDiff + yDiff) < rSum return true;
return (xDiff * xDiff + yDiff * yDiff < rSum * rsum)
Sqrt() isn't needed at all but of course this is a different scenario to
yours.
As always, you would need to measure the performance of different
schemes on your actual data and processor. Too many condition tests and
intermediate operations can end up being more expensive than Sqrt()
given modern FP capabilities.
Post a reply to this message
|
![](/i/fill.gif) |