Fast moving objects jump over what they're supposed to collide with
Author
Is the only way to fix this problem to take however much you're going to move an object, put it in a loop where it moves by a pixel then checks for collision over and over until it gets to how far you wanted to move it; or is there a better way?
One way is with swept collision or continuous collision testing (I am not sure if the two are synonyms, but a quick Google of both yields promising looking results). The basic idea is if you imagine the shape that a fast moving object makes in a frame - e.g. a fast, linearly moving 2D sphere will form a capsule shape - and use these shapes in your collision testing, rather than the sphere on its own.
An alternate way (of which swept area collision is a special case) is to consider collision prediction instead of collision detection. When your objects have not collided yet, compute the time when the two will collide (using the equations of movement as a function of time).
I once read an article in which, to avoid these fast-moving-no-collision-found problems, instead of checking collision with the actual object, one would take a bounding volume which contains the object position on the current frame and the previous frame, and then collision test these volumes. That way you'd check if the objects overlapped during their movement, from there you'd find some way to detect where they collided
[edit] Aah, that's what I get for taking too long to reply. Beaten to the punch! ^_^ [/edit]
Well, you should also be able to produce a collision shape that takes into account the object's movement, and check that against potential collisions.
for example, if your fast-moving object is currently represented by a point, you can instead test against a line segment, starting at the object's previous position and ending at its new position. If your object is represented by a circle or sphere, then a pill-like shape should work, and so on.
If you want greater accuracy, and especially if you want to check fast-moving objects against other fast-moving objects, you can do the same for the moving objects that you're testing against as well, and take time of collision into account as well (to determine whether the two objects would be in that place at the same time).
You might find more information here (by following the link under "Collision Detection", specifically) or here (look under "Technical FAQ", specifically, and towards the end, I think).
A search of the forums may well also turn up useful information. ^_^
Good luck! ^_^
Well, you should also be able to produce a collision shape that takes into account the object's movement, and check that against potential collisions.
for example, if your fast-moving object is currently represented by a point, you can instead test against a line segment, starting at the object's previous position and ending at its new position. If your object is represented by a circle or sphere, then a pill-like shape should work, and so on.
If you want greater accuracy, and especially if you want to check fast-moving objects against other fast-moving objects, you can do the same for the moving objects that you're testing against as well, and take time of collision into account as well (to determine whether the two objects would be in that place at the same time).
You might find more information here (by following the link under "Collision Detection", specifically) or here (look under "Technical FAQ", specifically, and towards the end, I think).
A search of the forums may well also turn up useful information. ^_^
Good luck! ^_^
As others have said, use a sweeping test. If you know your vector math, they're pretty easy to implement, and they'll not only tell you whether a collision has occurred, but they can also tell you exactly which point in time, between the two frames, the collision occurred, allowing you to easily find the exact position of the collision. You can reset the objects back to that position, and then do whatever (trigger an explosion there, or change the objects' velocities so that appears that they bounce off each other, etc.).
Here's my favorite article on the subject:
http://www.gamasutra.com/features/19991018/Gomez_1.htm
Here's my favorite article on the subject:
http://www.gamasutra.com/features/19991018/Gomez_1.htm
Keep track of the last position and current position of the object. Construct a segment over these two points , then use that segment for collision checking.
The other way is to adjust your collision timer to be faster , or your object to be slower, or both. Or make your collision umbral to be bigger,like if it collides with a wall, make this wall be a rectangle and give it bigger width. there are several ways to solve this common issue.
The other way is to adjust your collision timer to be faster , or your object to be slower, or both. Or make your collision umbral to be bigger,like if it collides with a wall, make this wall be a rectangle and give it bigger width. there are several ways to solve this common issue.
Also, be a bit careful about how you do the sweeping test. If you're just constructing segments or capsules and then seeing if they overlap, you'll get mixed results. For instance, check out this thing I drew (click to enlarge):
This shows two spheres, a red one and a blue one, each at their position during one frame, and then again at their position during the next frame. The arrows indicate direction of travel. As you can see, their paths intersect. However, if you visualize these spheres moving at constant velocity, you can see that it's actually unlikely that they did collide during this frame. The red sphere clearly moves out of the way before the blue sphere crosses its path. If you just are checking if their paths overlap, you'll get some false positives (i.e., instances where a collision is detected, when in fact there was no collision). Then, finding the actual point of collision is guesswork anyway.
This shows two spheres, a red one and a blue one, each at their position during one frame, and then again at their position during the next frame. The arrows indicate direction of travel. As you can see, their paths intersect. However, if you visualize these spheres moving at constant velocity, you can see that it's actually unlikely that they did collide during this frame. The red sphere clearly moves out of the way before the blue sphere crosses its path. If you just are checking if their paths overlap, you'll get some false positives (i.e., instances where a collision is detected, when in fact there was no collision). Then, finding the actual point of collision is guesswork anyway.
Quote:Original post by CDProp
Also, be a bit careful about how you do the sweeping test. If you're just constructing segments or capsules and then seeing if they overlap, you'll get mixed results. For instance, check out this thing I drew (click to enlarge):
This shows two spheres, a red one and a blue one, each at their position during one frame, and then again at their position during the next frame. The arrows indicate direction of travel. As you can see, their paths intersect. However, if you visualize these spheres moving at constant velocity, you can see that it's actually unlikely that they did collide during this frame. The red sphere clearly moves out of the way before the blue sphere crosses its path. If you just are checking if their paths overlap, you'll get some false positives (i.e., instances where a collision is detected, when in fact there was no collision). Then, finding the actual point of collision is guesswork anyway.
This is actually easy to handle: simply take one of the objects as a fixed point of reference, and find the other object's velocity relative to it. Then do a swept-vs-static collision test; if there is a collision, you can find the time of collision, and use it to transform back to "world coordinates" to figure out where the collision actually takes place in space.
i am new - so its just a thought how i think it could work.
taken the picture:
if the paths intersect, do the following:
calculate the distance object a traveled = dist_a
calculate the point inside of dist_a where the intersection has happened = dist_a_offset.
do the same for object b
if (dist_a / dist_a_offset ) = ( dist_b / dist_b_offset ) then the 2 collided
(maybe it makes sense if this query is made a little bit more tolerant - so that these values just need to be "nearly" the same)
this algorithms tests if the intersection-point is the same relative to the traveled distance of both objects.
dont know if this works - was just a quick thought.
taken the picture:
Quote:Original post by CDProp
if the paths intersect, do the following:
calculate the distance object a traveled = dist_a
calculate the point inside of dist_a where the intersection has happened = dist_a_offset.
do the same for object b
if (dist_a / dist_a_offset ) = ( dist_b / dist_b_offset ) then the 2 collided
(maybe it makes sense if this query is made a little bit more tolerant - so that these values just need to be "nearly" the same)
this algorithms tests if the intersection-point is the same relative to the traveled distance of both objects.
dont know if this works - was just a quick thought.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
