As a side note to this project,
@MrRowl
You mentioned in your website that you were having problems with collisions with more than one contact point such as an edge–edge collision.
Well surprise surprise im having the same problems as you, if I just use a single contact point in the middle of the edge the body can wiggle its way though another body, this is reduced somewhat if I use stabilising points on the corners, but with a low physics dt it still works its way through.
You mentioned the possibility of using a LCP solver just for this type of collision to get the collision impulse, did you have any luck with that? Or think of any other ways to help with this.
[Edited by - Structure on March 2, 2005 12:15:03 PM]
(Nonconvex rigid bodies with stacking) paper in 2d
Quote:Original post by Structure
You mentioned in your website that you were having problems with collisions with more than one contact point such as an edge–edge collision.
Not quite - the issue I described was more that when an object (e.g. a box) rests on another (e.g. a plane) processing the resting-impulses sequentially isn't perfect... and in some situations is really bad. But it really shouldn't result in objects going through each other - that sounds like a very different problem...
Author
I thought id show an example of everything going on in this thread,
http://www.whenplanetscollide.com/tmpuploads/wpc.exe
In the exe the frame rate is artificially fixed to 25 fps to highlight the problems, Separation code is also disabled,
You can see the items coming to rest before they hit the ground, and the edge collision not preventing the box from falling through the floor, this only happens when it has some rotational velocity to cause the oscillation through the floor.
http://www.whenplanetscollide.com/tmpuploads/wpc.exe
In the exe the frame rate is artificially fixed to 25 fps to highlight the problems, Separation code is also disabled,
You can see the items coming to rest before they hit the ground, and the edge collision not preventing the box from falling through the floor, this only happens when it has some rotational velocity to cause the oscillation through the floor.
Author
Quote:Original post by MrRowl
Not quite - the issue I described was more that when an object (e.g. a box) rests on another (e.g. a plane) processing the resting-impulses sequentially isn't perfect... and in some situations is really bad. But it really shouldn't result in objects going through each other - that sounds like a very different problem...
Sorry that was the situation that I was talking about, im having trouble working out whats going wrong here, you can see the inelastic resting contact is correct as it holds the vertex collision correctly, but the other one has a collision in the mid point then a collision to the left corner then right, this dosnt stop the box at a low frame rate, it does when the fps are over say 50.
I don't think there is a problem with your implementation. The hexagon and the rectangle when it's on its end don't sink through the floor - this is because the contact point is nearly directly below the center of gravity so the contact impulse tends to push the object up rather than just rotating it. When the rectangle is on its side the ratio of the angular impulse to the linear impulse is much bigger, so an impulse that is big enough to stoop the contact point going through the floor is not nearly enough to stop the center of mass continuing to move downward. So your options are:
1. Increase the number of iterations per timestep (just had a thought - you are iterating over contacts more than once per timestep aren't you?!)
2. decrease the physics timestep
3. handle simultaneous contacts all together in some way.
4. Turn on your penetration-handling code
5. think of some other cunning solution!
1. Increase the number of iterations per timestep (just had a thought - you are iterating over contacts more than once per timestep aren't you?!)
2. decrease the physics timestep
3. handle simultaneous contacts all together in some way.
4. Turn on your penetration-handling code
5. think of some other cunning solution!
Author
Quote:Original post by MrRowl
1. Increase the number of iterations per timestep (just had a thought - you are iterating over contacts more than once per timestep aren't you?!)
2. decrease the physics timestep
3. handle simultaneous contacts all together in some way.
4. Turn on your penetration-handling code
5. think of some other cunning solution!
1) yep i use 8 iterations at the mo
2) yes this does alleviate a lot of issues , but as I may of mentioned before the engine is written in fixed point math to target handheld platforms, here the fps as generally going to be low so im testing using this lower frame rate
3) this is what I was interested in but ive never implemented an LCP solver before so don’t really know what im doing :)
4) this could be the best solution if the problem is not something I can easly fix. But then we come back to the jiggle thing again… wooo! Though if I can get the sweep thing working correctly this may not be an issue, im thinking that there’s going to be problems with multiple collisions and where to move the sweep to in the end, but ill fiddle with that when I get to it,,, this is fun!
5) any cunning plans out there ;)
Author
I think ive discovered the cause of the problem, but not the solution,
With the low frequency the body is not actually having any edge-edge collisions, after what you said I was thinking if it has a collision point in the centre of the two edges why wouldnt this support the body,
It turns out that its oscillating back and forward from corner to corner collision stepping over the edge contact position, this dosnt happen with a higher frequency as there is a smaller step and the body is supported by the mid point in the edge collision.
Mmm how to stop this….
(this is turning into a bit of a blog, sorry (well could be usfull to someone out there in a far of land))
With the low frequency the body is not actually having any edge-edge collisions, after what you said I was thinking if it has a collision point in the centre of the two edges why wouldnt this support the body,
It turns out that its oscillating back and forward from corner to corner collision stepping over the edge contact position, this dosnt happen with a higher frequency as there is a smaller step and the body is supported by the mid point in the edge collision.
Mmm how to stop this….
(this is turning into a bit of a blog, sorry (well could be usfull to someone out there in a far of land))
How about (sure I've suggested this before to someone else), rather than coding up a fixed point LCP solver (which I guess is pretty nasty!) code up a linear solver (for each pair of bodies, not for the system as a whole), but if it gives you negative normal impulse (my guess is this is rare...) then throw the result away and handle that pair of bodies as you do now. Might be a good trade-off between ease of implementation, speed, accuracy etc...
Author
I think im having physics engine block , so I could so with some more help here, first a quick update,
Ive come to the conclusion that trying to get things to stack at low frequencies is near on impossible (unless someone wants to suggest otherwise) so ive fixed the physics feq to 60.
But even at this stepping objects with low mass can step over the edge edge collision point and start to oscillate.
To get people up to speed the implementation im making uses inelastic impulse collisions to handle resting contacts.
In the diagram you can see that the box collides at point A and has a vertex edge collision, this then begins to rotate and the next collision is at point B, the same thing happens and the box wiggles its way down through the ground plane.
Really after point A the next collision should be an edge edge collision with the ground plane but because rotation is not handled in the sweep it steps over it.
Any suggestions on how to get around this?
Ive come to the conclusion that trying to get things to stack at low frequencies is near on impossible (unless someone wants to suggest otherwise) so ive fixed the physics feq to 60.
But even at this stepping objects with low mass can step over the edge edge collision point and start to oscillate.
To get people up to speed the implementation im making uses inelastic impulse collisions to handle resting contacts.
In the diagram you can see that the box collides at point A and has a vertex edge collision, this then begins to rotate and the next collision is at point B, the same thing happens and the box wiggles its way down through the ground plane.
Really after point A the next collision should be an edge edge collision with the ground plane but because rotation is not handled in the sweep it steps over it.
Any suggestions on how to get around this?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement