Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There's no way to create joints (constraints) in the current API. #111

Open
bryanedds opened this issue Dec 28, 2024 · 7 comments
Open

There's no way to create joints (constraints) in the current API. #111

bryanedds opened this issue Dec 28, 2024 · 7 comments

Comments

@bryanedds
Copy link

bryanedds commented Dec 28, 2024

Maybe I'm missing something obvious, but I don't see a way to actually create any instances of a joint like DistanceConstraint or DistanceConstraintSettings. All of the joint constructors are non-public and inaccessible.

Assuming this can't get fixed very soon in the wrapper, can someone advise me on how to perhaps create one via reflection? I just need to know how to pass the required nint handle into the ctor when calling the constructor's invoke.

Thanks!

@amerkoleci
Copy link
Owner

Hi,
Thanks for bringing attention to those points, I'll fix them soon, hopefully tomorrow or within some days.

Thanks!

@bryanedds
Copy link
Author

Awesome!

I was thinking perhaps it might just have been a minor oversight :)

Thank you kindly!

@amerkoleci
Copy link
Owner

Hi,
Constraints has been improved a lot, grab the new 2.12.1 and tell me if there is something missing.

Cheers,
Amer

@bryanedds
Copy link
Author

Looks like I can access the constructors fine, now! However, I'm noticing that there might not be any way to access BodyLockMultiRead or BodyLockMultiWrite when creating constraints -

                    | AngleJoint hingeJoint ->
                        let constraintSettings = new HingeConstraintSettings ()
                        constraintSettings.Point1 <- hingeJoint.Anchor
                        constraintSettings.Point2 <- hingeJoint.Anchor2
                        let mutable bodyLockWrite = Unchecked.defaultof<_>
                        let mutable body2LockWrite = Unchecked.defaultof<_>
                        try physicsEngine.PhysicsContext.BodyLockInterface.LockWrite (&bodyID, &bodyLockWrite) // NOTE: assuming that jolt needs write capabilities for these.
                            physicsEngine.PhysicsContext.BodyLockInterface.LockWrite (&body2ID, &body2LockWrite) // TODO: P0: send support request to JoltPhysicsSharp maintainer to expose BodyLockMultiWrite so that we don't get a deadlock here if accessing from another thread!
                            let body = bodyLockWrite.Body
                            let body2 = body2LockWrite.Body
                            let constrain = constraintSettings.CreateConstraint (&body, &body2)
                            constrain.Enabled <- bodyJointProperties.BodyJointEnabled
                            Some constrain
                        finally
                            physicsEngine.PhysicsContext.BodyLockInterface.UnlockWrite &bodyLockWrite
                            physicsEngine.PhysicsContext.BodyLockInterface.UnlockWrite &body2LockWrite

This code could cause a deadlock according to https://github.com/jrouwe/JoltPhysics/blob/master/Docs/Architecture.md#multithreaded-access -

You cannot use BodyLockRead to lock multiple bodies (if two threads lock the same bodies in opposite order you'll get a deadlock). Use [BodyLockMultiRead](@ref BodyLockMultiRead) or [BodyLockMultiWrite](@ref BodyLockMultiWrite) to lock them in a consistent order.

I'm guessing the issue is that the BodyLockMultiRead and BodyLockMultiWrite types haven't been exposed by the wrapper yet?

@amerkoleci
Copy link
Owner

Hi,
I've just added multi lock read/write support, grab the 2.12.2 and tell me if it works?

Thanks

@bryanedds
Copy link
Author

I've integrated the API and gotten everything to compile and work without actually exercising the deadlock prevention behavior. The actual testing of the additional MT semantics of multi-locking behavior won't taken place on my end since I just needed the construct to make sure I don't get deadlocking in some speculative future (IE, as a sanitation best practice).

Since I've not done the deep testing you might be wanting, I'm leaving closing the issue to your discretion.

@amerkoleci
Copy link
Owner

Hi,
Lets leave it open, when you'll be able to do deep testing reach out.

Thanks.
Amer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants