Skip to main content
GameDev.net gamedev.net
🔒 Locked

Is this algorithm new?

Started by LuxMentis Jul 22, 2003 at 8:45 PM 6 replies 1k views
Original Post
LuxMentis
LuxMentis
Today I thought up an algorithm that I haven''t seen before for doing basic collision testing. Basically it solves the problem of a sphere moving so fast that it isn''t properly tested on another sphere and it requires almost no slow operations (it requires 1 square root; everything else in part 3 (the new part of the algorithm) is done in 7 operations which are vector additions, subtractions, scalar multiplications, or dot products). That seems pretty good to me, but I don''t know all the algorithms out there. I''m almost 100% sure it works in every possible collision case. I will use the following terms in describing the two hypothetical objects: Potential Collider - The object that is having its movement processed and is checking other objects to see if they would hit it if it were to move to its destination. Target - The current object being tested for collision with the potential collider. Position vector - Position vector of the center of a sphere. Offset vector - The vector added to the current position vector to obtain the new position. Anyway, the first two steps of the algorithm are the same thing that everyone does already. Part 3 is the new part. For each possible colliding object: 1.) See if the potential collider is even traveling in the direction of the target in the first place (simple dot product abort test). If it is, then proceed. 2.) Calculate the length of the offset vector for the potential collider, and the length of the "distance" vector. The distance vector is the vector that points from sphere center to center. If the offset vector''s length is shorter than the length of the distance vector minus the radius of the target, then there isn''t any way they could hit and the collision test aborts. If this is not the case, this new action is taken: 3.) Calculate the orthogonal projection of the distance vector onto the offset vector. This is 2 dot products, a division, and a scalar multiplication of a vector. It''s actually only 1 dot product and a squaring operation, since you need to find (offset dot offset) but that is equal to ||offset||^2. Then take the difference of the projection vector and the distance vector, which is the vector v. Find the length of v, which is the distance d. This requires one vector subtration, a dot product, and a square root. If you''re not familiar with orthogonal projections (or the description was too convoluted to follow), v is the the vector that points from the target''s center and intersects the offset vector at a right angle. Therefore, it is the shortest distance from the center point of the target sphere to the offset vector. It seems logical that if you take the distance d and subtract the target radius, you have the smallest possible "window" that an object would have to fit in to avoid colliding. If the potential collider radius was smaller than this window, it would always fit through. If it was the same size or larger, it would always collide. Therefore r1 > d - r2 is the only way there is no collision. I would state this as r1 + r2 > d is always a collision avoidance, else the two objects must have collided. I believe this test always works, and it seems relatively fast. The slowest operations are the two dot products and the square root. However, since no one uses this already (AFAIK), I think there must be a better way.
LuxMentis
LuxMentis
Oops. Everywhere I wrote "orthonogal projection" I meant "vector projection".
JuNC
JuNC
Sounds like this, I didn''t read through yours in detail, but it does sound very similar.

Even so, the question isn''t ''is there something better?'' it should be ''does it work for me?''.
oliii
oliii
nice, but I still prefer the good old method of doing a ray/sphere second order equation resolution for two moving spheres. One square root also, and quite straight forward.

Basically, it is equivalent to testing two moving sphere of radix r1 and r2 for collision as tesing a ray intersection with a static sphere of radius r1+r2.
Everything is better with Metal.
c t o a n
c t o a n
So what you''re saying is: Have the sphere original center, and it''s desired offset vector (NewPos - OldPos) and then find the minimum distance between this offset vector and the center of the other sphere (I can''t think of a direct formula for this, but how about project the point onto the vector, then say Ray(the_projected_t) - CollidingSphere.Center) and if ShortestDistance < (Radius1 + Radius2)^2, they collide? Sounds like a good idea, but I''m sure it''s been done before...

Chris Pergrossi
My Realm | "Good Morning, Dave"
Chris PergrossiMy Realm | "Good Morning, Dave"
davepermen
davepermen
whats what you want to do? see if two moving spheres do collide? and when/where?

simple:

sphere a,b;

a.velocity += b.velocity;
b.velocity = 0;

b.radius += a.radius;
a.radius = 0;

ray test = ray(a.position,a.velocity);

bool collide = intersect(test,b);

you can use t as well, to interpolate and get the values you want back..



oh, and this one is somewhere in the nehe tut actually..

"take a look around" - limp bizkit
www.google.com
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia
My Page davepermen.net | My Music on Bandcamp and on Soundcloud
c t o a n
c t o a n
Unfortunately, that solution you presented davepermen, is that to solve a Ray-Sphere collision query, you have to use a square root and some aritmatic. What was presented was a method to decide whether or not the spheres intersected (without returning the exact locations) but in only in a few arithmatic commands, instead of a monster square root and an exact value. And I have NO clue how that ray casting one works...even if it works for that matter

Chris Pergrossi
My Realm | "Good Morning, Dave"
Chris PergrossiMy Realm | "Good Morning, Dave"
davepermen
davepermen
it works on the idea that all is relative.. so you can make one sphere non-moving by moving the other relative to it.

as well it doesn''t mather if one sphere is bigger if you shrink the other at the same time. so you can reduce the moving sphere to a point => a ray.

yes it works, done yet.

and.. "monster square root".. dunno:D runs quite fast on my processor..

oh.. yes.. i''m not using the fpu, so..

"take a look around" - limp bizkit
www.google.com
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia
My Page davepermen.net | My Music on Bandcamp and on Soundcloud

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.