Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the default gravity settings of the RigidBody2D Node so its physics feel less floaty out of the box #98

Closed
golddotasksquestions opened this issue Sep 23, 2019 · 6 comments · Fixed by godotengine/godot#36263
Milestone

Comments

@golddotasksquestions
Copy link

golddotasksquestions commented Sep 23, 2019

Describe the project you are working on:
2D Action game. Eventually I want to incorporate RigidBodys in my game, so I make a number of test projects.

Describe how this feature / enhancement will help your project:
RigidBodies2D gravity never seems to behave realistic out of the box. The reasons why one setting won't be the perfect setting that fits all projects, are obvious. What settings I have to change though and why the current default settings are not correct, is the exact opposite of obvious. But having the default settings come closer to what the majority of users do would already help A LOT in getting off from a much better start.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
My proposals is just to change the default settings.

Describe implementation detail for your proposal (in code), if possible:
I assume since in the 2D engine the unit is one pixel not one meter as it is in 3D, those 9.8 refer to 9.8 pixel, not meters. This seems plausible, because if you make your RigidBody2D's CollisionShape exactly 2 pixels high (comparatively to a person of 2 meters height), and zoom waaaay in with your camera onto your "character" so much so those two pixels seem as high as a character on screen normally would, gravity seems very natural.
However most people won't have 2 pixel characters to apply RigidBody2D physics to and a viewport of 11 by 20 pixels. At this resolutions, pretty much any "ball" will be a square. RigidBodies would not make that much sense here anyway:
11x20
This brown football is never going to roll.

KidsCanCode RigidBody2D demo runs at 1024 by 600 and has a gravity scale of 20 and it still feels floaty. The more realistic value with a character that size and items that size would probably be around 50.
default_gravity
The left ball has a gravity scale of 50, mass 2, and weight 19.6,
the right ball has the default gravity scale of 1, mass 1, and weight 9.8,

There are a lot of values to tweak to get RigidBodies to behave like you want them. Let's make new users not also wonder why the 9.8 they associate with gravity ever since school a specific value they don't need, and neither is the neat 1 of gravity scale. (Why would anyone who wants natural gravity think of scaling it?)
The default setting looks correct, it looks as if it needs no changing. When in fact they are only correct in a world with 2 pixel characters.

The 1024 by 600 is the default project resolution, the default Rigidbody2D physics settings should feel realistic with those settings.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Since this is about default values, it would be used every time RigidBody2Ds are used.

Is there a reason why this should be core and not an add-on in the asset library?:
Core, because it's a usability setting of an existing feature.

@nuke-haus
Copy link

nuke-haus commented Sep 23, 2019

This would be a simple change and something certainly more user friendly. Perhaps have default physics settings for 3d projects and default settings for 2d projects. Make the default 2d physics settings more earth-like and less floaty out of the box.

@Calinou
Copy link
Member

Calinou commented Sep 23, 2019

This will break compatibility in all projects that don't override the default gravity, so this will have to be done in 4.0.

Also, the gravity scale of 50 seems a bit excessive to me. Maybe something like 35 or 40 would be a better fit?

@golddotasksquestions
Copy link
Author

golddotasksquestions commented Sep 23, 2019

Perhaps have default physics settings for 3d projects and default settings for 2d projects.

Both are not necessary since we are talking about RigidBody2D, here. 3D has it's own RigidBody node and can just keep it's defaults (I have not tested the defaults of the 3D RigidBody, but I would assume it's fine)

@golddotasksquestions
Copy link
Author

golddotasksquestions commented Sep 23, 2019

@Calinou

This will break compatibility in all projects that don't override the default gravity, so this will have to be done in 4.0.

I'd be fine with that. Better late than never. 4.0 will bring many compatibility breaking changes anyway.

Maybe something like 35 or 40 would be a better fit?

I tried it first with 20 then 30 and 50. 30 looked still very floaty to me, but anything would be better than 1.

@Xrayez
Copy link
Contributor

Xrayez commented Sep 25, 2019

I confirm this, I always set physics/2d/gravity to ~700.

@Calinou Calinou changed the title Change the default gravity settings of the RigidBody2D Node so it's physics feel less floaty out of the box. Change the default gravity settings of the RigidBody2D Node so its physics feel less floaty out of the box May 4, 2020
aaronfranke pushed a commit to Calinou/godot that referenced this issue May 6, 2021
This makes 2D RigidBody physics feel less floaty out of the box.

This closes godotengine/godot-proposals#98.
@akien-mga akien-mga added this to the 4.0 milestone May 18, 2021
@SmartySmart702
Copy link

SmartySmart702 commented May 31, 2021

Since Area2D's can override the gravity for objects inside itself those gravity settings should be change too. Right now the values are clamped to -1024/1024.
But maybe a "World Scale" property in the Project Settings would be better? Something like 256px == 1m so physics can be constant. For 2D only oc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants