PinJoint2D's Softness = 0 doesn't firmly fix the bodies

[genete]

Operating system or device - Godot version:
OS X 10.10.3 Godot 2.1 stable official.

Issue description (what happened, and what was expected):
On the composition of the #6314 issue changing the gravity scale from 0.1 to 20 produces a pendulum that at first strokes reduces its amplitude drastically. It is caused by the softness parameter that although it is zero (rigid) it still uses some kind of softness, causing the body loose its potential energy that it has at start.

I expect the behavior of a friction-less pendulum (amplitude equal its initial position) but with higher frequency due to gravity scale.

Steps to reproduce:
Open issue #6314 and change gravity scale from 0.1 to 20

Link to minimal example project (optional but very welcome):
See #6314

[eon-s]

Looks like this affects master too.

Example also on the issue mentioned in the OP.

[pwab]

I just looked into this and it seems to be reproducible in Godot 3.2.1 on my Windows machine. I wasn't able to get a friction-less pendulum which would get to its initial position the whole time. Somewhere in between energy is lost but I haven't figured out where and why.

Here is the updated sample project:
pendulumv3.zip

I removed PhysicsMaterial and tried different physic settings. Damping, bias, softness are 0 and there shouldn't be any friction (please correct me if I'm wrong here). You can see that the pendulum never reaches its starting position again - so it looses energy.

[madmiraal]

@pwab I've just run your example project, and, as far as I'm concerned, it's a frictionless pendulum. Yes, if you leave it running, it will eventually drop from 90° to 89°, but this is probably due to a floating point rounding error.

I think the original issue has been resolved at some point, or it may have been due to the default damping. Either way, I think we can close this issue.

[pwab]

Yes, if you leave it running, it will eventually drop from 90° to 89°, but this is probably due to a floating point rounding error.

Just to understand it correctly: There is still energy loss on master? If so I can create another issue for this to track. Even if it is a floating point rounding error this could be solved somehow (or at least documented).

[madmiraal]

There is still energy loss

As long as the "energy" is not increasing, I wouldn't call this a bug. In the real world there is always energy loss; so the physics engine reflects reality.

this could be solved somehow

When trying to simulate physics on a computer, there will always be rounding errors, because the engine uses discrete time steps and floating point numbers have limited precision.

or at least documented

I suppose the short answers is: If you want a non-damping solution, don't use physics. However, I'm not convinced documenting this is necessary. I would expect most people to use the AnimationPlayer before trying to use physics.

[pwab]

I can totally understand your thoughts about rounding precision and using the AnimationPlayer. If this is not wanted I won't create an issue for that. The only thing that I want to comment on is this:

In the real world there is always energy loss; so the physics engine reflects reality.

If there is no energy transformation in form of friction (conversion of kinetic energy into thermal energy) or deformation (there is non in rigid body dynamics) you don't have any energy 'loss' in a dynamic system because it is an Isolated system.

So in a rotating system where only the gravity applies (pendulum) you convert potential energy into kinetic energy and back. If friction is 0 then this is totally a Simple gravity pendulum and there shouldn't be any loss of amplitude.

[madmiraal]

In the real world there is always friction.

[pwab]

And Godots friciton setting can be set to 0 so if

[...] the physics engine reflects reality

why it can be set to 0 and what effect do we expect here?
I would expect to get a non-real-world simple gravity pendulum.

[pwab]

Apart from my last comment about friction in general I'm now convinced that this doesn't have to do with friction at all. I changed the gravity in my sample and it can be clearly seen that the higher the gravity value the higher the instant amplitude drop will get. This can be prevented if the Engine.time_scale is set to a lower value which seems to be not quite far away from working with time scaling in bullet.

After the initial drop no energy is lost (so no friction is applied) but the fact that the system changes the amplitude while the gravity is changed (while keeping the time_scale) seems to be a bug or it should be documented that manipulating the gravity leads to non-physical behavior if the time_scale is not adapted accordingly.

I'm going to investigate this with more samples and if I can confirm this I'll create another issue because softness or friction or damping doesn't seem to be the problem here - it's gravity scale (or the project wide gravity) combined with the time_scale.

---

For testing just change the gravity from standard 98 to 9800 and back and watch the change of amplitude in the first frames (drop) and then the pendulum continues as expected:
pendulumv3.zip

[mrcdk]

The joint's bias has an effect on the bodies. If I undertood it correctly, the lower the value the more the bodies will be pulled towards the joint. I think that that's the force that's causing the issue. Set it to a higher value and it should work as expected. I'm not sure why it's clamped to 0.9 in the editor, set it to 1.0 in a script.

[pwab]

Hey @mrcdk thanks for the suggestion. This was somehow working but also it does not. Here is the test project where I added a simple graph to visualize the rotation:
pendulumv3-1.zip

And here are some test scenarios with Engine.time_scale = 1.0 and different gravity + bias settings.

gravity = 9800 | bias = 0

Here you can clearly see the energy loss.

gravity = 9800 | bias = 1

Much less enery loss - but still there.

gravity = 980000 | bias = 0 | at the start

A huge drop at first and then much energy loss.

gravity = 980000 | bias = 1 | at the start

A huge drop at first and then less energy loss.

gravity = 980000 | bias = 1 | a lot of time passed

This is after a two or three minutes.

As you can see this needs much more investigation and maybe some benchmarks with parameter matrices to compare the results. I'll keep this issue in mind but I'm sure I should create another issue for that topic.

[madmiraal]

I'm going to investigate this with more samples and if I can confirm this I'll create another issue because softness or friction or damping doesn't seem to be the problem here - it's gravity scale (or the project wide gravity) combined with the time_scale.

@pwab Have you created a new issue for this? I can't find it.

[pwab]

@madmiraal Oh no I haven't found the time for doing it with more accuracy so I restrained. It's still on my todo list for this year though 😅
As soon as I have more to show I'll mention you and link to this issue here.