Tons of problems trying to simulate simple rope without elasticity

[Romahaaa]

Hey,

I spent tons of time trying to simulate the rope I need. 
The idea was pretty simple - the rope must be attached to the pencil, and the paper clip must be attached to the end of the rope. Moving the pencil paper clip had to behave more or less realistic way, but I couldn't reach it playing with all the parameters and iterations. I also checked all the test scenes, and still can't get, why it's so complicated to implement it.
The issues I got:

1. rope and paper clip NEVER stops moving while the pencil is static. Here is the video.
   
2. rope behaves like a fishing string moving the pencil up and down. Furthermore it looks like paperclip has 10kg of mass while it's 0.01 only. Here is the video. 
   I need the rope similar to this      As you understand such type a rope don't stretch at all an don't.
   
3. the worst issue - if I move down the pencil and paperclip collides with a surface, it behaves veeery weird - instead of laying down to the surface it "floats" in the air, and the rope starts to shake as crazy. Here is the video.
   
4. artifacts with attached objects - looks like the attached paper clip (but I also will add more attachments) position doesn't follow the particles position properly. You can see in the video I mentioned in #3 there are some gaps between paperclip pivot point and end of the rope.
   

[josemendez]

rope and paper clip NEVER stops moving while the pencil is static. Here is the video.

Chances are the rope and the clip are colliding with each other. This will result in jittering, attachment offsets and all sorts of weird behavior as described in the "Pin constraints and collisions" section of the manual:

http://obi.virtualmethodstudio.com/manua...collisions

Quoting it:

When pinning a particle very close to or inside a collider (so that they overlap), if you have collision constraints enabled you can encounter a situation in which both constraints fight each other. This results in jittering and/or an undesired offset in the pin position, because the collision and pin constraint cannot be met simultaneously. If the particle is pinned to a rigidbody, results will be even worse as this setup causes a force feedback loop with largely undefined behavior.

Just filter out collisions between the rope and the clip using collision filters, as suggested in the above link.

rope behaves like a fishing string moving the pencil up and down. Here is the video. 
I need the rope similar to this  As you understand such type a rope don't stretch at all an don't.

Crank up the amount of substeps (setting found in the ObiFixedUpdater). That will do. The manual contains a very detailed explanation of how and why the timestep and the amount of iterations affect the perceived elasticity of the simulation, and why using a smaller timestep is more effective:

http://obi.virtualmethodstudio.com/manua...gence.html

Also keep in mind that the higher your rope blueprint's resolution, the more substeps you'll need to remove any spurious compliance (since the rope contains more particles and constraints). It's usually a good idea to keep resolution around 0.25-0.5 unless you really need full resolution, this is specially the case for long ropes.

Furthermore it looks like paperclip has 10kg of mass while it's 0.01 only.

The mass of the paperclip doesn't matter by itself. What's important is the mass ratio between the clip and the rope. If your clip mass is 0.01 and your rope is 0.001, then for all intents and purposes your paperclip weights 10 times more than the rope. You'll get the same results you would with a 10 kg clip attached to a 1kg rope.

the worst issue - if I move down the pencil and paperclip collides with a surface, it behaves veeery weird - instead of laying down to the surface it "floats" in the air, and the rope starts to shake as crazy. Here is the video.

Your clip and the rope are colliding with each other, as I pointed out above. The situation is this: the rope is attached inside a collider, so the attachment wants the rope to be inside the collider. However the collider wants the rope to get outside. Since the rope can't be simultaneously inside and outside the collider (for obvious reasons, you cannot be both inside and outside someplace), jitter and weirdness ensues as the engine tries to solve something that's impossible to solve.

The simplest solution is to deactivate collisions between the end of the rope and the clip, as proposed in the manual.

artifacts with attached objects - looks like the attached paper clip (but I also will add more attachments) position doesn't follow the particles position properly. You can see in the video I mentioned in #3 there are some gaps between paperclip pivot point and end of the rope

Same issue as above: there's a gap because the rope is colliding with the clip.

I also checked all the test scenes, and still can't get, why it's so complicated to implement it.

Deformable body physics is really complex, advanced stuff. Most people struggle understanding regular rigidbodies well enough, for deformables crank up difficulty a couple notches. Getting comfortable with it will take some time, so hang in there (no pun intended ). Let me know if I can be of help.

[Romahaaa]

Chances are the rope and the clip are colliding with each other. This will result in jittering, attachment offsets and all sorts of weird behavior as described in the "Pin constraints and collisions" section of the manual

Well, I am familiar with pin constraints. Everything was set properly - paper clip and pencil use category 1, rope uses category 0 with excluded cat 1 in collision mask for pins (the attached points).
I also had start2 and end2 pins which where far away from pencil and paper clip colliders with the same setup and start and end, but to make the experiment more simple I removed them. Nothing helped. After that I removed and added Obi Particle Attachments components again and this stop jittering... But the result is horrible still because none of your recommendations helped.

Crank up the amount of substeps (setting found in the ObiFixedUpdater). That will do. The manual contains a very detailed explanation of how and why the timestep and the amount of iterations affect the perceived elasticity of the simulation, and why using a smaller timestep is more effective

As I said before I tried to play with the different parameters: increase substeps/decrease time step/both of them. The timestep decrease works better comparing to substeps increase. To avoid the stretching effect I tried to increase distance substeps only but this works different way in 2 cases - when rope is not collided with surface or other colliders rope is not so stretchy but when it collides with a surface, it behaves like a metal string - the rope can push the attached object...looks really weird.
Here is an example using your RopeAndJoints scene: video

The simplest solution is to deactivate collisions between the end of the rope and the clip, as proposed in the manual.

Again, as I said before I checked ALL the documentation you have. I used as a sample your own scene and you can see the result in the video above. Please, stop refer to some solutions in documentation because IT DOES NOT WORK. Seems your asset is able to do some simulations without 2nd object attachment affected by physics. Rope just isn't a rope.

Same issue as above: there's a gap because the rope is colliding with the clip.

Nope, it's not. You can see clearly that your sphere and the rope in the same RopeAndJoints scene behave same way. video


Conclusion - I am pretty sure that you couldn't setup it the similar way I need it as well.

[josemendez]

Hi!

when rope is not collided with surface or other colliders rope is not so stretchy but when it collides with a surface, it behaves like a metal string - the rope can push the attached object...looks really weird.
Here is an example using your RopeAndJoints scene: video

- The rope has zero max bending, so it will behave as closely to a rigid string as possible (given the solver budget).
- It has zero max compression, so it has the exact same pull and push resistance. It's not allowed to compress (lose volume).

So what you show in the video is the intended result: a rigid-as-possible rope (again, given timestep and iteration budget), that will push the object around as well as pull from it.

If you don't want this effect, increase max bending and max compression parameters (both found in the rope component itself): this will allow the rope to bend easily, and compress instead of pushing the object around:



If you want the rope to coil/bend instead of compress, but still don't push the object, increase max bending only and leave max compression to zero.

Again, as I said before I checked ALL the documentation you have. I used as a sample your own scene and you can see the result in the video above. Please, stop refer to some solutions in documentation because IT DOES NOT WORK. Seems your asset is able to do some simulations without 2nd object attachment affected by physics. Rope just isn't a rope.

I'm sorry, I can feel your frustration with this. The solutions I referred to totally work for me, I can help with your use case if you want. Just send me your scene to support(at)virtualmethodstudio.com and I'll do my best to adjust it.

Nope, it's not. You can see clearly that your sphere and the rope in the same RopeAndJoints scene behave same way. video

That's because the solver and the sphere rigidbody are using interpolation (for the smooth slow-mo/bullet-time effect in that particular scene), so it will always have a 1-frame delay as warned in the manual:

http://obi.virtualmethodstudio.com/manua...olver.html

Keep in mind that interpolation introduces a 1-frame delay. This is specially important to keep in mind when attaching actors to other objects.

Disable interpolation in both the rigidbody and the rope. In this video I have set the timescale to 20% so that the simulation is slow enough to see any gaps that may appear:


Note that a small gap can still appear if the rope is overstretched (such as when you suddenly jerk the rope around with great force), but that's not possible to avoid. If the rope is 2 meters long but the distance between attachments at its ends is 3 meters, it will stretch and gaps will unavoidably appear.

Conclusion - I am pretty sure that you couldn't setup it the similar way I need it as well.

I'm not sure what specific results you're after, but attaching an object to a rope shouldn't pose any problems. It's a very simple setup that I've seen done hundreds of times in many projects over the years, under very challenging simulation conditions. Maybe if you present a reference video of the results you want I can help you get closer to them or give you a sample scene that approximates it.

kind regards,

[josemendez]

Hi,

Went ahead and replicated your original scene. You can find the scene and all associated assets attached in this wetransfer link:
https://we.tl/t-ML2mYnC7Rf

Here's a video of it:



I aimed at a very easy to bend, zero-stretch rope with high contact friction and a light object attached to its end. As you can see the simulation is very snappy, extremely robust under violent motion, zero jittering, no gaps, comes at a perfect rest very easily. Runs at > 600 fps (1.5 ms/frame) in a Core i7.

I'm not 100% sure the behavior of the rope is what you were originally after, maybe it could be a bit more rigid (the kind of cord in the image you posted above tends to be quite rigid and has some plasticity to it). Also the scale of the scene is quite large: that clip is definitely not as small as a real-world clip, but based on the grid seen in your original video I think it's pretty close to yours.

let me know if I can be of further help or if you'd wish specific adjustments to this scene to be made.

[Romahaaa]

I aimed at a very easy to bend, zero-stretch rope with high contact friction and a light object attached to its end. As you can see the simulation is very snappy, extremely robust under violent motion, zero jittering, no gaps, comes at a perfect rest very easily. Runs at > 600 fps (1.5 ms/frame) in a Core i7.

I'm not 100% sure the behavior of the rope is what you were originally after, maybe it could be a bit more rigid (the kind of cord in the image you posted above tends to be quite rigid and has some plasticity to it). Also the scale of the scene is quite large: that clip is definitely not as small as a real-world clip, but based on the grid seen in your original video I think it's pretty close to yours.

Well.. This definitely much better comparing what I made, but also with some weird things. The rope stops pretty often in such poses but the funniest is how it deforms like a wave when you drag it. I found that adding much more mass to paperclip (1kg instead of 0.1f) the result is much better. As I understood there are no ideal option to cover all the scenarios so need to negotiate between them. Will check how it works on mobile with AR enabled, I hope it will not overload the CPU.

Thanks for the package. Btw, it would be veeeery helpful if you add more sample scenes with a different materials simulation. For example, in your package you attached I see that you activated all the constraints (except chain) in ObiSolver component, while your Rope package sample scenes have just couple of them enabled with a different params. I believe not all of these constraints are required - I didn't test much but disabling some of them didn't affect to the rope behaviour at all.

UPDATE!
Well, seems I found one of the main problems here - in your package the size of objects are not realistic, it's about x50 time bigger then real world size. In my case the rope is ~12cm, paper clip ~3cm, pencil ~15cm. I created rope blueprint according to the real size, so this means the distance between start and end points (attachment points) was ~12cm. Using Particle renderer I see that there are only 2 particles in the real world size rope using the parameters from your scene.
The only way to add more particles is decreasing blueprint thickness and set decimation to 0 but after reaching same particles count for the same distance, I see that the rope behaviour become pretty different.
Another approach I found to fit your last example to my real world size scene is to scale down the ObiSolver transform to 0.02. The only issue in that case that paperclip doesn't rotates, only when collides with a surface.
Please clarify - why these 2 approaches doesn't behave similar way? Does it mean that rope itself had to be bigger initially?

[josemendez]

Well.. This definitely much better comparing what I made, but also with some weird things. The rope stops pretty often in such poses 

That's probably because the solver's sleep threshold is a tad too high, reducing it will allow rope particles to continue moving even if they have very little energy:
http://obi.virtualmethodstudio.com/manua...olver.html

Sleep threshold: Any particle with a kinetic energy below this value will be freezed in place. This is useful when you don´t want minuscule variations in velocity or force to perturb an actor, making it look like its jittering or moving very slowly.

but the funniest is how it deforms like a wave when you drag it. I found that adding much more mass to paperclip (1kg instead of 0.1f) the result is much better.

This is the expected and intended behavior: the "waves" are energy traveling trough the rope. Keep in mind that dragging a transform happens in Update(), but the simulation takes place in FixedUpdate(). FixedUpdate() is called at a different frequency than Update(), so the rope sees the cylinder it is attached teleport between frames in stop-and-go fashion. These small jerky movements are translated as waves traveling trough the rope.

Increasing the mass of the paperclip tenses the rope up faster, so the frequency of the waves will increase and become less noticeable mainly due to the temporal resolution not being high enough to see fast vibrations. Damping also plays a role in this.

Btw, it would be veeeery helpful if you add more sample scenes with a different materials simulation.

The Crane and FreightLift scenes have easily bendable ropes, the RopeShowcase has ropes with various bending parameters, the rope cutting scene has somewhat intermediate stuff. You also have examples of chains, nets, etc. Each scene uses quite different parameters. If there's any parameter combination in particular that you'd want to see among the examples let me know!

For example, in your package you attached I see that you activated all the constraints (except chain) in ObiSolver component, while your Rope package sample scenes have just couple of them enabled with a different params. I believe not all of these constraints are required - I didn't test much but disabling some of them didn't affect to the rope behaviour at all.

The manual introduction contains a list of all constraint types and indicates which actors use each one and what for:
http://obi.virtualmethodstudio.com/manua...rainttypes

For instance:

Distance constraints: [...]These are responsible for the elasticity of cloth and ropes.
Bend constraints: [...]These are used to make cloth and ropes resistant to bending.
Tether constraints: [...]These constraints are used to reduce stretching of cloth.
Skin constraints: [...]Skin constraints are used to keep skeletally animated cloth close to its skinned shape.
Stretch/shear constraints: [...]These are used by rods and bones.

...etc

Then the individual page for each constraint type describes where they are used and how they work.

Ropes only use distance and bend constraints:
http://obi.virtualmethodstudio.com/manua...aints.html
http://obi.virtualmethodstudio.com/manua...aints.html

You can also see that distance and bend are the only constraint types that appear in the ropes' inspector.
Rods for instance, use stretch/shear, bend/twist and chain constraints:

http://obi.virtualmethodstudio.com/manua...aints.html
http://obi.virtualmethodstudio.com/manua...aints.html
http://obi.virtualmethodstudio.com/manua...aints.html

[josemendez]

UPDATE!
Well, seems I found one of the main problems here - in your package the size of objects are not realistic, it's about x50 time bigger then real world size. In my case the rope is ~12cm, paper clip ~3cm, pencil ~15cm. I created rope blueprint according to the real size, so this means the distance between start and end points (attachment points) was ~12cm. Using Particle renderer I see that there are only 2 particles in the real world size rope using the parameters from your scene.
The only way to add more particles is decreasing blueprint thickness and set decimation to 0 but after reaching same particles count for the same distance, I see that the rope behaviour become pretty different.
Another approach I found to fit your last example to my real world size scene is to scale down the ObiSolver transform to 0.02. The only issue in that case that paperclip doesn't rotates, only when collides with a surface.
Please clarify - why these 2 approaches doesn't behave similar way? Does it mean that rope itself had to be bigger initially?

Yes, everything is way bigger than in real life in that scene as I pointed out:

“Also the scale of the scene is quite large: that clip is definitely not as small as a real-world clip, but based on the grid seen in your original video I think it's pretty close to yours.”

I took your original video as reference, there the clip is around half a grid cell (which I thought meant its intended size was half a meter long or so). Seemed weird to me so that’s why I commented on that, not sure if my interpretation of your scene was correct.

Scaling the solver does not scale the rope: it scales the simulation space, that’s very different.
Think about an object moving at 10 m/s: if you make the object half its size, it still moves at 10 m/s.  However if you keep the size of the object and scale the space down by 50%, the object will not only look smaller but appear to move at 5 m/s for any external observer.

In your case, making a thin rope using real world units is the best approach imho.

[Romahaaa]

In your case, making a thin rope using real world units is the best approach imho.

Well, I tried to do so. I changed everything to real sizes and set the blueprint thickness to 0.0015, so it have almost same amount of particles comparing to your samples.
Unfortunately, I still got problems here:

1. paperclip is not tightly fixed to the bottom rope particle. I also tried to add by 1 control point to each side of the rope, just to see, will it "help" to hold paperclip or not, but this didn't work. Here is example
   
2. I found that if paperclip hit the trigger collider (I need it in my case to detect the TriggerEnter event with another object) each frame. This means OnTriggerEnter and OnTriggerExit are called even when paper visually doesn't leave the collider area. I assume this is because the interpolations, but is there a way to solve it?
   
   

I updated your sample scene adding real size objects and added TriggerDebugger component so you can get easy what do I mean in #2. Please have a look, I hope I may make it work finally as expected.

[josemendez]

paperclip is not tightly fixed to the bottom rope particle. I also tried to add by 1 control point to each side of the rope, just to see, will it "help" to hold paperclip or not, but this didn't work. Here is example

Pin constraints are still constraints. This means that if they don't fully converge at the end of the frame, the condition imposed by them might not hold perfectly. As in any iterative solver, this is exacerbated by large mass ratios, and improved by using smaller time steps or more iterations.

You can either use more substeps, spend extra iterations on pin constraints alone, or reduce the mass of the clip. This should help completely close the gap.

I found that if paperclip hit the trigger collider (I need it in my case to detect the TriggerEnter event with another object) each frame. This means OnTriggerEnter and OnTriggerExit are called even when paper visually doesn't leave the collider area. I assume this is because the interpolations, but is there a way to solve it?

Not sure what you mean. Triggers are part of Unity, Obi's solver interpolation has no effect on them. If you're referring to rigidbody interpolation, then yes this is to be expected: interpolation derives rendering state from physical state: objects are drawn where they should be according to render time, but as far as the physics engine goes (this includes triggers) they're located elsewhere since simulation time != render time. Same for extrapolation. I don't think this can be prevented.

I updated your sample scene adding real size objects and added TriggerDebugger component so you can get easy what do I mean in #2. Please have a look, I hope I may make it work finally as expected.

I can't see any links to the updated scene. Can you share it so that I may take a look?