godot
godot copied to clipboard
godotengine
RigidBody and RigidBody2D ignore scaling on runtime
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:
- Add a RigidBody2D, with a Sprite to actually see its size
- Scale it down or up
- 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.
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
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))
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.
there should be a tracker with all these things, so i can work and remember everything after 3.0
@reduz The tracker for items on the 3.1 milestone is https://github.com/godotengine/godot/milestone/7
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.
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.
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...
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.
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.
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)?
Someone could make a collision shape scale function for 3.2. I'm not sure what the situation is for 4.0 right now
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?
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.
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.
Using 3D, and I am not sure if this is correct, but it seems that it mostly works when scaling uniformly (the RigidBody:ies are instanced with MeshInstance and CollisionShape as children):
The other rigidbody is scaled [0.2, 0.2, 0.2] while the longer is [0.2, 0.4, 0.2]. Of course if it's not scaled uniformly, it results in a weird change of scale when the rigidbody rotates. (It seems to work OK if the scale is uniform.)
In any case I think this is something godot needs. For example this would be usefull when working with instanced models, but scale each instance separately.
https://github.com/godotengine/godot/pull/50637 may allow for using non-uniformly scaled PhysicsBodies, but right now, only uniform scaling is supported.
#50637 may allow for using non-uniformly scaled PhysicsBodies, but right now, only uniform scaling is supported.
I see, atleast uniform scaling is working.
If it is truly supported (uniformly), should the warning message be adjusted (if it's not already) to reflect that? Or is the scaling still somewhat unsupported feature?
I'm playing around with the current 4.0 master, and was disappointed to find out that it's still not possible to scale a RigidBody2D (I haven't tried its 3D counterpart):
As I've raised before, this makes certain use cases (like spawning asteroids of slightly randomized sizes) cumbersome to implement, as detailed in this tweet of mine and the thread following it.
I've been wondering about this issue for a long time, feeling that I must be missing something obvious, but so far I have not managed to find a solution, or at least an answer to why this is even a thing (consider that no other game engine I've used has had issues like this.)
Why does the physics engine even want to scale the body at run-time?
This is definitely one of the topics I'd like to improve for 4.0, it's just nobody had time to work on it yet.
What's needed is to check the current state for different cases, make some changes in the engine to handle more of them and adjust the warnings to be more accurate for the remaining cases.
I'll try to spend some time on this topic once the general API changes and major bug fixing are done for 4.0, but any contributor is welcome to give it a try.
FWIW, and I'm saying this as someone who knows absolutely zero about Godot's internals, I think what might also work fine is to leave RigidBody and RigidBody2D as is, but allow us to have an intermediary node between it and the collision shapes, and allow that intermediary node to apply scaling to its contained nodes (collision shapes included). (Related: @aaronfranke's proposal here: https://github.com/godotengine/godot-proposals/issues/535)
Good point! It could be a way to solve the problem in case there's any technical limitation to allow scaling the rigid body itself.
Copying a comment by @pouleyKetchoupp on the current state of RigidBody scaling (from #35614), at least as of Feb 2021:
The current state with scaling physics objects is: Non-uniform scale: This is not supported for either bodies or collision shapes and there's no plan to support it in the future. Uniform scale: This is supported for collision shapes, not for bodies of any type. This limitation will be lifted in the future.
Parent node scaling: This is also not supported for bodies. Actually, it would be best to test global transforms rather than local ones in order to catch parent node scaling. Cases where the rigid body scale cancels the parent scale seem to work fine, so testing global transforms should be enough. edit: For collision shapes, non-uniform scale would be tested on the local transform.
apparently this problem still exists in 3d in version 4a3?? is this on the to do list??
EDIT: you CAN resize STATIC bodies and adjust size, so this wont effect levels comprised of static colliders.
for DYNAMIC rigid bodies you have to manually pair up meshes with hitboxes and resize them both every single time. this makes reusing dynamic rigid bodies limited to one size. i /think/ you can bypass this limitation with scripts?
i dont know if this isnt already planned, but this IS a problem. i know yall have your work cut out for you, but please consider it for the todo list. EDIT i understand this may be outside of your control. i'll try not to complain to much about it. ;)
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.
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 https://github.com/godotengine/godot/pull/56801 has not been merged.)