Feedback Pinholes: new component for ropes

[josemendez]

New component coming to ObiRope 7.0.5: ObiPinhole.

This is something that has been requested quite often: the ability to attach a rope to a point while allowing it to slide/pass trough that point - just like a thread passing trough the eye of a needle.

Pinholes implement that and a lot more: they have full two-way coupling with rigidbodies, they're motorized, and you can even define the friction between the rope and the pinhole. They work for ropes and rods, both open and closed/looped, and fully support rope tearing/cutting. Here's the WIP manual page for them, which contains more details and some use cases:

https://obi.virtualmethodstudio.com/manu...nhole.html

Let me know if you have some feedback, questions or suggestions!

[goosejordan]

Fantastic news, I will for sure try this out! I know I will need different friction depending on the direction of force, like a ratchet mechanism. Is it easy to modify it to support that?

[josemendez]

Fantastic news, I will for sure try this out! I know I will need different friction depending on the direction of force, like a ratchet mechanism. Is it easy to modify it to support that?

Hi!

Yes, pinholes report the position along the rope they're currently in as well as the relative velocity. You can get the rope's velocity at that point, get its direction, and then use it to drive friction. I will include a sample scene that does this.

[goosejordan]

Hey! I have taken a deeper look into this constraint now. It seems to work fine as intended in the examples! But I'm having problems adapting it to my usecase.

I made a clone of ObiPinhole.cs which instead of one pinhole coinstraint, creates multiple constraints along a spline.
I was able to get some progress by offsetting the FirstEdge and LastEdge of each constraint by their length position along the spline - Then clamping the range down to a point. That gives me the result seen here. Very stable!
   

However, the moment I disable the range the stability collapses and they can no longer keep their positions and it starts to jitter. This happens even with friction set to 1 and motor force to infinity. I would expect them to keep their positions as though they were clamped with infinity friction. The constrains slide over each other so to speak. I could get the cable car example to do the break down similarly if I gave it a high enough speed.
   

If i were to set friction to 0, I can understand that happening as there is nothing in the constraint that forces them to be ordered and distanced to eachother with respect to their mu. However, It would be very useful if there were a setting to force them to have a certain mu offset toward each other.
   

Another issue I see is that if I disable "Limit Range" and enable it again, the attached offsets of the constraints seem to be zeroed.


I totally understand if I'm pushing the use outside of the intended scope and that nothing can be done. The last issue i mentioned seem like a bug to me though

I also attached the script I modified ObiPinhole.cs to

[josemendez]

However, the moment I disable the range the stability collapses and they can no longer keep their positions and it starts to jitter. This happens even with friction set to 1 and motor force to infinity. I would expect them to keep their positions as though they were clamped with infinity friction. The constrains slide over each other so to speak. I could get the cable car example to do the break down similarly if I gave it a high enough speed.

Constraints are completely independent of each other. This is a core design principle of most physics engines, necessary for efficiency reasons: multithreading can only work on constraints that don't share particles as otherwise they'd run into race conditions - multiple threads trying to modify the same particles at the same time, leading to undefined behavior.

For pinholes this means they have no notion of their relative position/distance to each other: they can (and sometimes will, as you discovered) cross over each other.

In practice, making a constraint be "aware" of another constraint means they must act on each other's particles so they effectively become a single, larger constraint. So I guess what you'd want in your case is an uber-pinhole of sorts that constraints multiple particles to multiple points in multiple bodies, and also constrain their relative positions along the rope.

If i were to set friction to 0, I can understand that happening as there is nothing in the constraint that forces them to be ordered and distanced to eachother with respect to their mu. However, It would be very useful if there were a setting to force them to have a certain mu offset toward each other.

Note this may happen even if friction is 1 and motor force is set to infinity, as these parameters affect velocity but don't directly affect position, which other constraints might modify: the only sure-fire way to prevent this is by setting constraint limits.

Another issue I see is that if I disable "Limit Range" and enable it again, the attached offsets of the constraints seem to be zeroed.

Will take a look at this, as it indeed sounds like a bug. Thanks for reporting it!

[goosejordan]

Thanks for the information!

I think some way to guarantee a distance in "mu space" would be very useful. In many cases you would want two pinhole joints close to each other to constrain the direction. But with the possibility of the constraints to pass over each other many simulations will become unstable.

Would it be possible to give each pinhole constraint a reference to another pinhole constraint which (if defined) modifies the constraint limits to keep a certain distance to the reference pinhole? Would this break the multithreading rules or is it fine a single reference to another constraint?

About the bug, I only see it in my script which is creating multiple pinhole constraints in the same batch. Sorry, I can't guarantee I haven't made an error there. I tried debugging best I could but havent found anything wrong in my modified script yet.

[goosejordan]

After some digging I found the issue on my end anyway. I forgot to use the modified edge coordinate per pinhole when m_positionDirty == true. Sorry if it took any time from you!

Now it is actually pretty close to working!  After initially locking the pins with ranges the friction is able to do its job to hold the correct positions.

[josemendez]

I think some way to guarantee a distance in "mu space" would be very useful. In many cases you would want two pinhole joints close to each other to constrain the direction.

This would require all related constraints to become a single constraint, so unfortunately not currently possible.

But with the possibility of the constraints to pass over each other many simulations will become unstable.

If both pinholes are constrained to the same object/rigidbody (which typically is the case when you want to constrain direction) it should be pretty much impossible for them to cross unless there's enough instantaneous tension in the rope for it to slide trough one pinhole, but not slide trough the other. Not sure if this is your case?

Would it be possible to give each pinhole constraint a reference to another pinhole constraint which (if defined) modifies the constraint limits to keep a certain distance to the reference pinhole? Would this break the multithreading rules or is it fine a single reference to another constraint?

Doing this properly would introduce an order dependency between both pinholes: if pinhole A's limits depend on pinhole B's position, then you must ensure that B always gets updated before A, which cannot be guaranteed in the general case given the current API even when ditching multithreading entirely. Obi can only explicitly sort different constraint of different types, eg. distance constraints before bend constraints, bend constraints before pinhole constraints, etc.

If you're fine with just approximate limits that might not be perfectly enforced every frame, you can do this yourself by setting the limits of a pinhole using the position along the rope reported by another pinhole.

About the bug, I only see it in my script which is creating multiple pinhole constraints in the same batch. Sorry, I can't guarantee I haven't made an error there. I tried debugging best I could but havent found anything wrong in my modified script yet.
[...]
After some digging I found the issue on my end anyway. I forgot to use the modified edge coordinate per pinhole when m_positionDirty == true. Sorry if it took any time from you!

Now it is actually pretty close to working! Sonrisa After initially locking the pins with ranges the friction is able to do its job to hold the correct positions.

Glad to hear! let me know if I can be of any help.

kind regards,