Hey there! Do you have an MRP & test builds as well so we can test this in action?

Hey there! Do you have an MRP & test builds as well so we can test this in action?

Hey, please give me some advice what this exactly is (MRP) and how i can provide that data?

Hey, please give me some advice what this exactly is (MRP) and how i can provide that data?

It's a small, minimal project which will allow us to test your features. You can just make a .zip & provide it along with your Godot build.

Hey, please give me some advice what this exactly is (MRP) and how i can provide that data?

It's a small, minimal project which will allow us to test your features. You can just make a .zip & provide it along with your Godot build.

Allright, i will create some. What build should i integrate, is a windows build .exe file enough? All in one zip file i guess?

Thanks for opening a pull request!

Feature pull requests should be associated to a feature proposal to justify the need for implementing the feature in Godot core. Please open a proposal on the Godot proposals repository (and link to this pull request in the proposal's body).

Thanks, the reference is already added.

Thank you realized my message had a typo it should have said to link to the proposal in the PR, don't know how that got in threre!

Allright, i will create some. What build should i integrate, is a windows build .exe file enough? All in one zip file i guess?

Just provide the MRP instead!

Please don't upload any builds, they can be gotten from the CI build or built manually, people shouldn't run unknown executables uploaded to GitHub

Please don't upload any builds, they can be gotten from the CI build or built manually, people shouldn't run unknown executables uploaded to GitHub

How can I get them from the CI?

They're listed as artifacts, see here

Thx for all feedback. MRP is added -> physics3d_joints_mrp.zip

This is the showcase of this PR. It looks nice :) (Sorry for the lag, may be because I have many apps open)

I've looked into the 2 failing checks, but i am not quite sure about both:

https://github.com/godotengine/godot/actions/runs/18650008833/job/53166436589?pr=111842
This jobs seems to fail because the sorting of things in the xml, should i implement the proposed changes from this Run?

https://github.com/godotengine/godot/actions/runs/18650008833/job/53166436573?pr=111842
Here i am out of knowledge what can cause this issues. Any advice? Is it maybe because of float vs. real_t in header and implementation? Why only linux with "doubles" fails on this?

The methods should be sorted yes, please see here

The second issue is that you are not matching the return types, they're changed from float to real_t only in the header

My 2c in the real_t discussion: I think real_t should only be used for things that can potentially become very large (e.g. positions, velocities). Forces/torques should never become big enough for float to be too inaccurate and since float is cheaper than double I would go for float. Also, Jolt returns the results in float, so you're not getting better precision by converting to real_t anyway.

Allright, i've changed it that way.

Ups, i'm not sure if i messed up this PR. I accidentally synced master into this PR. May this be a problem?

Didn't cause any problems this time it seems but prefer to rebase instead, you can remove that merge commit using:

git reset --hard HEAD~
git push -f

Make sure to pull your branch to your local version first to make sure you drop the merge commit though

@AThousandShips Thanks, seems it worked.

Is there any possibility that this get merged? The longer it takes, the lower the possibility that this can be merged without problems, i guess?

Right now we're in feature freeze for 4.6 so new features and enhancements won't be merged until after that has been released (scheduled for January)

Hey, I am unsure if this should be a new issue or what, but the error

Condition "joint->get_type() != JOINT_TYPE_PIN" is true. Returning: 0.0 <C++ Source> modules\jolt_physics\jolt_physics_server_3d.cpp:1776 @ pin_joint_get_applied_force()

is being given when node_a and node_b is empty while trying to get applied forces.
This is pretty simple to work around, but in my opinion it shouldn't be giving errors for this.
Loving the commit so far though 😘

Hey, I am unsure if this should be a new issue or what, but the error

Condition "joint->get_type() != JOINT_TYPE_PIN" is true. Returning: 0.0 <C++ Source> modules\jolt_physics\jolt_physics_server_3d.cpp:1776 @ pin_joint_get_applied_force()

is being given when node_a and node_b is empty while trying to get applied forces. This is pretty simple to work around, but in my opinion it shouldn't be giving errors for this. Loving the commit so far though 😘

As far as i understand the jolt things, this is how it is supposed to throw errors when some data is missing. The code should run properly however, it just return 0.0 and log that error. This errors appear in other jolt functions as well. I've implemented the error checks the same way.

Would it be possible to change the functions to return a vector3 version of the force/torque, instead of the magnitude? I need it to make a breakable joint that only breaks in specific direction.

Would it be possible to change the functions to return a vector3 version of the force/torque, instead of the magnitude? I need it to make a breakable joint that only breaks in specific direction.

Not with Jolt. Jolt exposes this as it is now. It's not a problem of this PR, it exposes all this as it is originally from the physics engine.

You may have to go to the jolt library to suggest it there, but i don't think that this is a thing that can be changed without rewriting the whole engine.

It looks like jolt already exposed it. It is just that godot is the one that exposed it as a magnetude:
https://github.com/jrouwe/JoltPhysics/blob/83eea75749660afb8c654541274079ff2bbb11b3/Jolt/Physics/Constraints/HingeConstraint.h#L143
https://github.com/godotengine/godot/blob/2d53a62898a65ba635efd554b101e033070c784c/modules/jolt_physics/joints/jolt_pin_joint_3d.cpp#L134C21-L134C43

If the method is not used anywhere, should we just change it to return the vector3 force instead? 🤔

It looks like jolt already exposed it. It is just that godot is the one that exposed it as a magnetude: https://github.com/jrouwe/JoltPhysics/blob/83eea75749660afb8c654541274079ff2bbb11b3/Jolt/Physics/Constraints/HingeConstraint.h#L143 https://github.com/godotengine/godot/blob/2d53a62898a65ba635efd554b101e033070c784c/modules/jolt_physics/joints/jolt_pin_joint_3d.cpp#L134C21-L134C43

If the method is not used anywhere, should we just change it to return the vector3 force instead? 🤔

Ah, i see, you are right. Interesting. Well, that shifts the problem to godot, but still not for this PR. To keep it on-topic, you should create a new Feature request about that.

If I remember correctly: The reason that only the magnitude was exposed is that these quantities are in constraint space and there currently isn't a way to know what that is in Godot.

If I remember correctly: The reason that only the magnitude was exposed is that these quantities are in constraint space and there currently isn't a way to know what that is in Godot.

Can it be returned in world space instead?

Can it be returned in world space instead?

You can, but it gives you a dilemma:

• Do you return it in world space of the current joint position/orientation (which means after the joint has moved, joints are first evaluated and then the simulation is stepped)
• Do you return it in world space when the joint was evaluated (which means you cannot go back to local space as the joint has moved)

I will close this PR at the end of may 2026. My spare time shifted and a cannot provide any more support for this PR.
I guess in the current state it's even not mergable because to much time without any action has been passed and main code has been drifted away.

Hope someone can bring life to this or close it right away, i'm fine with both.

Greetz

I don't think there's any issues with merging this currently, at least there aren't any merge conflicts, and it's unlikely that it's become so out of date in so short a time

This is unlikely to be merged before the end of the month as 4.7 is likely to release no earlier than the end of the month, though this could get in early 4.8 if it is ready

Would you combine all the commits into one?

EDIT: also, I think the generic 6dof methods should be placed just above _configure_joint() so it matches all the other method orderings. right now it is between get_param_z() and set_flag_z() methods.