Sign in to follow this  
_Flecko

Bouncing rigid bodies

Recommended Posts

I'm trying to model rigid bodies in my 2D game using verlet integration and stick constraints. I'm playing around with boxes, which I make out of four particles and six constraints. When I was first setting this up, I figured that when a particle struck the ground, I would project it out of the terrain, reflect its velocity across the normal and multiply it by some constant no greater than 1. For a lone particle, this works very nicely. However, my boxes were bouncing way too far, and I realized that there is another force at work: That's what happens when a body is being relaxed after a collision (it's repeated a few times). The gray circles represent where the particles used to be, which is important because for verlet integration velocity is implicit, so it uses the vectors from the old positions to the new ones to decide how far to move the next frame. Notice that after the relaxation, both particles are now moving to the left. Now, there's a couple of problems with this. One, it bounces in the wrong direction - it negates its velocity, rather than reflecting it across the normal like it ought to. Two, I sort of lose control over velocity - everything is way too bouncy here, and though I can set a particle's velocity to 0 (or to a reflection across the normal) when it's in a collision, I can't really do the same with the particle that gets pushed left by the stick constraint. It seems like this is generally good, natural behavior, but I need more control over it. Any suggestions?

Share this post


Link to post
Share on other sites
I did similar stuff a while ago and it used to work really fine. Are you taking into account the velocity modification induced by the vertice projection?
I cannot see why from the graph you show C would bounce in the wrong direction. Step 4. would detect P2 as colliding and proceed on solving penetration, etc...

Share this post


Link to post
Share on other sites
The reason it bounces in the wrong direction: the particles are projected out of the terrain in the direction they entered in order to approximate where they hit it. When a particle hits a surface, its velocity should be reflected across the surface's normal vector, which is why I was prescribing velocity before. However, the diagram shows that regardless how I set P2's velocity, P1's velocity will be some vector opposite its velocity before the collision. Now, this seems perfectly fine to me, -except- that P1's velocity is overpowering P2's, and the result is that the object basically just bounces straight backwards in the direction it came from much faster than I would like it to. The direction actually isn't a huge deal, it's just that things fly a lot further than they should after crashing into the ground.

If you have an engine that does something like this properly, though, is there any way I could get a look at the source code?

Share this post


Link to post
Share on other sites
Quote:
Original post by _Flecko
The reason it bounces in the wrong direction: the particles are projected out of the terrain in the direction they entered in order to approximate where they hit it. When a particle hits a surface, its velocity should be reflected across the surface's normal vector, which is why I was prescribing velocity before. However, the diagram shows that regardless how I set P2's velocity, P1's velocity will be some vector opposite its velocity before the collision. Now, this seems perfectly fine to me, -except- that P1's velocity is overpowering P2's, and the result is that the object basically just bounces straight backwards in the direction it came from much faster than I would like it to. The direction actually isn't a huge deal, it's just that things fly a lot further than they should after crashing into the ground.

If you have an engine that does something like this properly, though, is there any way I could get a look at the source code?


Since Verlet velocity is implicit did you try not modifying it yourself? Simply projecting offending vertice give very good results (theorical behavior and stuff like energy conservation set aside). For the source code I need to dig my archive really deep because that was around 4 years ago so I'll give it a try but cannot promise anything :). I should still have that somewhere hopefully.

Share this post


Link to post
Share on other sites
Yes, as I mentioned in the original post, my original method was to set the offending particle's velocity after projecting it, and as I said in the last post, the problem is that the velocity of other particles after a collision (so in the diagram that would be P1) overpower it. Sorry if I was unclear about that.

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