godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.12k stars 69 forks source link

Add motor/target_rotation property to Joint Nodes #3891

Open 19PHOBOSS98 opened 2 years ago

19PHOBOSS98 commented 2 years ago

Describe the project you are working on

I'm planning to work on a building game that involves animating a rigid body build using joints like an active ragdoll except it's a house with legs that acts like a dog...

The point is, I need to animate joints by copying object rotations from a keyframe animation like how this guy does with Unity's "targetRotation" property for configurable joints:

https://www.youtube.com/watch?v=nmN1TyEd7lE

But as of writing this, the closest thing we have is the "motor/target_velocity" property.

Describe the problem or limitation you are having in your project

Without natively having a "motor/target_rotation" property, I am forced to calculate the right torque to maintain a target rotation and dodge physics limitations on top of having to calculate the right quaternions to properly determine the correct rotation.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

By having such a property, it would be much easier to control joints in general. This makes it easier for me to animate composite rigidbodies and if possible even skeleton bone ragdolls using keyframe animations and even IK if necessary.

here's an example tutorial of how I would go about it: https://www.youtube.com/watch?v=nmN1TyEd7lE

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Applied to the appropriate joint nodes such as the Generic6DOF joint, "linearmotor(x,y,z)/target_rotation" would be added as a property.

Based on how Unity does it, targetRotation requires quaternions although it might be possible to add a way to use regular axis rotation angles instead.

Moreover, as I've heard using Unity's targetRotation property is quite confusing as stated in this guide:

https://wirewhiz.com/the-complete-guide-to-unitys-configurable-joints/

"...Now setting target rotation is really confusing as it doesn’t use global or local coordinates even if your joint is set to use world space so you have to calculate yourself and store the original rotation of the joint..."

The author even pointed out that they use an extension to properly calculate local and world rotations to use on the property: https://gist.github.com/mstevenson/4958837

If possible, it would be beneficial to calculate local and world coordinates internally as well.

I found this Devlog by krogank9 that made a partial addon for PinJoint2D that calculates torque to maintain a target rotation however, he also stated some flaws in applying dampening in his implementation. Devlog: https://www.youtube.com/watch?v=CipnAZHO3VE&t=53s Addon: https://github.com/krogank9/godot_stuff/tree/master/addons/PinSpringJoint2D

If possible, this property should also be available as a sub property to the physicalBone node's joint property. However, I do understand that this should be discussed with the people working on the IK system such as Andrae Catania and Noah Beard for Godot 4 but in any case it should be possible to implement this to work on Godot 3.x.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, being able to set target rotations on configurable joints has been a standard in Unity and other game engines. From active ragdolls to animated physics based vehicles and props it is essential to be able to control and rotate joints.

Although there is already prior work of addons, albeit incomplete, implementing world space to local space rotation calculations and the proper torque calculations, let alone coding the property to every rotating joint node both 2D and 3D would take more than a few lines of code.

Is there a reason why this should be core and not an add-on in the asset library?

In addition to the last paragraph, it is more efficient to do the physics and rotation calculations natively instead of having it as an add-on.

This is important for almost every physics based game out there. That's why Unity's Configurable Joints comes with the "targetRotation" property. The down side is that they still need an addon to make it easier to use... we can improve upon that through Godot.

Moreover, this property should be in core instead as joint nodes are already in core.

Calinou commented 2 years ago

@ismailgamedev Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

ismailgamedev commented 2 years ago

Ok

4 Şub 2022 Cum 5:06 PM tarihinde Hugo Locurcio @.***> şunu yazdı:

@ismailgamedev https://github.com/ismailgamedev Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

— Reply to this email directly, view it on GitHub https://github.com/godotengine/godot-proposals/issues/3891#issuecomment-1030127445, or unsubscribe https://github.com/notifications/unsubscribe-auth/APONQ3D4JS6FPC3GSOUUULLUZP2SDANCNFSM5NC3S2BQ . You are receiving this because you were mentioned.Message ID: @.***>

19PHOBOSS98 commented 2 years ago

made a prototype, still needs work tho. Also, can someone help me figure out where I should stick my joint physics calculations in Godot? I can't seem to find the right cpp file for it on 3.4.x. Tried searching "Angular Spring" and "6DOF" but all I got were just setters and getters functions :(

19PHOBOSS98 commented 2 years ago

Right, sorry, forgot to actually drop the link. For anyone who's interested, here's my prototype: https://github.com/19PHOBOSS98/GODOT--Joint_Target_Orientation

jitspoe commented 2 months ago

I was actually just looking for something like this. There's a target velocity with the motor, but not a target angle.

It would also be great to implement this for the physical bones as well. Not sure if that logic is shared, but that's the type of thing that can be used for powered ragdolls (though it might be simpler from a user standpoint to use the animations to drive this). Those allow for much more dynamic death animations and other fun behaviors.