Roulette Simulation Rigid Body

Hey everyone,
I am currently making an roulette simulation. I have 4 main objects: the bowl, the sphere, the spinner in the middle and the separators which separate the numbers (I don’t know the correct name for these). I have animated the spinner to rotate on the z axis and linked the separators to it, so they rotate with it. The ball runs in the opposite direction. I have set to origin for all objects to center of mass. All objects are declared as passive, except for the sphere. The bowl is declared as mesh, the separators as convex hull (Base), and the spinner also as mesh. I have also increased the steps per second to 1.000 and the solver iterations to 100, but I always get the same strange behavior. The problem now is that as the ball collisions with the separators, the ball bounces off extremely from the separators. I have looked at several videos from youtube of an roulette wheel, and that’s not the typical behavior of the ball. I have set the bounciness on everything to 0 but it still behaves like that. I am already going crazy about this problem, I really hope somebody has a solution for me :slight_smile:

PS: I am quite a newbie, sorry if I made a stupid fail which should be obviously

No, I don’t think you made a mistake. Indeed there is a thing that has been bugging me all along with the rigid body sim, which I suspect is what you are encountering here.

If you make a dynamic rigid body hit a resting, passive body with bounciness set to 0, it will stick perfectly after collision. But if you make an animated body (also with bounciness set to 0) hit a resting dynamic body it will bounce off, totally ignoring the bounciness setting.

That makes zero sense physically. No idea why it does that. Would be interesting to know whether the Bullet engine itself (which Blender uses internally for rigid bodies) also shows that behavior.

If you crash a bicycle full-speed into a stationary truck, the bicycle will come to a stop. If you crash a truck into a stationary bicycle, the bicycle will go flying.

That’s what’s happening here. Anything that’s passive or animated is an immovable object, an unstoppable force. When it collides with anything dynamic, it’s as if its mass is infinite. It’s completely unaffected by the collision.

Meanwhile, the dynamic body acquires velocity by sampling. It checks to see if it’s inside a collision body, and if it is, it moves itself out of it, acquiring velocity from the movement, rather than simply acquiring the velocity of of the colliding body. This is inherently error-prone, but if it errs on one side, it will still be inside the volume, maybe the next frame, and just do it again, so the only direction the error can go is for it to acquire more velocity than the colliding object. Regardless of bounce settings.

What can be done? Well, I think it’s a mistake to think that Blender physics are remotely realistic-- they are ways to create motion that might be difficult to animate by hand, but they are not simulations. You are always going to have problems, and you might as well get used to it. But if you really want to, it wouldn’t be impossible to give colliding bodies some mass and control them via animated constraints, rather than directly as animated rigid bodies. Of course, that would mean pumping steps through the roof, and it’s really not what Bullet physics were designed for-- Bullet physics are for game engines, for creating reasonably performant physics within certain limits, with error considered perfectly acceptable.

No insult meant, but sorry I need to disagree.

That isn’t true (https://en.wikipedia.org/wiki/Galilean_invariance). Or to be more exact, it can only be true when comparing apples to oranges, like a stationary bicycle without cyclist and a moving bicycle with a cyclist on it, or assume the truck is breaking voluntarily after impact.

That might be close to the right explanation of what is happening, but it is a serious deficiency of the sim, then. It certainly can be fixed. Engineering sims aiming at physically accuracy do not do that (to a significant degree). It also doesn’t explain, why bounciness is ignored.

Of course physical correctness is sacrificed for speed in sims for CG, but IMHO such a basic setup should be possible to sim more accurate.

As a side remark, I’m less surprised about rotation. It is no less wrong, but less noticable in most cases. It assumes the center of gravity to be at the object pivot point and has no notion of an inertia tensor. It just assumes isotropic momentum of inertia, which can’t be adjusted. The consequence is that one cannot sim a wobbling rugby ball or the increase in rotation speed when pulling the legs close on a swivel chair.

But this is way more understandable, given that it is way more difficult a concept and relevant for fewer situations and thus likely being sacrificed not for speed but for UI simplicity.

The bicycle acquires the full velocity of the truck. (More or less, a truck isn’t actually an immovable object like an animated rigid body is.) That’s invariant of inertial frame. The bicycle becomes “stationary” in either frame-- but stationary in the second frame has a velocity relative to the road.

I’m sure there are a lot of different ways to “fix” it. (It will always be prone to error, to spherical cow assumptions. I don’t think there is any single physics sim-- somebody making a plane needs different models than somebody making a bridge.) You don’t need to use sampling. You can solve the equations of everything involved. But I hope that anybody trying to do that doesn’t get rid of the version of rigid body physics that can actually be evaluated in a reasonable time frame.

Should also be said that to get more real physics, you lose the convenience of animated/passive bodies. You have to start interacting with everything through impulses, through constraints.

Bounciness is not ignored. Just did a test, gravity off, two stationary cubes, one bounciness 1.0, pushed by an animated body with bounciness 1.0, and there’s a clear difference between the bouncy cube and the other one.

I found a “workaround” for this problem. I played quite a while with the Steps per Second and the Solver Iterations.
And made the friction on every object higher, that nearly removed all the bouncing.
But now something else very weird happens.
I made the animation on my iMac from 2015 and it worked well, today I switched to Windows with a Nvidia 2080 Super graphics card and the animation looks completely different.
Is that normal?

Yes, I agree. But that would mean, with fully inelastic collision (bounciness=0) the bicycle should stick to the truck.

You are right, there is a difference, just much too little, thus it still bounces off.

Hmm, didn’t see the sim, but I’d say the physical system is unstable (sensitive to small changes). After all that is the point of the roulette setup, to add to the unpredictability to the result. Thus running with a build of Blender with a different compiler and/or different build options the small changes introduced from differences in rounding errors can create a completely different outcome.