Damping must be must be treated like a force (like in real world)

[L30n4rd0-4rg3nt1n0]

I have done a test. I created two identical cubes, giving them the same linear damp value (10) and a very large mass difference 1 to 10 or even 1 to 100, and then the bodies fall together all the time. That's not what happens in the real world, and I think I know why it's happening in GODOT. Apparently damping is treated in isolation from the rest of the forces present.

Let me explain myself...

I've been trying to understand what the "Damp" (or Linear Damp) property represents in the RigidBody3D class.

Reference: https://docs.godotengine.org/en/latest/classes/class_projectsettings.html#property-descriptions
(...) During each physics tick, Godot will multiply the linear velocity of RigidBodies by 1.0 - combined_damp / physics_ticks_per_second. By default, bodies combine damp factors: combined_damp is the sum of the damp value of the body and this value or the area's value the body is in. See RigidBody3D.DampMode.(...)

Based on this description I understand that the equation is

Vf=Vi (1-D dt)
where
Vi: Original speed value
Vf: New speed value
D: Damp (or combined damp)
dt: time between ticks
assuming that
Vi>0 and D dt<1

I'm right?... RIGHT???

So, we can re-write it like:
dV/dt=-D Vi
where
dV=Vf-Vi

If we took dt in the limit to zero we have
A=-D V
where
A is the acceleration...

...and we can multiply it by the mass "M" to obtain de force
F=-C V "Stokes law"
where
C=D M (C shouldn't depend on the mass, some cancellation must happen with D)

Reference: https://en.wikipedia.org/wiki/Drag_(physics)
This equation represents the "Stokes law", a particular case of the drag force expression when the Reynolds number is small. That is, a force proportional to the speed. The truth is that this is an approximation for a small Reynolds number. In other cases, a force proportional to the square of the speed is considered more appropriate. But for a video game perhaps it is a good enough model. Well, I don't know, it depends on how realistic we want the video game to be. At the moment I am not interested in discussing at that level of detail.

Ok, a correct physical equation is being taken into account. However, the damp force is not the only force acting on a body. In GODOT we also have the force of gravity. So the acceleration of a body is:

A=Fnet/M
where
Fnet= "Damp force"+"Gravitational Force"

Of course I am simplifying, since it is correct to work with vector magnitudes. In a simplified way we have that the speed of a falling body is calculated in each time step as
Vf=Vi+g dt-Vi D dt
where
g=9.81m/s^2 is de gravity's acceleration

If the fall lasts long enough, the speed increases until the damp force equals the force of gravity. That is
g =V D or V=g M/C
This is terminal speed, and it is greater the greater the mass. This implies that a body with greater mass reaches the ground faster. Of course, when D (or C) is very small, that terminal speed is so big that everything happens as if there were no damping. It is for this reason that in a vacuum bodies released from the same height reach the ground at the same time.

But that's not what happens at GODOT. I have done the test. I created two identical cubes, giving them the same linear damp value (10) and a very large mass difference 1 to 10 or even 1 to 100, and then the bodies fall together all the time.

It seems like the GODOT physics engine doesn't handle damping correctly. It does not treat it as a force together with other forces in order to compute velocity (vector magnitude) or speed (scalar magnitude).

I have been able to see the same erroneous treatment is present in other engines (such as UNITY with the "drag" property). That's not how the world works. I understand that a videogame doesn't have to be realistic, but if one is going to rely on a physics engine, what's the point if it can't reproduce realistic behavior?

My suggestion is that damping must be treated as another force and not as an exotic effect that mysteriously attenuates speed. If the intention was always to treat damping as a force, then it is very poorly done, almost to the level of considering this implementation very BUGGY.

[AThousandShips]

As you can see from the description:

Godot damping calculations are velocity-dependent, meaning bodies moving faster will take a longer time to come to rest. They do not simulate inertia, friction, or air resistance.

This is a limitation, you can simulate other physics with rigid bodies using custom integration

[L30n4rd0-4rg3nt1n0]

@AThousandShips I must admit that I missed the phrase: "They do not simulate inertia, friction, or air resistance." But if it is deliberately planned behavior, I really don't see the point. I still think that damping should correspond to friction or air resistance. So my recommendation remains that it should be implemented to meet that requirement.

And if not, I don't understand what it represents or what it is intended to be.

[AThousandShips]

Any simulation is a simplification, it's just a measure of how much it is, many physics engines work that way, it's expensive to make it advanced, and many don't care or need the advanced features

Have you tried the Jolt physics engine for Godot? I haven't myself but it might simulate more things?

I understand where you're coming from, but your post here is very much non-constructive, and focuses on comparing the engine to other engines (importantly ones developed by big companies, with a lot more resources) and frame the engine as "buggy", so you're unlikely to get a lot of support with that attitude, so I'd suggest that, if you want progress, to not be so negative

Especially it comes across as if you think that the engine developers are just ignorant and couldn't possibly have this limitation for a legitimate reason :) That won't help your case very well

Now that's just how it comes across to me, so take that with a grain of salt, it's not criticism or an attack, but more advice on how to get positive response

So to summarize:

• Physics is hard, I mean really hard, especially to get it to be responsive and performant
• Every single physics engine is a tradeoff, there's not a single physics engine in the world that does "real" physics, of course that's not an argument for not doing things certain ways, but let's not think that any physics engine represents the "real" physics
• Most people don't care about some of the real physics side of things for games, and pretty much every single game intentionally ignores actual physics, in fact games using more realistic physics are often not popular because of how it restricts you, the classic example is the ability to move in the air (or double-jump, but that one is obvious)

That last part has confused a lot of people, and I've seen a few issues reports (though I can't find them right now) where people were confused about the level of realism and how the engine simulated some degree of realism that they weren't expecting

So the important questions to ask are:

• How expensive is any one particular level of realism (it's not even a matter of a level, but specific features)?
• How in demand is it, what games would it target, are those games most people would develop with Godot?
• What are the workarounds, and can we provide them clearly? (I.e. code examples for _integrate_forces)

Thank your for your response and I hope my points are clear :)

[yosoyfreeman]

I think both Godot physics and Godot Jolt are behind in here. Neither of them has support for Static friction, which is extremely important to define physic behaviours, even the basic ones. I asked and there are no plans to support it by now, so we will have to life with objects requiring no force to push them or sliding forever. Note that static friction is taken into account in every other 3D engine i used. So yeah, i think there is margin for improvement.

In the case of the drag parameter, i think you are looking at it from the wrong eye. The Damping parameter does not refer to any specific force nor tries to do it in any engine i know. While you can approximate friction in a decent way based only on the points of contact between objects, this is not the case for air drag, in which theoretically the whole surface is in contact with an infinite amount of points and the air is treated like a fluid. Is expensive, is complex, and there is not a "good amount" of points that you can use for all objects.

Basically, unless you are intentionally programming something that reacts to aerodynamics and are willing to expend a good amount of effort doing complex physics calculations by yourself, the net gains are usually zero.

For the terminology: Damping in this case do not refer to the damping caused as a result of any particular force, but refers to the general concept of a damping force, which is the one that happens on oscillating motion and will tend to make it stop.

With that definition in mind you may see that it perfectly matches what happens in the game: Is a force that will eventually stop any motion. It's purpose is usually not to create complex behaviour, even if it can be used to simulate them to some extend. The damping parameter of a physics engine is usually there to make sure that any erratic movement or slight miscalculations do not accumulate and cause the bodies to gain imaginary velocity as a consequence. So in the case you have complex physics chains, the damping will help attenuate the vibrations. (Think of a rope composed of physical segments, it will vibrate due to the way collisions are resolved)

Hope this helps to clarify what is exactly this parameter doing.

TL;DR: I think we need better control in the way of static friction, i don't think damping should or even can simulate any kind of air resistance.

[L30n4rd0-4rg3nt1n0]

@AThousandShips

Any simulation is a simplification, it's just a measure of how much it is, many physics engines work that way, it's expensive to make it advanced, and many don't care or need the advanced features

I understand, I suppose that the tolerance threshold where one considers a simulation good enough is subjective and very personal.

Have you tried the Jolt physics engine for Godot? I haven't myself but it might simulate more things?

I didn't know about it, I'll look at it, thanks for the information.

I understand where you're coming from, but your post here is very much non-constructive, and focuses on comparing the engine to other engines (importantly ones developed by big companies, with a lot more resources) and frame the engine as "buggy", so you're unlikely to get a lot of support with that attitude, so I'd suggest that, if you want progress, to not be so negative

Well, actually I didn't make a comparison with a superior engine, in fact I mentioned that Unity has the same "problem". I saw the opportunity here to do something better than in that other engine, and I thought that mentioning it would make the proposal more attractive. I didn't realize that it could be interpreted as very negative.

Especially it comes across as if you think that the engine developers are just ignorant and couldn't possibly have this limitation for a legitimate reason :) That won't help your case very well

My fault, perhaps I underestimated the level of knowledge (in Physics) of the developers. I apologize if it was perceived that way.

Now that's just how it comes across to me, so take that with a grain of salt, it's not criticism or an attack, but more advice on how to get positive response

So to summarize:

* Physics is hard, I mean _really_ hard, especially to get it to be responsive and performant

Ok, I get it, maybe I don't get the idea of how demanding it is. I thought that, at each time step, the motor calculated the new speed (or velocity) in a similar way to the first equation I wrote. On the other hand, I suspected that the effect of gravity was calculated with some expression of the form Vf=Vi+g dt (well, in a vector version I suppose). That's why I thought it was immediate to integrate both expressions into a single one (like the one in the second to last equation), without this representing a greater requirement for resources. But of course, I imagine that many details escape me.

* Every single physics engine is a tradeoff, there's not a single physics engine in the world that does "real" physics, of course that's not an argument for not doing things certain ways, but let's not think that any physics engine represents the "real" physics

I agree, I understand that we are dealing with a solution where there is a trade-off between realism and functionality. I think the key is what departure from expected realistic behavior we can tolerate without perceiving dissonance. It is a very personal threshold. In my case, it feels strange to see a very massive body falling alongside a light body, because it is not what I expect to see (at least not under normal conditions with an atmosphere).

* Most people don't care about some of the real physics side of things for games, and pretty much every single game intentionally ignores actual physics, in fact games using more realistic physics are often not popular because of how it restricts you, the classic example is the ability to move in the air (or double-jump, but that one is obvious)

Me too, I don't expect to see a "Super Mario" where the movements look realistic. But there is a whole range of games where we want to maintain the illusion of realism.

That last part has confused a lot of people, and I've seen a few issues reports (though I can't find them right now) where people were confused about the level of realism and how the engine simulated some degree of realism that they weren't expecting

Well... I don't know what to say there. I don't know if I'm understanding you.

If there are people who have an expectation of what should happen in reality, that is not consistent with what happens in reality, it is a psychological issue that transcends the use of a game engine. If you are referring to people who do not want their game to look realistic, I suppose it would be enough to not make use of those functionalities provided by the engine.

So the important questions to ask are:

* How expensive is any one particular level of realism (it's not even a matter of a level, but specific features)?

As I said, I thought I was just integrating more or less the same amount of calculations. But if you as a collaborator/developer tell me that is not the case, then I guess I was oversimplifying the task.

* How in demand is it, what games would it target, are those games _most_ people would develop with Godot?

I really do not know. I myself am trying to understand the scope and limitations of this tool to know what I can do with it.

* What are the workarounds, and can we provide them clearly? (I.e. code examples for `_integrate_forces`)

I don't understand, are you saying that I should provide portions of code to implement in the engine? At the moment I don't think I can go that deep.

And if you mean implementing "better" physics in my Godot projects... Well, maybe I could, but it would be less work if it were already built in natively.

Thank your for your response and I hope my points are clear :)

Thank you for taking your time to respond to me.

[AThousandShips]

My fault, perhaps I underestimated the level of knowledge (in Physics) of the developers. I apologize if it was perceived that way.

You very much have, please don't assume things, it's never friendly or helpful to assume things like this, just because something doesn't work as you expect it doesn't mean someone else is ignorant, knowing how game engines works is an important knowledge to have when approaching this

If there are people who have an expectation of what should happen in reality, that is not consistent with what happens in reality, it is a psychological issue that transcends the use of a game engine.

I have no idea how you took that from what I said... You need to read what I said again, what I'm talking about is that in my experience most people don't expect certain physics to occur in the engine, even if it's realistic, because they don't understand physics and expect certain things from it, being confused over how friction works, or inertia, a highly realistic physics engine isn't in fact what most people need or expect or demand

I don't understand, are you saying that I should provide portions of code to implement in the engine? At the moment I don't think I can go that deep.

No, as I said I'm taking about custom integration

[L30n4rd0-4rg3nt1n0]

@yosoyfreeman

In the case of the drag parameter, i think you are looking at it from the wrong eye. The Damping parameter does not refer to any specific force nor tries to do it in any engine i know. While you can approximate friction in a decent way based only on the points of contact between objects, this is not the case for air drag, in which theoretically the whole surface is in contact with an infinite amount of points and the air is treated like a fluid. Is expensive, is complex, and there is not a "good amount" of points that you can use for all objects.

I think I understand what you're saying. You're talking to me about generic damping. However, in the GODOT documentation that I cite, it mentions a calculation that it makes with the speed (or velocity) at each time step. This calculation is compatible with a very simplified model of friction damping with a fluid medium (Stooke's law). Using this already simplified model it is possible, in my opinion, to obtain a more realistic result. The truth is that without looking at the GODOT source code I don't understand why this calculation is not working as a friction force (because in that case the most massive block should reach the ground first).

Basically, unless you are intentionally programming something that reacts to aerodynamics and are willing to expend a good amount of effort doing complex physics calculations by yourself, the net gains are usually zero.

I didn't expect something so sophisticated either.

For the terminology: Damping in this case do not refer to the damping caused as a result of any particular force, but refers to the general concept of a damping force, which is the one that happens on oscillating motion and will tend to make it stop.

With that definition in mind you may see that it perfectly matches what happens in the game: Is a force that will eventually stop any motion. It's purpose is usually not to create complex behaviour, even if it can be used to simulate them to some extend. The damping parameter of a physics engine is usually there to make sure that any erratic movement or slight miscalculations do not accumulate and cause the bodies to gain imaginary velocity as a consequence. So in the case you have complex physics chains, the damping will help attenuate the vibrations. (Think of a rope composed of physical segments, it will vibrate due to the way collisions are resolved)

I understand you, you are talking about an energy dissipation mechanism. In that case it is true that friction with a fluid is not the only way to dissipate energy... But, as I said before, in GODOT it seems that the energy is being dissipated by something very similar to Stooke's law

Thank you for taking your time to respond to me.

[L30n4rd0-4rg3nt1n0]

@AThousandShips

You very much have, please don't assume things, it's never friendly or helpful to assume things like this, just because something doesn't work as you expect it doesn't mean someone else is ignorant, knowing how game engines works is an important knowledge to have when approaching this

ok...

I have no idea how you took that from what I said... You need to read what I said again, what I'm talking about is that in my experience most people don't expect certain physics to occur in the engine, even if it's realistic, because they don't understand physics and expect certain things from it, being confused over how friction works, or inertia, a highly realistic physics engine isn't in fact what most people need or expect or demand

I've known people with that attitude, but I didn't think it was the dominant position. I guess there's something else to add to the "I'm alone in this" list.

No, as I said I'm taking about custom integration

Okay. Thanks for the clarification.

[AThousandShips]

I've known people with that attitude

What attitude? This isn't about an attitude, it's about expectations and what people expect in a game engine

Also please there's no need to tag me, it's just the three of us here :) also please use the threads feature you're creating really confusing conversations by creating new threads each time, no one can follow what you're talking about

[L30n4rd0-4rg3nt1n0]

threads feature?

[L30n4rd0-4rg3nt1n0]

I wasn't really understanding what you meant by "threads feature". But I just realized that some answers have a different colored background and appear further apart. Are they grouped separately? It seems that if I click on the 3 dots and choose "quote reply" I would not be doing the same as if I wrote in the box that says "write reply". Is that what you were referring to?

If I choose "Reply" or "Comment" am I doing something different? I honestly hadn't noticed and I don't quite understand the difference.

[L30n4rd0-4rg3nt1n0]

@AThousandShips @yosoyfreeman Okay people, after considering what you told me, I realized that my proposal has a problem. Energy dissipation occurs by many mechanisms. Friction with air is not the only way damping occurs. If we considered damping as an effect of friction with the air, in a game taking place on the Moon, since the bodies take the same time to fall, we would be tempted to take damp=0. But that would be a mistake, because damping occurs anyway due to friction between the different bodies that interact in the scene. With my proposal we had a solution to "a problem" (unexpected behavior on Earth, bodies that take the same time to fall), but it would have introduced another new problem (unexpected behavior on the Moon, bodies that do not slow down at all). I understand better now that, regardless of the resemblance to Stokes' Law, the way damping is implemented cannot be assimilated with air friction. Sorry for the inconvenience, please reject my proposal.

[yosoyfreeman]

Thank you for understanding. We just want to help.

Nice day!