Physics object "jitter".

[steveh]

Hi,
Using the standard Bullet code, I drop a sphere prim of radius 0.025 (2.5cm) onto a static box prim using gravity of 10m/sec.
The balls has coeff of restitution of 0.8, the box 0.5.

After the ball has bounced a few times, it will continue to bounce erratically to various (small) heights for quite a few seconds. Is there anything we can do to make the ball act correctly? I've tried varying the physics update period from 50 to 1000 times a second, the jittering is still present. This "jitter" is present on sphere to mesh collision too.

I realise these are fairly small objects, but for a pool game this is just the kind of scales we're dealing with and the camera will be zoomed closely on the objects, even tied to the balls.

Many thanks,

Steve.

[Erwin Coumans]

Using smaller objects then .2 units will require additional work, hence the recommendation to avoid it.

However, to improve Bullet we should try to improve it.
There are some hard-coded values like gContactBreakingThreshold (0.02) that interfere. Previously I recommended not to upscale objects, but it is better then changing those hard-coded constants. I expect better results if you upscale by scaling the actual shape dimensions (radius for sphere, halfextents for box, triangle vertices for mesh), instead of using 'localScaling'.

I'm on a busy trip at the moment, so unfortunately I don't have time to re-create and investigate a testbed with trianglemesh and small sized spheres. Can you help and re-create a similar setup inside a Bullet demo?

Thanks!
Erwin

[sparkprime]

Awaking a thread from the dead!

I don't mind adding hooks into bullet to play with things like "gContactBreakingThreshold" assuming that they can be changed at runtime taking effect immediately. My game has a lua console which I've been using a lot to experiment and tweak things until they are right.

It seems to me that everyone would want to tweak the solver and simulation constants until the behaviour is realistic for their particular situation.

How many variables are there that could potentially be optimised?

[Punhey]

I'm having a similar problem, only it is not with small objects. It is with spheres of radius 32.0f. I'm doing a 2D application so the z of all objects is set to 0. I then drop balls from above and let them bounce around and stack up in an area bounded by 3 static planes - one on the left, one on the right, and one at the bottom. The balls fall and collect at the bottom just fine. The problem is when the "floor" gets filled with balls and then subsequent balls have to rest atop those balls. When a ball comes to rest on top of other balls, the balls on top begin to sort of "hop". They almost look like pebbles sitting in boiling water where pressure from bubbles below slowly builds up underneath them, slowly raising them up, and then once the bubbles reach a certain point, they escape between the pebbles and the pebble suddenly comes falling back down, only to repeat the process again.

I tried playing with the restitution of the balls but nothing seems to fix it.

Has anyone else encountered this problem? Thanks!

[sparkprime]

If you call getSolverInfo() on your dynamics world, you get a reference to one of these:

http://brockley.ath.cx/~spark/bullet/st ... oData.html

They are internal bullet parameters that you can change at runtime.

Things you could experiment with are:

turning m_splitImpulse on
changing m_splitImpulsePenetrationThreshold

increasing m_numIterations

Also stepping the simulation at a faster internal timestep (e.g. 100hz or 200hz). This will probably fix the problem but maybe at an unhelpful cost.

Are you able to verify that your spheres are not drifting in the z axis? Maybe using cylinders would be better.

[Punhey]

Thank you for the suggestions. I tried changing each of them to several different values but none of them had an effect on the phenomenon. I've also verified that there is no axis drifting by setting up a constraint to keep all my spheres on the XY plane.

It seems that there is a serious problem with spheres in Bullet that I have not noticed with the other primitives, and I've now found that this phenomenon can be observed with a minor modification to BasicDemo.cpp. Make the following two changes to BasicDemo.cpp and you will be able to observe the phenomenon:

1. Replace the cube shape with a sphere shape of radius 1.0f.

2. Change START_POS_Y to 0. For some reason, when the cube formation of spheres starts out in contact with the "ground", the phenomenon does not occur (at least not until after the spheres collapse into a heap). This causes the formation to appear just above the "ground".

Now, begin the simulation and zoom in and watch very closely. You will notice that shortly after initial contact with the "floor", some of the higher up spheres will bounce normally, but the second row of spheres from the bottom will usually begin to strangely levitate slightly, lifting up all the spheres above them, before the formation finally collapses. You may have to press the spacebar a few times to repeat the simulation until you notice what's going on. It also helps to see what I'm talking about if you reposition the camera to be very close and on eye level with the second row from the bottom. This should make the effect very noticable.

Often you may also notice this behavior after the collapse if you manage to get a situation where a sphere rests atop another two or three spheres. To reveal this, you will probably have to disable deactivation. If you look very closely, you'll see that spheres in this arrangement will often levitate above the other spheres quite noticably with no points of contact anywhere near the other spheres. They will slowly rise, and then suddenly fall back into place.

When deactivation is disabled, I've also sometimes noticed balls rolling slowly away from the site of the collapse, eventually come to a stop, and then as another rolling ball approaches them, but nowhere near making contact, the ball will suddenly begin rolling again, as if the ball approaching it was emitting a sort of repulsive force (almost magnetic in behavior) at a distance.

From what I can tell, it is only spheres that I've found exhibiting this behavior.

[sparkprime]

I modifed the demo as you said and I can confirm that the "first floor" spheres hover above the "ground floor" spheres, when the cube of spheres comes to rest on the floor.

The "magnetic" effect might be due to something else - when spheres deactivate, their velocity is not reset to 0, so when they get woken up again, they pick up their velocity from last time. This does not explain the "hover" effect though, which I assume is some kind of bug with contacts.

[Punhey]

Thanks, Sparkprime! I'm really new to the library and I don't know enough about it to say if it's a contact issue or not, but I know that in the application I'm working on, it looks as though the balls below are exerting an upward force on the balls above them at a distance since it causes the balls to hover ever higher until they get to a certain distance and then suddenly fall back to where they should be, only to begin hovering again. This is not as obvious in the BasicDemo since after the first "collapse" in the cycle I mentioned above, the entire structure falls apart and you don't get to see the effect cycle repeatedly. But in my application, for lack of a better description, I'm filling the screen full of gumballs in 2D, and as they pile up, it becomes a horrid mess of hopping balls and it is not even remotely realistic in appearance, unless it was supposed to be simulating a bunch of balls sitting in boiling water.

I haven't downloaded and checked older versions of the library to see if they have the same problem yet, but I have difficulty thinking that such a glaring problem would have made it through all this time undetected and uncorrected, so perhaps it was recently introduced? At any rate, it is severe for any application that involves spheres resting on one another for any amount of time.

Thanks again for independently confirming the issue.

[Punhey]

I don't know if this helps diagnosis, but I'm pretty sure I've now noticed that the problem becomes more and more pronounced as gravity is stronger.