Godot: 2D physics Weight vs. Mass equation seems to have an unexpected scale factor of 10

[ArdaE]

The correlation between the default gravity entered in Project settings and RigidBody2D's weight/mass conversion seems to have an extra scaling factor of 10. If gravity is 98 and mass is 1, then weight should be 98, but it is 9.8. If gravity is 50 and mass is 1, then weight should 50, but it is 5.

RigidBody, the 3D counterpart of RigidBody2D, doesn't have the same issue. If gravity is entered as 98 as the 3D default and mass is 1, then the RigidBody's Weight is displayed as 98, which is as one would expect.

All of the above is assuming International System of Units (SI), but the same argument can be made for any consistent units of measurement. I realize Godot doesn't necessarily adhere to such units for its 2D physics engine, but what's the point of introducing an unexpected extra scaling factor of 10 in the calculation of Weight. Such scaling would only be acceptable if the produced numbers are either too large or too small for human taste (i.e. they introduce too many 0's in our normal decimal number notation). 10 doesn't qualify for that. In short, the unit of weight should simply be the unit of mass times the unit of gravity (i.e. acceleration) without any extra scaling.

I'm assuming this is just a display issue, i.e. an easy issue to fix. If it goes deeper into how the 2D physics engine works, then please simply ignore this report, as it's not worth changing anything deeper than the user interface for this.

Godot version:
V3.0, custom build (currently based on Commit #44cce2b of Jan 24, 2018, but the issue has been there for awhile).

[akien-mga]

See this discussion: https://github.com/godotengine/godot/pull/9497#discussion_r125625597

This is actually on purpose, as 2D physics work with pixels and integers (while 3D physics work with meters and floats).

[ArdaE]

Thanks @akien-mga. The key point I see in your comment is not "pixels" but "integers". A pixel's length is just another unit, but using integer arithmetic can affect scale. There isn't much of a reason to use fixed-point arithmetic these days, but considering Godot has a decade-long history, integers would have made sense back then (and maybe still for some platforms?).

In any case, I still don't see how Weight would need an extra scale factor of 10 because of the use of pixels for units or the use of fixed-point arithmetic within the physics engine, because I don't see how the physics engine would care about Weight; it should only use Mass. The engine would be free to set the scale of distance and mass to whatever units make sense, but isn't weight just a calculated property just for convenience to users? And if it is calculated, it can be represented via a floating point number, which it already seems to be, and there's no reason for it to have an extra scale on it regardless of the units used. That extra scale factor simply creates a self-inconsistent measurement system in Godot, in my opinion. Having said that, I'm questioning if the extra scale factor was introduced in order to make every 10 pixels feel like a meter, and allow the use SI-like units for Weight (i.e. in the range of kilograms). But that approach would fail quickly when the scale changes dramatically, e.g. where each pixel is a light-year in length.

I'll have to dig into the code to confirm if Weight is ever actually used in the physics calculations (which I highly doubt), which I'll do after some other high-priority tasks I have and after I finish reporting some more bugs I jotted down in the last 2-3 weeks of experimenting with Godot.

[bojidar-bg]

Weight is just an editor "helper" property, which just mirrors mass * gravity. It doesn't even read the gravity setting right now. (old information, sorry)

[ArdaE]

I just took a look at the source code. Weight is a calculated property as I suspected (it's converted to/from mass on the external interface of RigidBody2D; it's not stored in RigidBody2D, and the physics engine doesn't care about it). In addition to that, weight is a floating point number, not an integer. So there's no reason for it to have an extra & arbitrary scale of 10 on it. This is what the current code does:

• When weight is set, mass is set to weight / gravity / 10
• When weight is read, mass * gravity / 10 is returned

Not only is the scale of 10 completely arbitrary here, it is not even applied correctly (note how the two equations are asymmetric -- see issue #16038). Putting gravity / 10 in brackets would make the equations symmetric, but then there's the question of why an extra scale of 10 on weight. So why not define it as x * pixels / second^2, where x is the unit of mass? (This is as opposed to the current ambiguous definition of 10 * x * pixels / second^2 if we take the first equation above or 0.1 * x * pixels / second^2 if we take the latter.)

Considering the current equations are already asymmetric, and hence ambiguous, I propose that the extra scale of 10 is removed. You could even remove Weight completely, and the code would be better without it as its unit is quite meaningless right now. I feel like someone tried to get the numbers to look SI-like based on the screen scale of a project they were working on, and hence introduced this arbitrary scale factor.

[bojidar-bg]

The scale factor likely comes from the fact that the 2d physics system uses pixels (not meters), while the 3d one uses arbitrary units (which are likely meters).

[ArdaE]

It doesn’t matter that Godot uses pixels for units. Currently the 2D “Weight” calculation is internally inconsistent with the rest of Godot’s 2D physics units. Weight works on a basis of 10 pixels in one case and 0.1 pixels in another case as I described above in detail. It should be based on 1 pixel like everything else in the 2D engine. Units should be kept consistent; otherwise they become meaningless.

[razcore-art]

I completely agree with @ArdaE, for our own sanity please don't use some hidden calculations that we're not aware of just for the sake of showing us visually something that isn't even used in the engine. As I understand the weight parameter isn't used in the actual physics calculations which makes sense cause the weight should be calculated at run time, BUT it does change the mass in the inspector in an unpredictable way. I argue remove weight. Most of us don't use weight when reasoning about simulations, but think of mass and this just adds to the confusion.

In 25275de... might be related to this, haven't looked in depth, but if you set weight to 100 and run the game, you'll be surprised to find out that the weight is set to 1 in the inspector. If you set it to 10000, and run the game, after you close the window, the weight jumps to 100, there's definitely some weird factors in there that have no reason to be there in the first place. And there's definitely some bugs there cause the mass/weight isn't calculated properly when changing one of them in the inspector.

So one last time, let's just remove the weight property please.