Question about a specific Obi Rope application

[kkansy]

Hello I want to create a rather long hose dragged by a dynamic object throughout the scene, while keeping collision with the scene objects like building, trees etc. as well as realistic hose baviour, including two-way dragging. Is Obi Rope suitable for such application? Thanks in advance for help.

[josemendez]

Hello I want to create a rather long hose dragged by a dynamic object throughout the scene, while keeping collision with the scene objects like building, trees etc. as well as realistic hose baviour, including two-way dragging. Is Obi Rope suitable for such application? Thanks in advance for help.

Hi there!

Obi does support two-way rigidbody coupling (dragging), collision with dynamic and static objects, etc.
Whether or not it would fit your use case basically depends on your hose length to width ratio, and how accurate you need collision detection to be.

Let me explain: the longer and thinner the rope, the larger the amount of particles Obi will need to represent it, and the larger the amount of constraint iterations you´ll need to keep it from stretching.

If you need accurate collision detection with objects that are as thin or thinner than the rope, this also poses problems, since they can slip trough gaps in the particle representation of the rope.

All of these issues can be resolved by brute force: increase the amount of solver iterations until the behavior is acceptable. But of course, more iterations = less performance. So it all depends on these three things:

- Precision requisites of your collision detection. Objects thicker than the rope diameter will collide ok, smaller objects will not.
- Length to width ratio of the rope/hose. A ratio of 50:1 is ok, a ratio of 2000:1 is not.
- Whether your performance budget is enough to get it all working as needed. For a single rope on desktop platforms it's fairly unlikely you'll have performance problems, but still.

[kkansy]

What a comprehensive answer, thank you My scenario will definitely require more than 2000:1 require somewhere between 1000:1 and 1500:1 length/width ratio. Does that mean it's a deal breaker or it's still feasible and I'll just have to sacrifice some quality/accuracy? Or maybe is it possible to do some tricks like connecting one shorter fragment to another (which is fine by me in my scenario)? I should have note it in my previous post: I'm targeting desktop. 
Thank you for your time.

EDIT: I had my ratios wrong.

[josemendez]

What a comprehensive answer, thank you My scenario will definitely require more than 2000:1 require somewhere between 1000:1 and 1500:1 length/width ratio. Does that mean it's a deal breaker or it's still feasible and I'll just have to sacrifice some quality/accuracy? Or maybe is it possible to do some tricks like connecting one shorter fragment to another (which is fine by me in my scenario)? I should have note it in my previous post: I'm targeting desktop. 
Thank you for your time.

EDIT: I had my ratios wrong.

It's difficult to tell. Your ratio lies right where things start to get problematic, but maybe you can get away with it by cranking the amount of iterations fairly high. 

At this point its hard to say anything without actually trying it. I'd recommend to experiment with it, if you find it doesn't cut it we can offer you a refund.

[kkansy]

It's difficult to tell. Your ratio lies right where things start to get problematic, but maybe you can get away with it by cranking the amount of iterations fairly high. 

At this point its hard to say anything without actually trying it. I'd recommend to experiment with it, if you find it doesn't cut it we can offer you a refund.

I will check it, thanks