Improving collisions and self collisions

[Pr0fitt3R]

Guys, are there any way to improve the collisions and self collisions besides increasing the number of iterations? Now I'm using 100 iterations, but sometimes my rope just ignore the obstacles and even itself. My rig is dealing great with that amout of iterations and icreasing it wouldn't be a problem, but I wonder if there is another parameter that i'm missing.

I'm trying to curl a rope on a reel but, sometimes, one part of the rope just pass through another. Other times it pass through the reel walls. It doesn't happens all the time, just some times. But I need to reduce this glitch as much as possible.

Thanks in advance!

[Pr0fitt3R]

Anyone?

I've already realised that increasing the rope resolution parameter will give me a better collision detection. But It will increase the rope flexibility either and i'm trying to create something not so flexible.

[josemendez]

Anyone?

I've already realised that increasing the rope resolution parameter will give me a better collision detection. But It will increase the rope flexibility either and i'm trying to create something not so flexible.

Hi there!

Have your tried increasing the amount of distance constraint iterations? (not just the collision iterations). This will make your rope less stretchy. Also try using tether constraints if your setup allows it.

[Pr0fitt3R]

Hi there!

Have your tried increasing the amount of distance constraint iterations? (not just the collision iterations). This will make your rope less stretchy. Also try using tether constraints if your setup allows it.

Hi, Jose! Thanks for helping me


In fact, my rope isn't stretching and I'm not having any sort of length issue.

I'm talking about flexibility, resistance to bend.

When I increase the resolution parameter (trying to get consistent results during self collisions), my rope becomes flexible (small bending radius).

I need both consistent self-collisions results and low flexibility (large bending radius), though.


You know what I mean? 

[josemendez]

Hi, Jose! Thanks for helping me


In fact, my rope isn't stretching and I'm not having any sort of length issue.

I'm talking about flexibility, resistance to bend.

When I increase the resolution parameter (trying to get consistent results during self collisions), my rope becomes flexible (small bending radius).

I need both consistent self-collisions results and low flexibility (large bending radius), though.


You know what I mean? 

Hi!

Yep, now I get it .

The thing with high-res ropes is that they have more particles, and bend constraints only work on 3 particles at a time (they have very low "radius", if you will). So for the anti-bending forces to propagate faster trough the rope, you need to increase the amount of bending constraint iterations in your ObiSolver. Using 20-50 iterations is not unusual for certain scenarios. This is similar to how all constraints work: for them to be more effective at what they do, you need to tell the solver to spend more resources (iterations) on enforcing them.

This will of course impact performance, as more iterations mean more work for the solver. How high you can crank the amount of iterations depends on your performance budget and how stiff you need your rope to appear. Note that getting a perfectly rigid rod using bend constraints would require an infinite amount of iterations. Obi Rope is designed to simulate ropes/chains, which are usually quite flexible by nature.

There's another kind of constraints we will be adding in the future, called "shape-matching" constraints. These would be better suited to keep particles in a certain rigid shape.

You can take a look at this video (excuse my strong accent), which will hopefully shed some more light on the inner workings of bend constraints:
https://www.youtube.com/watch?v=pe5mROQqPv8

cheers!

[Ttakala]

I have the same issue: I want to keep resolution high for self-collisions, and also want to be able to have a very stiff rope (I'm modifying the parameters in real-time, and it works pretty well for length and thickness). Setting the bending constraint iterations to 50 (or even 500) just doesn't get me the stiffness that I'm looking for.

Looking forward to the "shape-matching" constraints, hopefully they can be turned on and off in real-time.

[Pr0fitt3R]

Hi!

Yep, now I get it .

The thing with high-res ropes is that they have more particles, and bend constraints only work on 3 particles at a time (they have very low "radius", if you will). So for the anti-bending forces to propagate faster trough the rope, you need to increase the amount of bending constraint iterations in your ObiSolver. Using 20-50 iterations is not unusual for certain scenarios. This is similar to how all constraints work: for them to be more effective at what they do, you need to tell the solver to spend more resources (iterations) on enforcing them.

This will of course impact performance, as more iterations mean more work for the solver. How high you can crank the amount of iterations depends on your performance budget and how stiff you need your rope to appear. Note that getting a perfectly rigid rod using bend constraints would require an infinite amount of iterations. Obi Rope is designed to simulate ropes/chains, which are usually quite flexible by nature.

There's another kind of constraints we will be adding in the future, called "shape-matching" constraints. These would be better suited to keep particles in a certain rigid shape.

You can take a look at this video (excuse my strong accent), which will hopefully shed some more light on the inner workings of bend constraints:
https://www.youtube.com/watch?v=pe5mROQqPv8

cheers!

I dont need a rigid cylinder, but I got your point  


In fact, what I'm trying to do is to simulate something like an wire winding, as many layers as possible. Naturally, the lower layers must be able to support the upper ones. That's why I need to avoid missing self-collisions, otherwise it's gonna be a mess  

Something like that:



Due to that fact, is it possible change the spheric collider inside the rope for the capsule one? It would fill the gaps between the particles without needing to increase its amount.



These shape-matching constraints will be extremely usefull in my project if I were able to freeze parts of the rope in order to relieve the processing. Can't wait to use it  

I have the same issue: I want to keep resolution high for self-collisions, and also want to be able to have a very stiff rope (I'm modifying the parameters in real-time, and it works pretty well for length and thickness). Setting the bending constraint iterations to 50 (or even 500) just doesn't get me the stiffness that I'm looking for.

Looking forward to the "shape-matching" constraints, hopefully they can be turned on and off in real-time.

Hi! I don't know what stiffness do you need, however here I'm using res 0.5 and 100 bending iterations and it became stiffy enough for my purposes 

[josemendez]

I dont need a rigid cylinder, but I got your point  


In fact, what I'm trying to do is to simulate something like an wire winding, as many layers as possible. Naturally, the lower layers must be able to support the upper ones. That's why I need to avoid missing self-collisions, otherwise it's gonna be a mess  

Something like that:



Due to that fact, is it possible change the spheric collider inside the rope for the capsule one? It would fill the gaps between the particles without needing to increase its amount.



These shape-matching constraints will be extremely usefull in my project if I were able to freeze parts of the rope in order to relieve the processing. Can't wait to use it  



Hi! I don't know what stiffness do you need, however here I'm using res 0.5 and 100 bending iterations and it became stiffy enough for my purposes 

Hi!

Using self-collisions for this is a dead-end, as you might have discovered by now. It's just too many collisions happening at once, and lot of wasted performance just for keeping the rope coiled in place.

Also, particles are inherently spherical (that's what makes them so fast compared to regular colliders, as they are just a <position,radius> pair. They have no rotation information, therefore no quaternions or matrices involved in their simulation). They cannot be made into capsules or any other shape, as that would require to add a quaternion to express their rotation, a 3x3 matrix to represent their inertia tensor, etc... at that point we would be back to regular, unstable rigidbodies.

A much better approach to this would be to represent the coil itself with a static mesh. Append mesh vertices to it when the rope shortens, and remove vertices from it when the rope increases its lenght. This way maintaining the coil takes virtually 0 performance and you're only simulating the "free" end.

[Pr0fitt3R]

Hi!

Using self-collisions for this is a dead-end, as you might have discovered by now. It's just too many collisions happening at once, and lot of wasted performance just for keeping the rope coiled in place.

Also, particles are inherently spherical (that's what makes them so fast compared to regular colliders, as they are just a <position,radius> pair. They have no rotation information, therefore no quaternions or matrices involved in their simulation). They cannot be made into capsules or any other shape, as that would require to add a quaternion to express their rotation, a 3x3 matrix to represent their inertia tensor, etc... at that point we would be back to regular, unstable rigidbodies.

A much better approach to this would be to represent the coil itself with a static mesh. Append mesh vertices to it when the rope shortens, and remove vertices from it when the rope increases its lenght. This way maintaining the coil takes virtually 0 performance and you're only simulating the "free" end.

Yeah, I realised this! 


As I said before, It would be extremely usefull if I were able to freeze/unfreeze parts of the rope. But I though it would be possible only after the shape-matching constraints update. How can I do that thing with the vertices? Are there any documentation about it, any example?  


Thanks (one more time, lol) in advance, Jose!

[josemendez]

Yeah, I realised this! 


As I said before, It would be extremely usefull if I were able to freeze/unfreeze parts of the rope. But I though it would be possible only after the shape-matching constraints update. How can I do that thing with the vertices? Are there any documentation about it, any example?  


Thanks (one more time, lol) in advance, Jose!

Hi!

Well, if the rope is parented to the coil, fixing rope particles (i.e, setting their inverse mass to 0) would have the effect you want: they'd follow the rope transform, and by extension (because of parenting) the coil transform. They'd be frozen in the coil transform's local space. So when the coil rotates/translates, they'd move with it. Unfixed particles would still be simulated as usual.

So you could determine which particles to fix (by distance to the coil, or some other method) and then fix them. See http://obi.virtualmethodstudio.com/tutor...icles.html for an example on how to fix particles in place programmatically. 

This method (fixing particles close to the coil) would not require building your own mesh to fake the amount of coiled rope. The particles would still be there, but wouldn´t need to generate any collisions between them because they'd be fixed.

The other method I proposed in the previous post basically involves using the ObiRopeCursor component the extend/retract the rope dynamically, similar to the "Crane" sample scene included with Obi. Place it near the coil so that the rope gives the impression of coming out of the coil. Right where the rope meets the coil, append/remove vertices to/from a mesh that represents the coil itself. I think this video (AgX dynamics, an engineering-grade simulator) will make it clearer:



As you can see around 0:28, the coil itself is a simple static mesh (see the wireframe in green). Only the "free" part of the rope is simulated using particles. When the coil retracts the rope, particles disappear (this is handled by ObiRopeCursor) and you'd add a new loop of vertices to the coil mesh. When the coil extends the rope, reverse the process: mesh loops disappear from the coil, as new particles are created by the ObiRopeCursor.  

This method is slightly more complex to implement, but has the advantage that it uses much less particles. You´d be able to wind up as much rope as you'd like with barely any performance hit (rendering meshes is very cheap compared to simulating physics).

You'd only have to manage the addition/removal of mesh loops to the coil. Take a look at Unity's "Mesh" class for more info on how to modify a mesh at runtime: 
https://docs.unity3d.com/ScriptReference/Mesh.html