Swept Path Collision?
by Tim Doty · in Torque Game Builder · 03/28/2005 (4:09 pm) · 15 replies
Is swept path collision detection supposed to be functional in 1.00? I've noticed two problems with quick moving objects:
1. Passing through objects
Current work has two vehicles, one of which has the ability to launch homing missiles. The working map has many walls and the missiles have limited maneuverability so collisions with the walls are often inevitable due to the minimum turn radius. The missile accelerates rapidly from launch with a max velocity of 550. Going at the higher velocities the missiles easily pass through walls, visually jumping (yes, I'm using setImpulseForcePolar(), not setting positions manually -- the only thing I do manually is set rotation because it was easier to control turn rate that way).
2. Multiple collisions where only one should happen
The ::onCollision() function safeDeletes() the missile after resolving the damage. Sometimes damage occurs once, but it can occur up to (at least) five times. This may be related to the missile's velocity.
ps. a search of the forums only came up with two threads, even though I remember seeing swept path collision mentioned in more than that. Sorry if this duplicates an existing thread.
1. Passing through objects
Current work has two vehicles, one of which has the ability to launch homing missiles. The working map has many walls and the missiles have limited maneuverability so collisions with the walls are often inevitable due to the minimum turn radius. The missile accelerates rapidly from launch with a max velocity of 550. Going at the higher velocities the missiles easily pass through walls, visually jumping (yes, I'm using setImpulseForcePolar(), not setting positions manually -- the only thing I do manually is set rotation because it was easier to control turn rate that way).
2. Multiple collisions where only one should happen
The ::onCollision() function safeDeletes() the missile after resolving the damage. Sometimes damage occurs once, but it can occur up to (at least) five times. This may be related to the missile's velocity.
ps. a search of the forums only came up with two threads, even though I remember seeing swept path collision mentioned in more than that. Sorry if this duplicates an existing thread.
About the author
#2
03/29/2005 (12:25 am)
The problem with multiple collisions is known and I think it'll be fixed in the next release. The problem with not working collisions is known but I'm not sure if it'll be handled. 
#3
If this isn't the problem for sure, then it would seem you've hit some known T2D stuff. Thanks much for the report, and please watch for forthcoming updates. :)
03/29/2005 (1:35 am)
Tim, are your missiles both traveling at a really fast rate and turning while doing so? If so, colllisions won't and can't be perfectly accurate. No engine handles that... no good way to prevent tunneling when you're talking about a curved path of travel. Swept colliision schemes only predict for movement along a linear / straight path.If this isn't the problem for sure, then it would seem you've hit some known T2D stuff. Thanks much for the report, and please watch for forthcoming updates. :)
#4
03/29/2005 (1:42 am)
Turning isn't the problem. I've a ball bouncing around only with world limit set. The ball's speed increases after a couple of bounces (without external forces applied) and at a certain point it vanishes from screen - I guess that's due to the ball jumping out of bounds. 
#5
03/29/2005 (4:01 am)
I had this problem, but it was because I had the worldlimit set to bounce instead of rigid.
#6
03/29/2005 (5:17 am)
Since you might have just solved my problem: For a arkanoid type of game, should I set the worldlimit to bounce or rigid? I don't want to loose any speed on bounce and the manual seems to suggest that I should use bounce in that case.
#7
"Bounce" on the other hand is more like a trampoline. If you use "bounce" try using setMaxLinearVelocity(maxVelocity). That should limit the ball velocity.
Or, as others suggested, set your collision material damping to 0 and use "rigid" for the world limits. That ought to work as well.
03/29/2005 (5:28 am)
Well, "rigid" makes use of the rigid body physics and makes the world limits as if they're solid."Bounce" on the other hand is more like a trampoline. If you use "bounce" try using setMaxLinearVelocity(maxVelocity). That should limit the ball velocity.
Or, as others suggested, set your collision material damping to 0 and use "rigid" for the world limits. That ought to work as well.
#8
Thanks for the help.
-Lenny
03/29/2005 (5:32 am)
I was using setMaxLinearVelocity() already, but considered it more to be a way to fight the symtomes of the problem. I'll try setting it to rigid :)Thanks for the help.
-Lenny
#9
03/29/2005 (6:02 am)
@Josh: Not strictly a curve, only an approximation, but that might be the issue. Every 0.1 seconds the rotation is adjusted and a new setImpulseForcePolar() applied. It doesn't happen all the time, but the times it would happen are at least nearly always during oblique curves and it does seem to happen particularly when it is moving fast. 
#10
If you're not interested in a rigid-body response for your projectile, it might be worth setting your relaxation to 0 to see if this helps. You currently do not have control over whether overlaps are solved instantly or over time. If you did, you could specify that they were and the very high velocity wouldn't cause this problem. Setting relaxation to 0 does this but is only really useful against immovable objects. Not the best situation but it should reduce the overlap case and may stop the problem. There's no guarantee that this will work as the effects are too subtle. Making your walls fairly thick should solve this issue but in ther future, you won't have to do this.
The multiple-collisions that Lennart was referring to was the world-limit causing multiple collisions. This was due to the fact that overlaps are solved over time and the collision with the world-limit took several iterations to be completely solved. This issue was fixed and will be in the next update. Your problem is slightly different wherein when checking for collisions with objects and an object is safeDeleted during a callback in the middle of the processing, subsequent collisions were not ignored. This is now the case and will be in the next update.
Lots of nice refinements need to be made to the physics with regards to physics and simply the way the system is integrated. Some of these would definately resolve your issue.
@Lennart: The "bounce" response gives you a perfect bounce that simply inverts the linear velocity along the collision normal e.g the perfect bounce, essentially like a restituion of 1 in rigid-body terms. Only the ribid-body response alters angular velocity though, things like "bounce" won't.
When the new file-format is in, you'll be able to choose the response for standard collisions such as "clamp", "sticky", "bounce" and "rigid", identically as you would the world-limits. This is practically ready to go now, we just need the new format so we don't keep breaking peoples saves. There's been alot of talk about whether people want to use the rigid-body response and it was never the intention for force the response on anyone, you can disable it now but having more typical responses has always been the intention, we just never quite managed to get it in the first release. These other "auto" responses will be very handy and widely used. After looking at the code, you'll also be easily able extend the set with your own custom responses as well without breaking future updates for yourself.
Look for "%obj.setCollisionResponse( bounce );" in future updates.
- Melv.
03/29/2005 (7:47 am)
@Tim: There is a limit to the sweep and it is possible to set extremely high velocities that fail the projection test but I don't think that's the case here. The magnitude of the sweep has to be bound otherwise precision errors creep in with large magnitude float values. I'm kinda wondering why you need velocities of 550 world-units/sec? Do you even see this on the screen at this velocity? Constantly adjusting the rotation can be bad because it can easily lead to overlaps which can be a nightmare to solve correctly in every situation with prior knowledge or other constraints. The overlap solver for T2D is very good but if you end up overlapped well inside the object, the solver may decide that the best exit strategy is the other side of the object making it look like it's passed straight through it. This is nothing to do with rigid-body physics, just an overlap solver. Again though, I'm not convinced that this is what you're seeing here.If you're not interested in a rigid-body response for your projectile, it might be worth setting your relaxation to 0 to see if this helps. You currently do not have control over whether overlaps are solved instantly or over time. If you did, you could specify that they were and the very high velocity wouldn't cause this problem. Setting relaxation to 0 does this but is only really useful against immovable objects. Not the best situation but it should reduce the overlap case and may stop the problem. There's no guarantee that this will work as the effects are too subtle. Making your walls fairly thick should solve this issue but in ther future, you won't have to do this.
The multiple-collisions that Lennart was referring to was the world-limit causing multiple collisions. This was due to the fact that overlaps are solved over time and the collision with the world-limit took several iterations to be completely solved. This issue was fixed and will be in the next update. Your problem is slightly different wherein when checking for collisions with objects and an object is safeDeleted during a callback in the middle of the processing, subsequent collisions were not ignored. This is now the case and will be in the next update.
Lots of nice refinements need to be made to the physics with regards to physics and simply the way the system is integrated. Some of these would definately resolve your issue.
@Lennart: The "bounce" response gives you a perfect bounce that simply inverts the linear velocity along the collision normal e.g the perfect bounce, essentially like a restituion of 1 in rigid-body terms. Only the ribid-body response alters angular velocity though, things like "bounce" won't.
When the new file-format is in, you'll be able to choose the response for standard collisions such as "clamp", "sticky", "bounce" and "rigid", identically as you would the world-limits. This is practically ready to go now, we just need the new format so we don't keep breaking peoples saves. There's been alot of talk about whether people want to use the rigid-body response and it was never the intention for force the response on anyone, you can disable it now but having more typical responses has always been the intention, we just never quite managed to get it in the first release. These other "auto" responses will be very handy and widely used. After looking at the code, you'll also be easily able extend the set with your own custom responses as well without breaking future updates for yourself.
Look for "%obj.setCollisionResponse( bounce );" in future updates.
- Melv.
#11
As for adjusting the rotation it seemed like the easiest way to do it. If I set an angular velocity I would have to monitor rotation constantly to adjust the velocity to keep the missile pointed correctly. Maybe I'm missing something (entirely possible) and I understand your point about the overlap solver.
But then you say
Good to know that the multiple collisions is a fixed T2D bug.
I appreciate all the support
03/29/2005 (10:27 am)
@Melv: Thanks for the reply. About the high velocity: at the top end, no, it'd be too fast across the screen to see. It doesn't start that fast, I just set a high cap because it should be what it is, more or less (the units here are feet per second: a TOW has an initial burn velocity of 250 fps with a peak of 1000+ fps). My intention for really fast weapons, such as bullets, is to resolve them via pick rays. I'm trying to make the missiles slow enough to be visible, but fast enough to fly.As for adjusting the rotation it seemed like the easiest way to do it. If I set an angular velocity I would have to monitor rotation constantly to adjust the velocity to keep the missile pointed correctly. Maybe I'm missing something (entirely possible) and I understand your point about the overlap solver.
But then you say
Quote:Again though, I'm not convinced that this is what you're seeing here.Well, then, what do you think I'm seeing? Its an artifact I would like to eliminate.
Good to know that the multiple collisions is a fixed T2D bug.
I appreciate all the support
#12
In the meantime, you may be interested in using "fxSceneObject2D::castCollision()" which sweeps the objects polygon through forward-time and passes you back all sorts of useful info. This is much better than using "pickRay" (now renamed to "pickLine") although it only returns the first object it hits.
- Melv.
03/29/2005 (11:22 am)
Very difficult to say without debugging it directly I'm afraid. The best thing I can suggest for the moment is to wait for at least the next update and then maybe we can take it from there. It could be a bug under specific circumstances or it could be something that you're doing and can be easily solved.In the meantime, you may be interested in using "fxSceneObject2D::castCollision()" which sweeps the objects polygon through forward-time and passes you back all sorts of useful info. This is much better than using "pickRay" (now renamed to "pickLine") although it only returns the first object it hits.
- Melv.
#13
03/29/2005 (11:35 am)
@Melv: thanks for the pointers! I mentioned pick ray only to clarify that I'm not planning on using objects for things that will move too fast to be seen. castCollision() only giving the first object shouldn't be an issue for helping with the missiles.
#14
Technically, the question isn't one of the absolute precision, but the relative precision between the two float values in question. If one is larger than the others by about 7 orders of magnitude, then you start getting imprecision problems.
Granted, that's a lot easier to say when we're talking about a couple of bare numbers rather than having a physics system with any number of values in various combinations that could cause said problems. Perhaps the user could set up some kind of mapping or something that would let the system know what "small" velocities are. Knowing that velocity only needs to be kept to the nearest 10 units per second could allow a user to use a pretty small unit value.
Consider changing your units, then. Can't one world unit be 10 feet or 100 feet instead of 1? It moves velocities back into something that the collision system finds much more reasonable. Remember, the internal velocity doesn't have to be what you display to the user; you can secretly multiply by 10 or 100 before showing the velocity.
03/30/2005 (1:28 am)
Quote:The magnitude of the sweep has to be bound otherwise precision errors creep in with large magnitude float values.
Technically, the question isn't one of the absolute precision, but the relative precision between the two float values in question. If one is larger than the others by about 7 orders of magnitude, then you start getting imprecision problems.
Granted, that's a lot easier to say when we're talking about a couple of bare numbers rather than having a physics system with any number of values in various combinations that could cause said problems. Perhaps the user could set up some kind of mapping or something that would let the system know what "small" velocities are. Knowing that velocity only needs to be kept to the nearest 10 units per second could allow a user to use a pretty small unit value.
Quote:the units here are feet per second: a TOW has an initial burn velocity of 250 fps with a peak of 1000+ fps
Consider changing your units, then. Can't one world unit be 10 feet or 100 feet instead of 1? It moves velocities back into something that the collision system finds much more reasonable. Remember, the internal velocity doesn't have to be what you display to the user; you can secretly multiply by 10 or 100 before showing the velocity.
#15
I totally agree with you in relation to understanding what "small" velocities are or just providing a sense of balance or constraints. The physics system and the whole way its configured is (to put it politely) a little raw and obviously undocumented so it's not so hot at the moment. This is something that is an important next step. Providing a much nicer way to configure the system, on all scales as well as providing other response models; some very simplistic, some complex (like the rigid-body) and of course, good documentation.
I'll be the first to admit that getting a system like this working correct in all cases with no real constraints on how they are used is a hard task but I think we've made a good start and intend to make it more stable and easier to configure and definately don't want to force people to work in any specific way.
I think that for most cases, you'll find it quite stable but as you push the limits, you'll encounter problems. This will be resolved, especially as we spend more time on things such as the integration methods and precision control.
The suggestion to reduce the units is probably the best short-term solution though, assuming it actually is a precision problem at all.
- Melv.
03/30/2005 (4:48 am)
Quote:Technically, the question isn't one of the absolute precision, but the relative precision between the two float values in question. If one is larger than the others by about 7 orders of magnitude, then you start getting imprecision problems.I think there's only so much detail that we need to go into for posts like this, hence my general statement. The non-linear precision problems of floats can cause real problems, as you say, especially if you're referring to several components that are orders of magnitude apart. I've been looking at resolving all sorts of issues related to this problem, particularly related to determining resting contacts but the sweeping can be fooled as well.
I totally agree with you in relation to understanding what "small" velocities are or just providing a sense of balance or constraints. The physics system and the whole way its configured is (to put it politely) a little raw and obviously undocumented so it's not so hot at the moment. This is something that is an important next step. Providing a much nicer way to configure the system, on all scales as well as providing other response models; some very simplistic, some complex (like the rigid-body) and of course, good documentation.
I'll be the first to admit that getting a system like this working correct in all cases with no real constraints on how they are used is a hard task but I think we've made a good start and intend to make it more stable and easier to configure and definately don't want to force people to work in any specific way.
I think that for most cases, you'll find it quite stable but as you push the limits, you'll encounter problems. This will be resolved, especially as we spend more time on things such as the integration methods and precision control.
The suggestion to reduce the units is probably the best short-term solution though, assuming it actually is a precision problem at all.
- Melv.
Torque Owner Jeremy Tilton
%pickList=t2dSceneGraph.pickRay(%startPos,%endPos); %objCount = getWordCount( %pickList ); if ( %objCount > 0 ) { for ( %n = 0; %n < %objCount; %n++ ) { %obj = getWord( %pickList, %n ); //you now have access to the objects you collide with } }