RigidBody and RigidBody2D ignore scaling on runtime

[akien-mga]

Operating system or device - Godot version:
Mageia 6 x64, Godot 2.0.4.1 and master HEAD.

Issue description (what happened, and what was expected):
RigidBody2D does not respect its scale parameter, or that of its parents. When scaling a RigidBody2D (directly or by scaling its parent), it shows properly scaled in the editor, but on runtime the scale is ignored.

Steps to reproduce:

1. Add a RigidBody2D, with a Sprite to actually see its size
2. Scale it down or up
3. Run the project

Link to minimal example project (optional but very welcome):
3.x MRP (works in master too): RigidBody2D_scaling_bug.zip

(Old 2.1 project: RigidBody2D_scaling_bug.zip)

The project has a root Node2D scaled by (0.2, 0.2), and RigidBody2D, StaticBody2D and KinematicBody2D children. When running the scene, you'll see that only the RigidBody2D does not respect its parent's scale.

[reduz]

This is intended, because physics bodies manage their own transform which overwrites the ones you set.
Some kind of workaround could be done eventually, but not until 3.0

[ivanskodje]

Posting this here in case someone else also needs a "hack" to forcefully make scaling work on RigidBody2D.

You can use integrate forces to set the scale. For example,

func _integrate_forces(state):
	set_scale(Vector2(-1, 1))

[JarLowrey]

Also if you set the mode to "Kinematic" it will scale #7375 . _integrate_forces wasn't working for me.

Edit: got _integrate_forces working, think I copied something wrong. That's def better than changing your body type.

[reduz]

may do a workaround for 3.1 I am still not convinced it will work, though

[raffomania]

Is there a way to scale rigidbodies before instantiation?

[reduz]

there should be a tracker with all these things, so i can work and remember everything after 3.0

[aaronfranke]

@reduz The tracker for items on the 3.1 milestone is https://github.com/godotengine/godot/milestone/7

[reduz]

Sorry, out of time for 3.1 to create a workaround, kicking again.

[Houkime]

Probably it needs to be at least documented in RigidBody2D class description while workaround is in progress?
It took me a little while to decide that it is this issue that is screwing everything up.

[t-karcher]

I fully agree with @Houkime : A hint in the class description would have saved me almost an hour of tearing my hair out trying to figure out what's wrong with my code.

[Calinou]

apparently this problem still exists in 3d in version 4a3?? is this on the to do list??

pouleyKetchoupp is no longer available to work on the physics engine, so I can't guarantee this limitation will be lifted for 4.0. We have very few contributors who are knowledgeable with physics and have time to submit contributions to the existing physics engine implementations.

[Okxa]

One update on this issue; it seems that on godot 3.4.2-stable the uniform scaling (like I posted on this thread earlier) works when using bullet, but not on godot physics.

(That came up when I tried to switch to godot physics for #29392 / #34596, because #56801 has not been merged.)

[hmans]

Just a quick ping to find out if anything has happened in the meantime. In 4.0, apparently Bullet is no longer available, only GodotPhysics3D. Scaling a scene that contains a RigidBody3D (and probably also its 2D equivalent) still yields warnings & scaling resets at scene start.

I understand this is an Open Source project and I could just take the source and fix this myself, but this is outside of my abilities. I also understand that features are usually added/fixed by people who need them, so please don't misunderstand my comment here as me demanding anything. I just can't imagine that I'm the only person on the planet who'd like to take a scene prefab and spawn smaller and larger versions of it?

(As a reminder, I am very specifically not looking for being able to change the scale at runtime; just at spawn time. And uniform scale only would be perfectly fine.)

[akien-mga]

@hmans You can work it around fairly easily by changing the size of the collision shape, instead of scaling the RigidBody.

Here's a quick example in 2D:

You'd scale the parent node, whose script takes care of setting the size of the collision shape and propagating the scale to the sprite. The RigidBody itself is not scaled and works fine.

[hmans]

Thanks @akien-mga, but in that example the RigidBody node will now simulate (and move) independently from its parent node, correct? So this isn't of much use as a reusable prefab scene.

I remember adding code to a Rigidbody node (the last time I actually tried building a physics game with Godot :b) that would apply the Rigidbody's scale to its children like you're doing, and then reset the Rigidbody's own scale back to 1/1/1.

Also consider that this can be a little more complex than just the children's scale. Colliders might be offset (with their origin not at 0/0/0); this would also need to be scaled accordingly.

(It would be immensely useful here if colliders didn't need to be parented directly to their rigidbodies. Then we could have an intermediate node between the two and just scale that one.)

I'm hoping for a future version where hacks like these are no longer required.

• It's trivial in Unity
• It's trivial in Unreal
• It should be trivial in Godot

(Don't get me wrong, I fully understand that these engines also just rescale collision radii/polygons/etc. — I'm just making an argument for Godot abstracting this away so you can have a small ball and a large ball from the same prefab and not go hunting for hacks like the one above.)

I'll check again next year :-)

[hmans]

Woohoo:

Screen.Recording.2023-02-11.at.13.37.53.mov

As a workaround for this issue, I've created a new class called ScalingRigidBody3D in Godot 4.0 (feedback welcome):

@tool
class_name ScalingRigidBody3D
extends RigidBody3D

var _size := 1.0

@export var size : float:
	get: return _size

	set(v):
		_size = v
		_apply_size()

func _ready():
	_apply_size()

func _apply_size():
	for child in get_children():
		if child is CollisionShape3D:
			child.scale.x = size
			child.scale.y = size
			child.scale.z = size

This can probably be improved further.

My personal wish for Godot's (3D) physics would be to

• have the built-in RigidBody3D class apply a similar logic, but out of the box (for example, it could, in _ready(), examine its world scale, set its own scale back to 1/1/1, and scale its children accordingly. Doing this in _ready() should be enough since scaling works fine during the editing experience.)
• remove the editor warning that appear when you scale rigidbodies

Baby steps, but we'll get there :)

Update!

Improved version of the above class — doesn't use a new property, but just applies its own scale to its children as described in the notes above:

class_name ScalingRigidBody3D
extends RigidBody3D

func _ready():
	_apply_scale()

func _apply_scale():
	# apply my own scale to my children
	for child in get_children():
		if child is Node3D:
			child.scale *= scale

	# reset my own scale
	scale = Vector3.ONE

• Probably has a bunch of edge cases. Most importantly, it assumes that there's no parent node applying additional scaling (but this could probably be fixed trivially.)
• The editor experience is fine (you can scale rigidbody nodes and see the results), but you'll still get the annoying warning triangle. I wish there was an editor option to disable them. But more than that, I wish for this type of logic to eventually end up living in the RigidBody3D class itself. ;)

Update 2023-03-07:

I've polished the code, gave it some upgrades, and packaged it into a Godot Plugin. Please see this comment for details.

[koekhaos]

@hmans New to Godot and going through the tutorials wanted to try to make the 2d balls smaller and found this issue. Would your script work somehow for 2d too if just changing a few calls inside and changing to vector2? Thanks!

[hmans]

@hmans New to Godot and going through the tutorials wanted to try to make the 2d balls smaller and found this issue. Would your script work somehow for 2d too if just changing a few calls inside and changing to vector2? Thanks!

Yup, that should work!

If there's interest, I could wrap this into a plugin and publish it in the Asset Library (but probably for 4.0+ only.)

[koekhaos]

That could be super useful as a lot of people seem to want this but doesn't seem to be in the works anytime soon as it looks like the milestone is set to 4.1 now to fix/implement.

[hmans]

Hi and good morning to everyone following this issue! I've packaged my glue code into a Godot 4.0 Plugin that you can add to your project to work around this issue:

Godot RigidBody Auto Scaler 🎉

It's "fire and forget"; just add it to your project and it'll fix things up automatically. I've also given it a couple of upgrades: it now respects parent scale, also fixes child positions, and works for both 2D and 3D.

While the Asset Library listing submission is still pending, you can find it here:

https://github.com/hmans/Godot-RigidBody-Auto-Scaler

Feedback welcome! (But preferably outside of this issue thread. The plugin README is listing a bunch of ways you can get in touch with me!)

[Okxa]

Another problematic thing when scaling rigidbodies with the workaround (eg. RigidBody is at scale 1 and CollisionShape & mesh are at your desired scale) is that automatically calculated inertia does not seem to scale.

If you use PhysicsServer3D.body_get_direct_state(get_rid()).inverse_inertia.inverse() to check inertia, it is the same regardless of the child objects scale. This makes objects fall somewhat weirdly looking.

If I set the scale manually to something like calculated_inertia * scale it looks slightly better. (For example if calculated inertia is about (15000,7000,15000) on each xyz axis, and scale is 0.2, it's about (3000,1400,3000) respectively)

(However if I set the RigidBody3D mass to 1000, and the inertia in the editor for each axis, the model flies downwards through the floor, as if it had massive gravity. If I only set to x & z axis, it does not go through floor. When using the above function to check inertia, it reports the value set in editor for the x/z axis, and for z axis it's the autocalculated value.)

EDIT: As a workaround, it is possible to scale the inertia with script (at runtime), where ever you just have access to PhysicsDirectBodyState3D, like _integrate_forces() (or by getting it with PhysicsServer3D.body_get_direct_state(get_node(".").get_rid())). Using _integrate_forces() or _physics_process() is usefull as inverse_inertia is not set (inf) at _start():

var has_set_inertia = false

func _integrate_forces(state):
    if !has_set_inertia:
        var inertia_actual = state.inverse_inertia.inverse()
        if !is_inf(inertia_actual.x):
            # get scale from child collider node, assuming you have already applied scale with the workaround
            self.inertia = inertia_actual * collider.scale
            has_set_inertia = true

[hmans]

Another problematic thing when scaling rigidbodies with the workaround (eg. RigidBody is at scale 1 and CollisionShape & mesh are at your desired scale) is that automatically calculated inertia does not seem to scale.

If you use PhysicsServer3D.body_get_direct_state(get_rid()).inverse_inertia.inverse() to check inertia, it is the same regardless of the child objects scale. This makes objects fall somewhat weirdly looking.

Good point! I'll look into this. Thanks!

[Okxa]

Update: Using Godot Jolt physics engine, rigidbody scaling gets slightly better. (Godot Jolt is consired as physics engine, see: godotengine/godot-proposals#7308)

• Rigidbody children still need to be scaled instead of rigidbody itself (ie with hmans addon)
• It seems Rigidbody inertia is automatically calculated! for example:

var has_print_inertia = false
func _integrate_forces(state):
    if !has_print_inertia && self.inertia == Vector3.ZERO:
        var inertia_actual = state.inverse_inertia.inverse()
        if !is_inf(inertia_actual.x):
            print(name, inertia_actual)
            has_print_inertia = true

outputs:

prop_physics10(0.031431, 0.031431, 0.003251)
prop_physics11(0.031437, 0.031437, 0.003251)

The prop_physics are sized the same, but with this difference:

• prop_physics10 has a CollisionShape scaled to 2 (with a ConvexPolygonShape3D exported from blender after scaling to 0.01 -> apply scale)
• prop_physics11 has the same shape, but exported without applying scale (== 100x bigger when imported to godot), and then scaled in godot to 0.02

Also tested with godot physics and expectedly above function printed different inertia for the rigidbodies.

[jitspoe]

Just wanted to add to this, as I think it's the same/similar issue: It seems the rigid bodies will attempt to invert the scaling when re-parented to something of a different scale.

When I was working on the Godot plushy for KOOK, I wanted to have the arms and legs flop around, so I had joints and rigid bodies for them. When I pick rigid bodies up, they would get reparented to a bone on the player. The first person player is actually much smaller than everything else to avoid clipping through walls, so the objects picked up got scaled down (and there's an additional scale factor as well, just to fudge things so they look right, like 0.8x). The pinned rigid bodies, which are a child of the plushie would actually get scaled UP when everything else got scaled down, so they'd be sitting at > 1.0. When I dropped the object and changed the parent back to the world, they'd still be scaled larger (possibly because it was a non-uniform scale, as stuff in first person is actually squished as well).

Here's a clip from the dev stream where this happened. The white cube is a mesh that's a child of the RigidBody3D, for visual feedback: https://clips.twitch.tv/InspiringFrozenDotterelUWot-XoUI1ECrtU8-isdX

[hmans]

Just wanted to add that current GodotJolt stable seems to support this out of the box. It even seems to support non-uniform scaling. That's pretty cool!

Godot 4.2 is still giving me the little exclamation mark warning that I'm doing something that I'm not supposed to be doing, but it looks like it can be safely ignored.

[Okxa]

Just wanted to add that current GodotJolt stable seems to support this out of the box. It even seems to support non-uniform scaling. That's pretty cool!

Can confirm, here is a clip using Godot 4.2.2 and godot-jolt stable release 0.12. Each RigidBody is scaled just by their transform. IIRC this was not working on 0.11 (which was version I previously used), but not sure.

2024-07-14.10-41-56.mp4

The inertia also seems to be still scaled correctly, as was when using previous godot jolt version.