Jump to content
  • Advertisement
Sign in to follow this  
johnnyk

Squashing the Jitters: jenga tower, etc

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I've been working from the ubiquitous "Nonconvex Rigid Bodies with Stacking" paper (but 2d instead of 3d), and have most of it implemented but not perfected. I still got jitters! Free Image Hosting at www.ImageShack.us In the simplest of cases, a block on an immovable ground, the following happens: Each frame, it resolves collisions/contacts/shocks whatever at each point, first the bottom the left then the bottom right, but since I'm applying the impulse of each before moving on to the next, the result is that it moves a teeny-tiny bit to the right, since i process the right vertex last - the impulse it creates there does not cancel out the impulse generated at the left one, and there is a slight movement. If the right impulse completely cancelled out the left impulse, it would be still, but it doesnt! I'm not sure why not. Precision limitations? Problems in my algorithm? Anybody know? So theres a couple things I'm thinking of experimenting with there, I can condense those two impulses into a single one at the midpoint of the two, so theres only one impulse needed which will keep it upright. I've tried this and it does work, but then it opens doors to new problems. Behold, the ever popular jenga-tower, tumbling over here: Free Image Hosting at www.ImageShack.us Its a little more confusing figuring out what is going on here. I believe its just a case of the above jitter multiplied by the height of the tower, adding up to enough to topple the damn thing. So if I took the approach of condensing collisions to only one per-edge, that might help here.. but would it be physically accurate? then you would have weird cases like three small-blocks producing only a single impulse on the block stacked on top of it (does that make sense?) Or maybe the jitter is just something I have to live with, and do my best to cancel it and stop it, "sleeping" algorithms that detect when an object is jittering and cease its motion. That seems likely to generate lots of false positives, though, especially in cases like this: Free Image Hosting at www.ImageShack.us In this case you almost WANT some jitter, cause now the damn thing wont fall over! Its the shock algorithm, it seems: each block individually can stand on its lower one, and when you shock it and set the base blocks to infinite mass as you go up, they dont have any reason to topple over. I guess cranking up the iterations will help here, but theyre already pretty high.... I'm hoping a few people here can lend some advice here, as these are I'm sure pretty common problems, and I'm using a pretty common algorithm so someone must have some ideas of how to fix them, or at least what exactly the problem is! -John Krajewski

Share this post


Link to post
Share on other sites
Advertisement
I haven't programmed a physical simulation yet, but shouldn't you be using two separate buffers for objects? One for their current state and another for their state in the next frame (=after applying impulses to the objects from the current frame); you would then just swap the two buffers after each world update..

Share this post


Link to post
Share on other sites
your last pic show exactly the problem with shock propigation

in practice it isn't likely enough to be a problem

Share this post


Link to post
Share on other sites
Jittering in most physics simulations doesn't ALWAYS come out of the blue...
I agree with Devilogic, however, because of the fact that your objects seem to move in a specific direction. You are probably using data in the simulation that you calculated in the very same frame. That's wrong! I'll try to examplify... Imagine that you're simulating two planets in orbit. At any given frame, you don't just calculate the new position of planet A given the position of planet B, and then use the new planet A data to derive those of planet B. That's wrong. You should only use snapshots of the objects exactly as you left them in the previous frame.

However, some jittering is often seen in such applications. Even though a box should be resting on a flat surface, the physics/collision algorithms keep on igniting collision responses between them -over and over- and this produces this annyoing jittering you're getting.

The best way to deal with this, is define 'kinetic energy' traps [kinetic energy is: (mass*velocity^2)/2 ] for your objects and flag them -somehow- as 'temporarily inactive' when their kinetic energy drops below a certain minimum. Only use this if you have unyielding objects in your scene (like the floor in your app). This prevents the algorithm from flagging the very same collision in consecutive frame, when an object should rather rest, but use it with extreme caution (for the obvious reason)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!