(26-07-2017, 03:54 PM)Pr0fitt3R Wrote: 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.

(27-07-2017, 07:25 AM)josemendez Wrote: 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.

(14-08-2017, 07:24 PM)Pr0fitt3R Wrote: 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? 

(15-08-2017, 11:27 AM)josemendez Wrote: 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!

(17-08-2017, 02:50 AM)Ttakala Wrote: 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.

(17-08-2017, 04:43 PM)Pr0fitt3R Wrote: 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 

(17-08-2017, 08:37 PM)josemendez Wrote: 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.

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?  

(22-08-2017, 07:09 PM)Pr0fitt3R Wrote: 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!