Feedback Pinholes: new component for ropes

[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,