No friction at kinematic rigidbodies

[JirkaDellOro]

Just a question:

a recent game has turntables and objects placed on top of them, which should turn with the turntables due to friction. However, if the turntables are kinematic rigidbodies, which makes the movement easy, no fricttion occurs with the dynamic bodies resting on top. Is that the correct behavior?

If so, I guess the system to try for this is placing the turntable as a dynamic body in combination with a rotational joint, so that it is kept in place and won't spin out of control due to the reactional forces of the other bodies. Correct?

[Dev-MarkoF]

Hi, Could you post a link to the mentioned game?

In general kinematic bodies should apply their properties to others, but do not register anything themselves, which is what results in their behaviour of being easy to control. In case of friction this way of thinking could lead to the potential problem that is described here. Because friction is something that is happening between two bodies, so if one the dynamic body is not applying the friction of the dynamic body to itself because it's kinematic properties, then the whole result of the friction could be skipped also for the dynamic body, even if both bodies have a theoretical friction value.

My way of thinking would be that the kinematic body is actually fixed to have 0 friction property by the engine to ensure there is no friction applied on itself, since friction is multiplicative and so the result is always 0, and the dynamic body get's the same 0 calculation and yes that behaviour would be intentional, but probably it's not the expected behaviour.

Your workaround is the correct way of dealing it, but there a caveats to that approach, because with a dynamic turn table you have to work with acceleration which is probably not what you want in that game.

I will look into the reasoning why and if it works that way.

Update, until now i have not found a specific point where a friction is skipped because of the body physics type and a kinematic body does bring it's friction into the general equation of friction between two bodies. But i suspect that on the actual solving of the impulse/velocity the result is dropped, because the kinematic body does not have an impulse/velocity. There is definetly not a specific switch that is stopping it from happening.

[Dev-MarkoF]

I guess it's intended behaviour with kinematic bodies vs. dynamic in general.

A quick testscene in Unity with 2 Cubes, 1 kinematic - turning by transform.rotate 1 dynamic - sitting above with high friction (close to the edge) results in no rotational interaction between those two, instead of the probably expected "dynamic" moving/rotating with kinematic. (Physics Material with "Maximum" as friction, not the standard "average", which would result in 0 friction, if one body is 0)

[JirkaDellOro]

So the video shows the same behaviour, but with Unity, correct? Did you find any written documentation? I didn't see anything about it in the OIMO-Doc.

As for the turntable with joint: I created a little example and set the angularVelocity each frame. So that should remain constant TurnTable.zip .

[Dev-MarkoF]

Yes the video shows a turntable with a red cube (in Unity), the expected behaviour would be that the red cube is moved/rotated by the force of friction, since it is "touching" the underlying "turntable". The cube is near the edge, to test if it registers correctly the moment where it's physical center is over the edge, which it does. To test if the problem is that the kinematic body is 0 in the equation i tried to set the physical material to calculate the maximum friction, which changes the equation from *fric = bf1 bf2 to fric = bf1 > bf2 ? bf1 : bf2** (bf = bodyfriction). This is an option that OIMO does not have, OIMO does always calculate friction as a result of both, but the change does also not result in a different behaviour than the one OIMO is showing.

The resulting friction would pull the object along, when both are dynamic, because i guess of a force applied along the orthogonal direction of the collisionpoints normal dependent on the velocity of the kinematic body. My guess is that the kinematic body does not have a "velocity" in this step, since the whole point of a kinematic body is that it's not "really" physics based, but directly set through a transform + some influence of actual physical bodies (e.g. collision).

The Unity test is to verify my findings within OIMO, to be the behaviour that is expected in physics engines, even if it's not the expected behaviour in real physics. Since kinematic bodies are a construct of game physics and not real physics, the behaviour can differ from your expectations.

I didn't find any documentation on OIMO or Unity if this is intentional, but the conclusion of the experiment and some digging within OIMO show similar calculations of actually having a friction between those body types that is skipped in a solving step afterwards. There was one forum thread where someone asked a similar question but only got the answer to use joints/dynamic bodies.

It's not feasable to find out if it could be changed to match your expectations, because the actual solving step does not differentiate between singular bodies by any name, finding singular values by logging is therefore tedious. It's definetly not a switch/flag that isn't set, but underlying physical calculation, of forces that are 0 beacuse the counterforce of a dynamic body on a kinematic/static body is always 0 and so the solving between the two bodies can only result in either something that is physically incorrect, or in throwing away those forces (which seems to be the case).

The workaround is in my opinion the better way to understand physics, kinematic bodies should really only be used in very specific cases, like the player, because in reality a turntable is exactly build of what the "workaround" does.

TL;DR;

• The behaviour is indeed intentional, because it appears at least in multiple engines.
• It seems that the workaround is simple enough, to have a turntable on a joint. (Your example seems to work great)

[JirkaDellOro]

Ok, good to know, Thanks. Since it's intentional, using a joint then appears not to be a workaround but the correct solution. And it's fairly easy and straightforward. But always an interesting design challenge to use physics correctly...