Sign in to follow this  
Structure

(Nonconvex rigid bodies with stacking) paper in 2d

Recommended Posts

Structure    240
Hi, I have a question about the paper "Nonconvex rigid bodies with stacking" : http://graphics.stanford.edu/papers/rigid_bodies-sig03/ As it predicts where the objects will be in the next step for collisions then resolves the collision where the object are at the moment, wouldn’t this cause an object that has an inelastic collision with the ground plane to stop just above the plane? [Edited by - Structure on March 2, 2005 1:52:53 PM]

Share this post


Link to post
Share on other sites
Structure    240
Ok, just checking I got the implementation correct,

As im making 2d system, its quite noticeable and therefore unacceptable at the moment,

To alleviate this ive been detecting collisions where the body is at the moment , this of course leads to lots of interpenetrations.

Any suggestions?

Share this post


Link to post
Share on other sites
Airo    197
you apply impulses to prevent future penetrations.

this is what i got so far: http://home.planet.nl/~woute890/domino.zip

press s to start and r to reset.

Share this post


Link to post
Share on other sites
MrRowl    2490
Quote:
Original post by Structure
As im making 2d system, its quite noticeable and therefore unacceptable at the moment,
...
Any suggestions?


In 3D you don't normally see collisions side-on, so you don't see this. I came to a similar conclusion with my water experiment where you could see the compressibility of the fluid in 2D, but I bet it's more hidden in 3D.

A suggestion... well how about in the part of the method that has you put the objects back to their starting positions after collision detection, for any object that only collides with a static object, just move it back by the penetrationDepth along its movement vector instead of restoring its original state. If you're using swept tests for collision you might even be able to do this for pairs of moving objects as well.

Share this post


Link to post
Share on other sites
Structure    240
Mmm, yes that’s an interesting idea I’ll implement that tomorrow and see how it looks.

I did implement a swept test based on olliii’s work he posed a while back, but became dissatisfied with the fact that rotation is not included in the sweep, I looked at Stephane Redon’s work but decided it was a bit to much over head as im targeting the engine for pda use, then I kinda got lost in something else and haven’t thought about it.

Well thanks all, ill get back to you how it looks.

Share this post


Link to post
Share on other sites
Structure    240
Hi,

Ive been thinking about this paper some more,

I had to implement a separation impulse dependent on the collision depth to prevent objects from sinking in to each other, but doesn’t doing this defeat the object of the paper.

Lets say we have an object sitting still on a surface, the object's new position is predicted and collision detection run, because of gravity this will detect a collision with the floor, this is resolved with the objects old velocity (0) so nothing happens, then gravity acts on the new velocity and contacts are resolved this should give an inelastic bounce to 0 the velocity again, but the separation impulse will give a small upward velocity and the object will jiggle around…. I think… or am I missing something here,

Really we need a system that can distinguish between predicted overlaps and real ones and only apply separation on the real overlap, but I cant see a way of doing this without performing collision detection twice, something I don’t want to do.

Ideas?

[Edited by - Structure on February 18, 2005 5:58:16 PM]

Share this post


Link to post
Share on other sites
Structure    240
Actually , if anyone’s reading this thread in the future , I think ive come up with a solution,

Basically Oliii’s work allows you to detect collisions forward in time and overlaps, so instead of moving the object to the predicted position, im going to try doing a swept test with the new velocity from the old pos.

This way the separation impulse need only be applied if the objects actually overlap, otherwise we can move the object to the point of collision, then resolve with the old velocity as before.

Well ill se if this works over the next week.


MrRawl: if you do get to read this could you explain how your friction approximation works in your jiggle code, im having trouble implementing a solution for this.

Share this post


Link to post
Share on other sites
MrRowl    2490
Brief description is on
http://www.rowlhouse.co.uk/jiglib

"Friction - At each collision point the normal impulse has been calculated. Applying friction at each point is treated like a collision - calculate the impulse required to prevent the two points on the two objects diverging. Now compare this tangential friction impulse to staticFriction*normalImpulse. If it's greater, then friction won't be able to stop the objects, so apply dynamicFriction*normalImpulse in the tangential direction. If it's less then apply the originally calculated tangential friction."

Does this make sense (especially after looking at the code in jiggle)? If not I can try to explain it better...

Share this post


Link to post
Share on other sites
Structure    240
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]

Share this post


Link to post
Share on other sites
MrRowl    2490
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...

Share this post


Link to post
Share on other sites
Structure    240
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.

Share this post


Link to post
Share on other sites
Structure    240
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.

Share this post


Link to post
Share on other sites
MrRowl    2490
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!

Share this post


Link to post
Share on other sites
Structure    240
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 ;)

Share this post


Link to post
Share on other sites
Structure    240
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))

Share this post


Link to post
Share on other sites
MrRowl    2490
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...

Share this post


Link to post
Share on other sites
Structure    240
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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this