Create Global PixelsPerMeter setting and change force units to Newtons.

[zitongcharliedeng]

The engine has arbitrarily locked 1 meter = 100px.

Having the default force unit as kg*px/s^2 instead of Newtons is a pain to work with.

Physics code would be more intuitive if we used consistent SI units (like having gravity in m/s^2), and added a single PixelsPerMeter variable e.g. in editor settings, like in Unity, for 2D worlds.

The lack of this "scale variable" I am proposing also makes it harder to do things such as increasing the resolution of the textures in your game (e.g. 32x32 texture pack into 64x64), you'd have to change all your force values and gravity values to compensate, which would be much easier with a single PixelPerMeter setting.

Please end my suffering.

Although, I haven't been using the engine for very long. Maybe someone could enlighten me on a workaround/ correct my misunderstandings?

[AThousandShips]

The engine has arbitrarily locked 1 meter = 100px.

What are you basing this on? The only thing that seems to represent this (indirectly) is that gravity defaults to 980, but you can just change that, is there any other place where there's this definition of units in physics or otherwise? What is the usefulness of defining a meter for 2D in the engine?

[AThousandShips]

Just add a constant of your own to do the conversion?

Why add extra complexity? And expecting everyone else to track this instead, as people are pretty used to using pixels for 2D

[zitongcharliedeng]

Yeah, that's what I do for now, but in my eyes having it in pixels is adding more complexity.

Picture that you have a player sprite (moved by forces) standing on a static Island sprite. If I now decide I want to double the resolution of both my sprites to give them more detail, I can change their sprites, doubling their size. But now, since the forces are the same, my higher-resolution character now accelerates at half the speed (relative to the higher-resolution Island) than before.

To fix this we can then double the forces exerted on the player sprite, but then imagine we have many more player sprites - we'd have to change all of their forces too.

With a PixelsPerMeter setting, we can simply just change the value from e.g. 10 to 20 px/m, and everything moves as expected again.

[AThousandShips]

You just add a constant, you don't have to change the individual forces? Or apply scales?

I'm asking again: how does meter translate at all and how is it a better unit then pixels? Only one of those two relate to anything real or tangible

[zitongcharliedeng]

Do you mean every time I define a force in a script I should multiply it by a constant?
And how would you solve this with scales?

Maybe I'm just too used to SI units and can't let go...

[AThousandShips]

Yes, you're already defining the forces no? And you can just scale your objects if you change the resolution, but I'm not sure why you'd be changing the resolution so often that this becomes a problem

My recommendation is to just get used to the units used, just as if you were used to feet and needed to use the 3D

Also adding a global scale would affect performance as it'd have to be applied to everything when computing, instead of the user just applying it where needed

[theraot]

Maybe someone could enlighten me on a workaround?

Make a constant, put it on a script with a class name, something like this:

class_name Units

const Newtons := 100.0 # or whatever

And then define your forces like this:

var force := 10.0 * Units.Newtons

[theraot]

How would changing the project settings for every project with a different scale be less of a pain?

[zitongcharliedeng]

You would have to import the variable every time you use a force in a script and units in node properties don't accept variables:

So if I wanted to change the overall scale of the game, I would have to edit every gravity scale manually instead of just changing the pixelspermeter value I proposed.

[AThousandShips]

You would have to import the variable every time you use a force in a script

Import? You mean reference it? For global constants you just use an autoload

every gravity scale

What "every"? Use a global value and you're good? Why are you having multiple gravity scales?

[theraot]

@zitongcharliedeng

So, you need a world scale and more than one gravity? OK. We can do this.

First of all, I want to say that "You would have to import the variable every time you use a force in a script" does not sound like an issue to me. The only way I can see that being a problem is if some of the code is not written by you, but by third parties.

Now, I'm aware that most tutorials the character bodies would have gravity hard coded, or exported as a variable you set in the inspector. That does not help you, precisely because it makes it hard to change things globally. Instead, for the cases where things need to have a different gravity, we can work with gravity factors, so they can adjust automatically to changes in gravity.

How? Well..

---

As you know the game engine already has a global gravity which rigid bodies use. This is set in project settings, but areas can also override it (did you know that areas can override gravity? areas can override gravity).

We are not going to read the project settings directly, instead we are going to query gravity from the physics server. That way, areas can override gravity for character bodies too.

Like this:

var gravity := PhysicsServer2D.body_get_direct_state(get_rid()).total_gravity

And again, if you need more than one gravity (e.g. one gravity for jumping and another for falling), you can define them as gravity factors. That way if the gravity changes (because of project settings or because an area, it will adjust automatically).

---

As would know the project settings in question are:

• physics/3d/default_gravity and physics/3d/default_gravity_vector for 3D
• physics/2d/default_gravity and physics/2d/default_gravity_vector for 2D

Know also that you can read them and write them with ProjectSettings.get and ProjectSettings.set, respectively.

---

Now, you want to define the world scale, and you want changes to it to automatically change the default gravity. We can do that! First we need to decide where to store the world scale.

• You can use a const in a named class as I suggested initially.
• You can use a property in an autoload as suggested by AThousandShips.
• You can define custom project settings. From the project settings window, enable advanced settings, type a name for your custom project setting, pick a type, and click "add". So if you want to have a "world scale" property, you can have it.
• You could use a resource file that everybody loads. Hey, you can have multiple of these.
• Somewhere else I have not thought of?

What changes is where you have to go to change the value. They all work.

Now, you are going to need an autoload anyway. Since autoload load before the main scene, this autoload can adjust gravity settings based on the custom world scale property before the main scene is loaded. I already told you how to read and write project settings, I'm confident you can figure out the code.

Now, just cover all our bases, perhaps in some game you will want to change the world scale in runtime. Then opt for either the property in the autoload or the resource file, because in those cases you can define a setter for it.

In the same place you can also store conversion constants or whatever else you need.

---

The script in your character could read project settings or wherever you decide to store things. For example, if you need to set a target gravity, you can figure out which factor it is with respect to the default gravity from project settings... So you can keep only the factor, and as I said, that way it will adjust automatically to changes in gravity.

---

Perhaps this continues to sound like a lot of work, but think that once you have this code in place, you will be able to change the setting in a single place. If that single place is a script or project settings, makes little difference.

Regardless if Godot gets this in the future or not, I'm giving you a solution that works today.

[zitongcharliedeng]

😲 Woah. You didn't have to do all this for lil' ol' me. Thanks to everyone for the advice so far, I'll definitely try these.