# backing up from collision point

This topic is 5203 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, I'm working on a collision system that uses the tried and tested 'backing up from collision point' to position the colliding object. However i've never been very happy about using the normal method of newpos = oldpos + velocity*intersectTime - direction*SomeSmallValue (direction being velocity.normalised) On the face of it, this should back up the object from the collision point to a safe distance, but of course in reality it may not if the direction is shallow almost parallel to the the plane being hit. In fact it rarely keeps the object a safe distance from the plane at all. It is also completely unrelated to any properties like distance or speed. So I thought about using the information from the collision to ensure the object stays a specified distance away from the plane. What i came up with (and its nothing new) is tRepulse = SomeSmallValue/direction.dot(intersectNormal) newpos = oldpos + velocity*intersectTime + direction * tRepulse Does that look correct? I believe it should be backing up the movement direction by an amount to ensure that the closest distance from object to plane is 'somesmallValue' - basic trig using the dotproduct for the angle. It certainly seams to work from aquick test, but if there is one thing i've learnt from doing collision detection and responce, its never to assume its working ;) Oh and for completeness I test that velocity*intersecttime magnitude is greater than the direction*tRepulse magnitude before executing the code. If its not then the object is deemed not to have moved. Any thoughts?

##### Share on other sites
Quote:
 tRepulse = SomeSmallValue/direction.dot(intersectNormal)newpos = oldpos + velocity*intersectTime + direction * tRepulse

This should do the trick. But depending on what you are doing right now (polygon soup/sphere? physics? processing collisions in chronogical order?) that usually does not matter unless you are dealing with point size objects wich could potentially start from the wrong side of a primitive on the next frame due to precision issues if you did not offset them.

##### Share on other sites
Right now I'm using the bisection method to find the collision point. I've read about using the penetration depth instead to find the collision point which works faster. I still have to research how to do that.

here's a demo of the system in action.
colliding disks

##### Share on other sites
Thanks,

o.k so it doesn't look like there is really any problem with this, and it does appear to work far better than simply backing up the direction by a fixed value.

Although I did realise after posting that the line could potentially crash if there was a divide by 0. However for that to be true the direction and plane normal would have to be parallel. Still with precision issues maybe it will be wise to check?

I've actually got so fed up with producing a 100% robust triangle collision system, this time i've gone for a AABB world, everything is AABB's. Although simplistic in terms of geometry, I think its provided a good base to get a robust system going. For a change its also allowed me to develop a full static and dynamic system, with moving platforms and pushable boxes.

Hopefully with what i've learnt I can move back to a full primative vs traingle system and get that much more solid. I'll have to look into penetration depth solutions and also a three state collision method (no collision, collision & touching/embed) and adjust the result based on that.

Thanks

##### Share on other sites
Quote:
 On the face of it, this should back up the object from the collision point to a safe distance, but of course in reality it may not if the direction is shallow almost parallel to the the plane being hit. In fact it rarely keeps the object a safe distance from the plane at all. It is also completely unrelated to any properties like distance or speed.

what works for me is extrapolating the movement to at least x units (if the magnitude of the velocity for the move is less than x units), and then backing off the collision point by w units. This works perfectly all of the time for brush collision detection.

Also, instead of using the repulse quantity, you can just try adding the normal of the plane hit times some 'smalldelta' value, so that the collision position is guaranteed to be pushed a little bit away from the normal.

edit: this assumes the normal is already a unit vector.

##### Share on other sites

>
what works for me is extrapolating the movement to at least x units (if the magnitude of the velocity for the move is less than x units), and then backing off the collision point by w units. This works perfectly all of the time for brush collision detection.
>

I'm not sure I follow on extrapolating the velocity, as surely this changes the dynamics of the collision and repsonce as you are putting more speed into the system?

As to backing up by w units, this unfortunately doesn't always work, at least in my experience. Thats why I came up with the repulse method. Simply backing up a set amount doesn't take into account the angle between the move direction and the plane. So in case where the direction is almost parallel to the plane, you might not move out of contact.

The repulse method is meant to back you up along the original direction to ensure a specific distance from the plane. If there is not enough room to back up (i.e. backing up beyond the orignal position) then the object is not moved to the collision point, but can still do the slide repsonce so as not to stop dead.

>
Also, instead of using the repulse quantity, you can just try adding the normal of the plane hit times some 'smalldelta' value, so that the collision position is guaranteed to be pushed a little bit away from the normal.
>

I thought this was considered a poor approach though, as offsetting using the normal of the collision plane can push you into other geoemtry. Unlike backing up along the direction of the object that moved which is always safe.

##### Share on other sites
Quote:
 I'm not sure I follow on extrapolating the velocity, as surely this changes the dynamics of the collision and repsonce as you are putting more speed into the system?

Sorry, what I meant here was that when doing the *collision detection* you extrapolate the velocity, but you don't actually change the amount you can displace based on your velocity;

Quote:
 As to backing up by w units, this unfortunately doesn't always work, at least in my experience. Thats why I came up with the repulse method. Simply backing up a set amount doesn't take into account the angle between the move direction and the plane. So in case where the direction is almost parallel to the plane, you might not move out of contact.

I see what you are saying, and while rational thinking seems to be correct, my personal experience has been kind to me with this method...when I extrapolate the velocity when doing collision detection, I cannot ever go through geometry. And keep in mind this is with the brush algorithm, such that I'm doing a lot of fraction computing with 32bit floats to determine where rays intersect lots and lots of planes.

If you extrapolate the move enough, then when you are going parallel to a plane the collision detection routine will detect that the *extrapolated* move went through the geometry.

Quote:
 I thought this was considered a poor approach though, as offsetting using the normal of the collision plane can push you into other geoemtry. Unlike backing up along the direction of the object that moved which is always safe.

True there. Like I said, it's pretty hackish, more so than the other ideas.

##### Share on other sites
Quote:
 Original post by noisecrimeI thought this was considered a poor approach though, as offsetting using the normal of the collision plane can push you into other geoemtry. Unlike backing up along the direction of the object that moved which is always safe.

Again, it depends on what you are doing. If you are writing elipsoid vs. triangle for a game (FPS for example). Correcting new_pos along the normal is a very easy and cheap way to get correct looking sliding. For sure you need an iterative collision detection/solver to deal with tunneling effect.

##### Share on other sites
hi

b34r:

I think there is some confusion going on. When i talk about moving out along the planes normal, that has nothing to do with sliding (that would be vector along the plane).

Even if you have an iterative collision detection/solver that wont help becuase you are meant to be returning a 'safe' position. Moving out in the direction of the plane normal, is not gauranteed to be safe (imagine the classic V shape issue). The iterative solution only ensures that it takes care of the new velocity (slide) from the new position if it hits another plane.

I see what you're saying with extrapolating, but I don't think it actually helps. Well, it does, but only at the expense of more collisions, becuase you're not ensuring the position is not in contact with a plane. But if it works for you then great, just wish it did for me.

However my experince with 3D collision systems is that they are rarely robust. Change the world scale, framerate or velocity used and they are likely to need tweaking to avoid embeds or falling through geometry. For example I've read numerous mails about the ellipsoid collsiion system, where it fails, and each developer has come up with there own methods to workaround it or fix I (myself included). Thats not to say a collision system can't be robust, there are plenty around to prove that. But in general I don't think any of the turorials really go into the depth necessary to ensure this.

Anyway thanks for the ideas.

##### Share on other sites
Quote:
 Original post by noisecrimeI think there is some confusion going on. When i talk about moving out along the planes normal, that has nothing to do with sliding (that would be vector along the plane).

Sorry (;

Quote:
 Even if you have an iterative collision detection/solver that wont help becuase you are meant to be returning a 'safe' position. Moving out in the direction of the plane normal, is not gauranteed to be safe (imagine the classic V shape issue). The iterative solution only ensures that it takes care of the new velocity (slide) from the new position if it hits another plane.

Yes, and that's why it will solve it... the solver will converge to a 'safe' solution. It just needs a certain number of iterations depending on how bad your V shape is and the initial penetration.

1. 1
2. 2
Rutin
16
3. 3
4. 4
5. 5

• 26
• 11
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633704
• Total Posts
3013460
×