# Why are blender simulations jittery on small scale?

It's been common wisdom that, when a rigid body, or cloth simulation gets jittery, it helps to just scale up the entire scene and the simulations start to behave more predictably. And while I have myself experienced that this is good advice, I don't quite understand why. Since the simulations are just calculations, they should behave exactly the same when everything is 10x smaller, with mass, speed, and so on adjusted accordingly. And yet the results differ wildly. Could someone explain why?

Jitter is often caused by floating point instability. If you're not familiar with floating point and the problems which cause this, I have attempted to write a high level overview which I hope might be helpful. However the standard disclaimers apply; I'm not an expert on physics simulation nor a bullet or blender developer nor an authority in any sense.

Bullet, the physics library blender uses for rigid body simulation, uses floating-point arithmetic. Floating point numbers have the impossible task of representing all real numbers in a fixed number of bits, and so not all numbers are actually representable; arithmetic in floating-point is almost always rounded to a number a little different from the exact correct answer.

This tends to translate to jitter in rigid body simulations when an object is in constant contact with another object. Imagine that the precise position the object should sit so that it exactly collides with a collider (i.e. is neither inside it nor outside) is not representable. When calculating the next position for the object, bullet inevitably calculates a position inside or outside the collider. Lets say its inside; then a collision occurs and the object gets pushed outside, and then gravity (or any number of other forces) pushes the object back again and an oscillation starts. If the velocity of the object starts increasing, the jitter can quickly magnify in a positive feedback loop.

This is of course a simplified version of events, there are countermeasures which bullet employs to avoid this sort of thing and I don't pretend to know half of them (but Split Impulse is one you have control over from blender) but there are also many other ways things can go wrong in any complex simulation with multiple simultaneous interactions.

As to why shrinking things tends to help, that is likely because the standard format for floats (IEEE 745) is clever and manages to offer a higher density of representable numbers near zero; the logic being that larger errors matter less with bigger numbers. As for why making things larger can help; that may have more to do with collision detection being better behaved with a reasonable number of simulation steps for the size and velocities of the objects involved. (even with all the physics properties scaled, properties such as substeps and behavior of things like split impulse may not scale in a perfectly analogous way.. but i'm at the end of my knowledge here)

It would be possible to not use floating point arithmetic, but writing the physics engine would likely be harder especially while achieving comparable performance. The author of the bullet physics library has commented on this possibility and suggests it would be a completely separate engine.

• Hey @gandalf3, thanks for the response, however, I find the part about floats not very convincing, here's why: the usual 32-bit floats have 8 exponent bits, which means they can go all the way down to around 10^-37. On the other hand, in a simulation, let say we have a 0.001 kg object with radius of 0.001 m, and the impulses are computed for 120 fps, with 100 sub-steps per frame. Even at this extreme, we get numbers around 10^-10, maybe 10^-13, still very far from the end of the range - so far that that even multiplying the entire deal by another 10^-10 shouldn't make any visible difference. Commented Feb 26, 2023 at 22:04
• To put this another way: multiplying all floats in a calculation by some constant factor mostly just shifts their exponents, it doesn't affect the (relative) precision. What usually does is an add (or similar) operation of numbers with wildly different exponents - but I don't see how this kind of problem could be fixed by scaling things up or down. I like your explanation of the feedback loop, I agree that this is certainly the case, but I feel we didn't get to the bottom of it yet. Commented Feb 26, 2023 at 22:10
• I don't think the issue is that the "range of precision" is somehow exceeded. I suspect its more to do with most numbers throughout the entire range being rounded slightly. Under the wrong conditions, that slight rounding can lead to a positive feedback occurring in the simulation. The reason overall scale would matter is the density of representable numbers; where the density is higher the error should stay lower, enough so that the simulation may be less prone to driving itself out of control. Commented Feb 28, 2023 at 20:58
• One thing I should have noted earlier is that it's a known issue with the rigid body simulation that unapplied object transforms causes misbehavior. I've never satisfactorily found an answer for why this matters and it may be a bug, but either way something to keep in mind when testing for instability at different scales (i.e. apply transforms before testing for best results). Commented Feb 28, 2023 at 21:15