Godot: 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):
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 https://github.com/godotengine/godot/issues/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.

[nathanfranke]

This issue is very prevalent with HeightMapShape ... Since HeightMapShape does not have any options for cell size and scaling shapes is unsupported, it is impossible to have a heightmap that isn't 1x1 cells. I hope this can be fixed in 3.2 or at least high priority in 4.0...

[bluenote10]

I'd love to see this included in 3.2 as well (a major showstopper for the project I'm working on...). Is there actually any possible work-around in 3.1?

• @ivanskodje This trick doesn't seem to work in 3.1 -- it scales only visible subnodes, but not the shape child, i.e., the collision bounds don't match with the visuals in my case.
• Setting the mode to "Kinematic" has different behavior -- not really a work-around.
• The answers here also don't seem to be applicable in 3.1.

[ThakeeNathees]

I was trying to fix this bug, but when the scale is not (1, 1) after a physics frame the scale is changing by a small value ( 0.00001 ) because of the physics process which cause the body to flicker.

and the transform was orthonormalized intentionally which cause the scale to (1, 1).
https://github.com/godotengine/godot/blob/bd61281a5f515065b05be008dd3d6b73a03f5a7c/servers/physics_2d/body_2d_sw.cpp#L293
I think the scale must be (1, 1) to make the physics work properly and we have to prevent the user from scaling it.

[hmans]

Any new insights on this? I'm seeing the comments on this "simply not being possible", but it pretty much makes it impossible for me to build the game I want to build with Godot (while it's not a problem in pretty much any other engine, including one I hacked together myself using Box2D).

If performance is a concern (since this would probably involve combine parent transforms and then rebuilding the physics shapes), only allowing this in _ready() but not allowing it afterwards would be a great middle ground.

Are there any recommended workarounds (other than creating/adapting the collision polygon programmatically, which I suppose would work)?

[nathanfranke]

Someone could make a collision shape scale function for 3.2. I'm not sure what the situation is for 4.0 right now

[olson-sean-k]

Just wanted to bump this issue. I encountered this in my very first learning project and was confused about the transform (the _scale_) of a Node2D not being applied to its children (in this case, a RigidBody2D node). This was especially baffling, because the editor rendered what I expected but playing the scene did not. I see now that this is mentioned in the documentation of RigidBody2D, but I missed this.

Are there any thoughts, designs, or advice about how to create instanced scalable nodes that contain a RigidBody2D? Is it possible for the scene topology below to be scaled, or is this considered an antipattern? If this topology is not ideal, what is a more ideal topology?

[aaronfranke]

Are there any thoughts, designs, or advice about how to create instanced scalable nodes that contain a RigidBody2D?

The only supported option is to scale the child nodes.

[olson-sean-k]

The only supported option is to scale the child nodes.

Gotcha. Thanks for the help.

35614 should help alleviate this, but current quirks prevent merging it.

Awesome, that looks very helpful. 😄

I can see how applying (arbitrary) parent transforms to physics bodies could be tricky. Hopefully an intuitive solution can be found.