Posts: 15
Threads: 3
Joined: Jul 2023
Reputation:
0
20-07-2023, 05:28 PM
(This post was last modified: 20-07-2023, 05:52 PM by astro.domine.)
Hello,
Trying to figure out what I'm doing wrong, or if this is an actual bug.
When I attach a rigidbody to the end of a rod dynamically with constraint orientation, it behaves erratically, warping the rod and pushing it away. It's like they're colliding, but the attachment isn't touching the particles, and I have tried disabling collisions. This happens with sphere & cube colliders (haven't tested others).
The weird thing is, rotating the attachment somehow fixes the problem. E.g., if I set the Y rotation of the attached sphere to 40, it works as expected. Something about being at a 90 degree angle causes problems.
This doesn't happen with static attachments, or if Pin constraints are disabled. I have tried many different settings.
Any thoughts? Am I missing something?
https://imgur.com/LTKUQq8
Posts: 6,347
Threads: 24
Joined: Jun 2017
Reputation:
400
Obi Owner:
20-07-2023, 09:45 PM
(This post was last modified: 20-07-2023, 09:46 PM by josemendez.)
Hi there!
I'm unable to reproduce this. There's an included sample scene "SpringRod" uses a dynamic attachment between a rod and a cube with constrained orientation, this seems to work fine regardless of how the cube is rotated. The shape of the collider should not matter, since it's not used for the attachment - only the rigidbody component plays a part in attachment dynamics.
Could you send a repro scene to support(at)virtualmethodstudio.com so that I can take a closer look? thanks!
Posts: 15
Threads: 3
Joined: Jul 2023
Reputation:
0
20-07-2023, 10:32 PM
(This post was last modified: 20-07-2023, 11:23 PM by astro.domine.)
(20-07-2023, 09:45 PM)josemendez Wrote: Could you send a repro scene to support(at)virtualmethodstudio.com so that I can take a closer look? thanks!
Hey Jose, thanks for the quick response!
When I duplicate the rod from the SpringRod scene, or use its blueprint, it works as expected. But if I make a simple straight rod, or use the plectoneme blueprint, it wigs out as described. It's like the rod and attachment are fighting each other.
I sent the repro scene to you.
Posts: 15
Threads: 3
Joined: Jul 2023
Reputation:
0
22-07-2023, 04:53 PM
(This post was last modified: 22-07-2023, 04:55 PM by astro.domine.)
Did you get my repro scene?
Also, while I have you here, I had a couple general questions:
- For a tapered/graduated rod that has segments of varying rigidness, like a fishing pole or antenna, would you suggest using Obi Bones or Unity Configurable Joints?
- To attach a rope to a rod/bone, would you suggest using an Obi Stitcher, or connecting them with an intermediary rigidbody and dynamic attachments? It seems like there would be a simulation advantage to separating the rod & rope into separate solvers, allowing you to optimize the constraint settings for each (the rope might need more distance iterations, while the rod might need more bend iterations, for example); with a Stitcher you can't split them up.
Posts: 6,347
Threads: 24
Joined: Jun 2017
Reputation:
400
Obi Owner:
(22-07-2023, 04:53 PM)astro.domine Wrote: [*]For a tapered/graduated rod that has segments of varying rigidness, like a fishing pole or antenna, would you suggest using Obi Bones or Unity Configurable Joints?
Hi!
Unity's physics engine is velocity based, while Obi is position based and hence, unconditionally stable. I'd suggest using Obi, unless you need to use joints for some other reason.
(22-07-2023, 04:53 PM)astro.domine Wrote: [*]To attach a rope to a rod/bone, would you suggest using an Obi Stitcher, or connecting them with an intermediary rigidbody and dynamic attachments? It seems like there would be a simulation advantage to separating the rod & rope into separate solvers, allowing you to optimize the constraint settings for each (the rope might need more distance iterations, while the rod might need more bend iterations, for example); with a Stitcher you can't split them up.
[/list]
Rods use bend/twist and stretch/shear constraints, while ropes use the simpler distance and bend constraints. You can fine tune constraint settings for each even if using the same solver, which is also cheaper and simpler to set up than using two separate solvers with an intermediate rigidbody.
Posts: 6,347
Threads: 24
Joined: Jun 2017
Reputation:
400
Obi Owner:
24-07-2023, 07:13 AM
(This post was last modified: 24-07-2023, 07:14 AM by josemendez.)
Got a chance to take a look at your sample scene but couldn't reproduce the original issue, so I must be missing something?
One thing I did notice is that your constraint settings are cranked way too high, most are set to +20 iterations and you're using 4 substeps, for a total of 4x20 = 80 iterations per physics step. Your rod has very low resolution so it's unnecessary to spend such a huge budget on it, you can set the amount of iterations to 1 for all constraints. If you want the rod to be more rigid, go into the path editor and set all control point's rotational mass to a larger value (eg 0.1 instead of 0.01) to make it harder for it to bend.
kind regards,
Posts: 15
Threads: 3
Joined: Jul 2023
Reputation:
0
24-07-2023, 04:44 PM
(This post was last modified: 25-07-2023, 05:08 PM by astro.domine.)
(24-07-2023, 07:13 AM)josemendez Wrote: Got a chance to take a look at your sample scene but couldn't reproduce the original issue, so I must be missing something?
Perhaps I have misunderstood how pin constraints with constraint orientation should work? I would expect the rigidbody to be constrained to its initial orientation in relation to the rod.
This is the behavior I get with a new scene, default solver settings, and a default rod blueprint (only with resolution reduced slightly): https://share.getcloudapp.com/mXuGbOpj
Doesn't seem right. I can repro the problem by simply going to the SpringRod scene, replacing its blueprint with the "plectoneme", reassigning the attachments, and setting the load's rotation to zero.
Thank you a ton for the support and advice regarding rods, that's really helpful.
Posts: 15
Threads: 3
Joined: Jul 2023
Reputation:
0
26-07-2023, 05:16 PM
(This post was last modified: 31-07-2023, 02:24 AM by astro.domine.)
One more general question: is there a way to manually set the particle positions of a rod? I.e., only have them at control points, stop them from being automatically repositioned on start.
EDIT: I figured out how to do this. Not sure what was wrong previously.
Posts: 6,347
Threads: 24
Joined: Jun 2017
Reputation:
400
Obi Owner:
31-07-2023, 08:33 AM
(This post was last modified: 31-07-2023, 08:36 AM by josemendez.)
(24-07-2023, 04:44 PM)astro.domine Wrote: Perhaps I have misunderstood how pin constraints with constraint orientation should work? I would expect the rigidbody to be constrained to its initial orientation in relation to the rod.
This is the behavior I get with a new scene, default solver settings, and a default rod blueprint (only with resolution reduced slightly): https://share.getcloudapp.com/mXuGbOpj
Doesn't seem right. I can repro the problem by simply going to the SpringRod scene, replacing its blueprint with the "plectoneme", reassigning the attachments, and setting the load's rotation to zero.
Hi!
Could reproduce this, when very close to zero relative rotation between the attached particle and the attached object, the orientation constraint has a mathematical singularity that causes the object's rotation to be negated.
Will try to fix this for the next update, but it might take a while. Depending on how critical this is for your use case, one simple workaround is to attach the object to the other end of the rod. Since the relative rotation between particle and object in this case is -180º instead of 0º, it should work correctly. Simply offsetting the rotation (as you initially found out, by rotating the object 40º) should also circumvent it.
Thanks for the report!
kind regards,
Posts: 15
Threads: 3
Joined: Jul 2023
Reputation:
0
(31-07-2023, 08:33 AM)josemendez Wrote: Will try to fix this for the next update, but it might take a while.
Thanks so much for investigating the issue. I'll look forward to the next update, but should be able to work around it for now.
|