godot: RigidBody freezes in rotating Spatial

I tested it with Godot 4 and I have some interesting news. In the beginning it’s a bit laggy because my laptop is complete garbage and it seems to have problems with Vulkan in general.

https://user-images.githubusercontent.com/18660100/105396264-f8a16380-5c1f-11eb-9c8a-d59cd7c8c636.mp4

Nonetheless it seems to work as expected in the first place. (The outer smaller sphere is just to visualize the rotation, because Godot crashes on my machine when I try to apply a shader)

The Capsule is a static rigid body and is not a child of the rotating Node3D.

Godot: 4.0.dev Commit: a9b151c664d00d353640e6b2c52d026347230269 Project: godot_4_test_proj.zip

Quick hack to show the kind of procedure I had in mind.

Script attached to RigidBody:

extends RigidBody

var last_state:PhysicsDirectBodyState
func _integrate_forces(state:PhysicsDirectBodyState):
	last_state = state

func _physics_process(delta):
	if (!last_state):
		return
	
	translate(last_state.linear_velocity * delta)
	rotation += last_state.angular_velocity * delta

This already results in (rotation speed increased):

https://user-images.githubusercontent.com/18660100/104953543-e2e53180-59c6-11eb-943a-766cad262c0e.mp4

Obviously buggy, but one can see where this is going. I would expect this to work way better, if this kind of “algorithm” is used in the core engine.

But ok, I will figure it out eventually.

I think this should go into docs repo with example. Even though circular motion is only a few lines of code, lots of people seem to not be able to grasp physics involved. You can approach it with proper simulation (gravity, centrifugal force, etc.) or just converting velocity into force and torque.

First you need to handle distance to rotation center, i.e. apply radial force in direction out or into your circle. Second, your remaining vector is perpendicular to radial vector. Just add it to the above. For torque you check angle between previous force vector and current one and apply torque if it is more than some small number to correct rotation.

On Mon, Jan 18, 2021 at 11:21 PM Camille Mohr-Daurat < notifications@github.com> wrote:

Reopened #45268 https://github.com/godotengine/godot/issues/45268.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/45268#event-4219720121, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABPUY7HAXNYSOVFVXEGPDS2SJ6HANCNFSM4WGQERAA .

Is the issue (Rigidbody not inheriting Spatial rotation) made clear in docs? I don’t think it is, as I had an extremely similar issue with carting around Rigidbody items in my FPS tech demo…

Ok, makes sense. Let’s make sure the documentation states very clearly how rigid body transformation works.

I could do that, but it would somewhat question the whole use of the scene tree concept, if child nodes can unexpectedly behave different, when they are children of a spatial.

I do not expect the children do be affected by the parents movement on a physics based level. E.g. forget the rotation for a moment. Imagine the following scene:

-WorldNode
  |- ShakingSpatial
    |- RigidBody

When I now would shake the ShakingSpatial, I would not expect the RigidBody to build up momentum relative to the WorldNode and fly around. I would expect the RigidBody to simply follow the translation of the ShakingSpatial and behave physically correct within and relative to the the ShakingSpatial. The ShakingSpatial would be, in some way, its own inertial frame of reference for all its children.

Back to the rotation example of this issue: I would not expect the box to build up centrifugal force. The box should simply follow the translation like any other static object plus the translation caused by collisions from within the RotatingSpatial.

For further clarification of my problem: Thanks for your advice so far, but I am less in search of an alternative solution. “Calculate it yourself” is almost every time a solution. At this point my question is more like if this is officially expected behavior or not?