Small object jitter: approaches summary?

[ejtttje]

If I use centimeter units to keep scale of objects in my simulation "around 1", then gravity should be 980. If I use meters as my unit, then my object is 0.05 units on a side, gravity is 9.8, and I still get the jitter. It just seems hard to simulate a small object with accurate gravity.

This is similar to this post, which didn't get any responses, and seems to be a common/ongoing problem.

I'd like to collect any current tips and update the Scaling The World wiki page.
If people contribute suggestions I'll write it up on the wiki.

There's a few parameters I've seen mentioned, but I'm not sure where they are:

• "linear [Sleep Threshold]" from the wiki page
• gContactBreakingThreshold?

Things that don't seem to work:

• dynamicsWorld->getSolverInfo().m_restitution=0 nor CollisionObject::setRestitution(0) affects this jitter.
• solver info's m_linearSlop causes the cube to sink into the plane, but doesn't straighten out the rotation very much

Things that do work to reduce jitter:

• Running simulation updates at high frequency (e.g. 500Hz+)
• Setting dynamicsWorld->getSolverInfo().m_splitImpulse=true (allows 200Hz without jitter... reference info here and here)
• Reducing gravity (which obviously affects simulation outcome)

Note that simply enabling split impulse reduces the jitter rotation, but does not affect the sliding distance... at 200Hz the box will slide significantly further than if running at 500Hz, regardless of split impulse.

Any other suggestions? My dynamicsWorld->getSolverInfo().m_erp is 0.35. m_numIterations is 250, although I doubt that is coming into play with a single object.

[Erwin Coumans]

We only support using meters as units. Using very small objects, such as 0.05 meter, is indeed not properly supported at the moment. This limitation should be clear when using Bullet.

Can you re-create the issue in one of the Bullet demos? Then I can try to provide some help. A smaller internal substep is likely needed, world->stepSimulation(deltaTime, 10, 1./240.);

Thanks,
Erwin

[ejtttje]

Hmm "only support meters as units" is actually news to me, I've seen a fair bit of discussion regarding scaling the world to get around numerical/stability issues though. The trick is it seems to be scattered and inconsistent, so I'd like to collate some of the items. It may not be "supported" but there does seem to be some community interest in the issue.

[Erwin Coumans]

As far as I understand, you want to be able to simulate small objects of around 5 centimeter.

Again, I suggest you keep the units as meters and provide a modified Bullet demo with the objects that matter to you (I would expect a moving dynamic object falling onto a static object, both with specific collision shapes). I can try to help improving the stability for the small object in such specific demo.

Thanks,
Erwin

[syl]

Thanks for the sumup ejtttje. Greatly appreciated here because i'm too trying to simulate at centimeters scale. Do you think missing collisions with small objects can be the same issue than jittering ? How could we run the simulation at higher frequency ?

[ejtttje]

Further tests reveal this is actually a collection of issues:

• Object spinning
• Object drifting
• Object jitter (e.g. twitching, jumping)
• Impaled objects
• Constraint sag
• Constraint twitch

And what you see depends on initial conditions:

• Spontaneous occurrence vs. only following a drop/impulse
• Eventually convergent/dampened vs. continuous
• Only occurs while object is in motion

So for example, my initial problem was a sliding cube showing rotating while in motion. Adding split impulse fixed the rotation without requiring (too) high frequency physics updates. But then I realized this causes issues with small falling objects remaining impaled in the ground and spinning in place. It's like playing whack-a-mole, and this is probably why I was seeing various and sometime conflicting advice... some approaches address certain aspects, but may cause other issues in ways that aren't immediately obvious.

So I may take Erwin up on making some test cases. Some of these issues show up even with 'supported' sizes like 0.5 with mass of 1, and some unit tests could be shoehorned to automate the parameter optimization process for a particular environment... we'll see :-/

[ejtttje]

Actually, here's a quick question: I see a lot of jitter when using a btStaticPlaneShape for the ground plane, but oddly switching to a large box is somehow stable. Is that a bug of the plane, or lack of a feature in the box handling?

[Erwin Coumans]

It could be a bug in the btStaticPlaneShape, but usually it is a combination of things that leads to jitter.

That's why I asked for a reproduction case, preferably modify the BasicDemo so we can have a look.
You can attach zip files in this forum.

Thanks,
Erwin

[ejtttje]

I've created a test program to look into these issues:
http://code.google.com/p/bullet/issues/detail?id=540

[Erwin Coumans]

I've created a test program to look into these issues:
http://code.google.com/p/bullet/issues/detail?id=540

Thanks, but as I repeatedly mentioned, you need to use a smaller substep when using very small objects. This line fixes your jitter:

Code: Select all

world->stepSimulation(deltaTime, 10, 1./240.);

thanks,
Erwin

[ejtttje]

Or in this case, using a box as the 'ground' also works... I need the CPU to do more than burn extra cycles to work around the physics engine

[Erwin Coumans]

Using box as a ground only improves the case when colliding boxes against the box ground, because there is a specialized collision algorithm that computes multiple contacts between btBoxShape and btBoxShape.

Bullet has many different collision shapes, and a collision algorithm is a combination between two shapes, so it is not 'just' improving the btStaticPlaneShape collision algorithm but improving btStaticPlaneShape against arbitrary other collision shapes. So optimizing plane versus box is just one out of many cases. So an important question is: Which collision shape types are you using in your app for dynamic moving objects? Just boxes? Obviously you are free to implement new collision algorithms and contribute them.

Note that Bullet has the option to sample multiple contact points for convex shapes against btStaticPlaneShape, using

Code: Select all

m_collisionConfiguration = new btDefaultCollisionConfiguration();
m_collisionConfiguration->setConvexConvexMultipointIterations();//might need to tune optional parameters

Note that for some shapes (sphere, capsule, cylinder) it introduces unwanted side effect (rolling due to wrongly positioned contact points), so some filter needs to be added to only apply this perturbation algorithm for specific shapes.

I need the CPU to do more than burn extra cycles to work around the physics engine

What is your target platform? It seems better to optimize the physics engine performance for your app, so you can run a smaller timestep while using the same CPU cycles.

Thanks,
Erwin

[ejtttje]

Fair enough that it's only a fix for this specific case, but that's better than having a problem in that case instead

I do use mostly boxes. Sometimes cylinders as well, and maybe general meshes someday, but we can model a lot with boxes and cylinders (and the occasional sphere for fun). And then of course the ground plane to hold them up. Or ground box as the case may be, but I'd prefer not to have to consider things falling off the side, and I would think a single plane could be faster than a box as well. Considering this is the primary support surface generating the majority of object interactions over time, that performance could have an impact, but I haven't explored that aspect.

One concern with running a shorter step time is that when something "interesting" happens in the simulation, all of a sudden those high frequency steps can get expensive and cause everything to stutter or fall behind.

Another point: the main issue with small objects (that I've seen so far) is really an issue with high gravity acceleration relative to the size of the object. There may still be other issues, but a gravitational issue is going to primarily show up with support surfaces, and btStaticPlaneShape is really mainly useful as a primary support surface. So in other words, fixing this may be a special case, but it directly addresses a root problem... other inter-object interactions are roughly gravity-neutral, and would otherwise be fine with the longer simulation step.

Our target platform is desktop PCs, across a range of performance levels (notably netbooks unfortunately). We run robots and simulations thereof, and some of the robots themselves are controlled by netbooks, and in classrooms they might not have additional PC resources, so they wind up developing and testing in simulation on the same netbook that later controls the robot... for these robots, 5 cm is quite large -- that's already an obstacle to be avoided. The interesting stuff it can pick up or manipulate is on the order of a couple cm, like chess pieces: http://chiara-robot.org/Challenge/

So it's pretty debilitating to write off everything under 5 cm as being "too small", because that's all of the interesting stuff. Bullet is really close to handling this, we just need to handle one more order of magnitude (~5 mm) to handle common interactions with desktop/office items.

[Erwin Coumans]

There is a mechanism that adds multiple contacts between plane and convex shapes, and latest trunk exposes a method to enable/control this:

Code: Select all

	m_collisionConfiguration = new btDefaultCollisionConfiguration();
	m_collisionConfiguration->setPlaneConvexMultipointIterations();

Use the latest svn trunk version together with the attached BasicDemo.cpp, the plane-box and plane-convex should have similar stability to box-box.

So it's pretty debilitating to write off everything under 5 cm as being "too small",

It is too small relative to the internal timestep, given a discrete physics simulation and default gravity. The motion of the object in a single simulation frame given those conditions is too large to reach a stable resting state, in particular when not enough contacts are generated. Even when enough contacts are generated, the simulation is not very reliable given those conditions.

Even increasing the internal substep to 120 hertz (1./120 instead of 1./60.) might already help you. Perhaps you can benchmark the performance on your slowest platform (netbook with a slow Atom?) and try optimizing it. You can use CProfileManager::dumpAll() right after 'world->stepSimulation' to get some statistics in the console.

Thanks,
Erwin

[ejtttje]

Thanks for providing that, it looks like it does the trick for quieting boxes.

I updated the BasicDemo sample to see how things are going for cylinders and a sphere, and the cylinders have issues with self-rolling.

Note this happens on both the ground-box and the ground-plane, regardless of the multipoint iterations call (fyi I added a useMultipoint flag to turn this off/on easily.) The Sphere seems fine in all cases, but perhaps it needs some perturbation to see any issues.

You had warned that setConvexConvexMultipointIterations() might have issues with self-rolling spheres/cylinders. Does this setPlaneConvexMultipointIterations() call share that, and/or does the registerCollisionCreateFunc() call in the sample you provided avoid this?

In any case, it doesn't seem to be any worse than the normal case, but is there a way to make them better? I use cylinders for wheels, which might not auto-roll due to having stuff attached, but I have seen some issues with vehicles slowly drifting sideways which might be related.