Help Stretching ropes without gaps between particles?

[Elegar]

I wonder how to make ropes elastic but without possibility of ropes pass through each other. I understand that stretching the rope causes appearing gaps between particles and from some moments these gaps become quite big to allow other particles to go between them. I do not need endlessly stretching ropes but I need them to be quite more elastic then they are. Setting particles density would fix my problem but it is impossible to set density (resolution) higher than 1.
Any workarounds or suggestions?

---

PS I also noticed that stretched particles are not evenly distributed, but grouped by 2: http://prntscr.com/v11xt0 Is it ok?

[josemendez]

I wonder how to make ropes elastic but without possibility of ropes pass through each other. I understand that stretching the rope causes appearing gaps between particles and from some moments these gaps become quite big to allow other particles to go between them. I do not need endlessly stretching ropes but I need them to be quite more elastic then they are. Setting particles density would fix my problem but it is impossible to set density (resolution) higher than 1.
Any workarounds or suggestions?

---

PS I also noticed that stretched particles are not evenly distributed, but grouped by 2: http://prntscr.com/v11xt0 Is it ok?

Hi,

Obi is a particle-based engine, so collision detection is done on a per-particle basis. If there's gaps in between particles (and if your rope is very elastic, there will be), the only solution is to increase the blueprint resolution. Still, this will only allow you to stretch the rope to roughly double of its rest length before gaps appear.

If you're using sequential mode for distance constraints, constraints in between particles will be updated in an interleaved order (to maximize parallelism) which makes this mode order-dependent (that's why they seem to "pair up" when stretching the rope). Switch to parallel mode if you want order-independent (though slower-convergence) constraint solving. See the "Evaluation Order" section of the solver's manual page for details:
http://obi.virtualmethodstudio.com/tutor...olver.html

The order-dependent nature of the sequential solver is also explained here:
http://obi.virtualmethodstudio.com/tutor...gence.html

[Elegar]

Thank you very much
Actually I just found another workaround: I doubled width of particles. Bigger particles can be stretched more before gaps appear. Then I doubled rope length to keep rope proportions. And finally I increased scale of my game's world to fit increased rope length.

But things would be much easier if it were possible to set rope's resolution larger than 1. Is this limitation actually necessary?

[josemendez]

Thank you very much
Actually I just found another workaround: I doubled width of particles. Bigger particles can be stretched more before gaps appear. Then I doubled rope length to keep rope proportions. And finally I increased scale of my game's world to fit increased rope length.

But things would be much easier if it were possible to set rope's resolution larger than 1. Is this limitation actually necessary?

Hi there,

More particles = More constraints = less performance = worse convergence. This is why resolution is capped to 1: At that resolution, collision detection is usually good enough for a moderately elastic rope, while keeping reasonable convergence speed and performance. As you increase the amount of particles per length unit, performance degrades and the rope becomes artificially more elastic due to poor convergence, so you need to use shorter time steps or more iterations to maintain the same results (which affects performance even more).

The range limit for resolution is entirely artificial though, there's no technical obstacle to having a rope with really high resolution. If you know what you're doing and are aware of the tradeoffs that are associated with long constraint chains in iterative solvers, you can open ObiRopeBlueprint.cs and change the [Range(0,1]] attribute of resolution to [Range(0,3)], or whatever range you'd like to use. In the future we might remove the range limitation and place a warning in the inspector instead, to make people aware that cranking up resolution arbitrarily high is generally not a good idea. Making a really long rope has the same downsides, and there's no limits to rope length anyway, so...

[Elegar]

Thanks for answer @josemendez!
One more little question: is there any difference in terms of performance between following ropes:
1. length 10, width 1, resolution 1  (10 particles, if I'm not wrong)
2. length 20, width 2, resolution 2  (10 particles too)
?

[josemendez]

Thanks for answer @josemendez!
One more little question: is there any difference in terms of performance between following ropes:
1. length 10, width 1, resolution 1  (10 particles, if I'm not wrong)
2. length 20, width 2, resolution 2  (10 particles too)
?

As long as the amount of particles is the same, there's no difference in performance .