• 3D

  • Rigidbody does not work properly with joints.

Hi everyone! I'm trying to get the player to throw the ball. I tied the ball using joints. I have already tried with pinjoint and with conetwistjoint. The moment the player presses the throw key, a scene instance is created as in the screenshot above.

My camera was made using two objects. One is responsible for the horizontal axis, and the second for the vertical. ((PlayerCamera)_sm.PlayerCamera).CameraH.GlobalTransform.basis.z; This is how I get the direction of where to throw the ball. This is the horizontal camera forward vector.

Ball.ApplyCentralImpulse(forwardVector * force); Then I apply an impulse to the ball using a forward vector * force (force = 20). Perhaps I'm somehow applying impulse incorrectly? But it seems to me that physics somehow does not work that way. Because if you throw the ball exactly along the Z-axis or along the X-axis, then it flies correctly, but if you do it in between, then physics for some reason breaks...

Here's how it works on video: https://imgur.com/tzjcoIe

No one answered. Apparently this is a little-known problem. I prepared a project where I reproduced this configuration, see, please.

Here is a video demonstration where I multiplied the push force by 5, 10 and 20. https://imgur.com/a/fi0v0V9

It looks like the problem was in the physics engine. I searched for alternative physics engines and found a second default engine. I changed the project engine to GodotPhysics and my problem was resolved. I'm glad I can continue working on the game. More details can be found on the link that I left.

I've always had issues with Godot's physics joint, they often do not operate exactly how I expect. I'm glad you found a solution :smile:

I've been using bullet for a while now.

I the first problem I see is that joints should never be the children of the bodies they control. And in fact you should not ever manipulate a rigid body's transform directly or outside of _physics_process (use apply forces or impulse for example).

You can however connect a kinematic body to a rigid body via a joint and manipulate the kinematic body as you please (within reason again, so the solver does not deal with huge impulses or extreme delta v)

I made the same mistake you did initially.

The reason why it is wrong is because the joint is effecting the position of the body and, as a child of the body, the joint is constantly being moved by the body transform changes. This causes bullet to constantly be disrupted because the joint is being reposition external to its solver. It gets really upset about it.

Break down he problem to a two body example and connect body a and b by a joint that is not the child of either.

The high order bit, is don't manipulate rigid body and their joints transforms bullet will get confused.

Don't arrange rigid bodies or joints in a hierarchy, put them instead in a Spatial node to organize them cleanly

So: Root-Node-For-Physics-Assembly (spatial) body-a body-b ... joint-1 joint-2 ..

or similar

You can even Root (spatial) Blob o things 1 (spatial) bodies and joint children Blob o things 2 (spatial) etc. * joint 1 to blob o things1 sub rigid body and blob 2 sub rigid body..

6 days later

A few more comments: Organizational nodes (like blob-o-things) can be used to place your soon to be added assembly into your world of choice. Just set the blob's global_transform before adding to your scene, then your assembly will be in the right place.

Don't touch the blob's transforms and don't make it a child of anything that moves.

When you need to get rid of your blob, just remove and delete as you see fit.

Reusing the blob may be a bit tough, because the physics constructs may retain something of their past life. I tried to do some scene transition by removing a player assembly, changing the map and simply dropping it in, but ran into problems. It may just be that I had to let a few more frames pass to give bullet/godot time to release resources (alas no real documentation!) but I also solved the problem by traveling my assembly with its kinematic control to the new spawn point.