Help on configuring Obi Rope to simulate sewing.

[ploom]

Hello,

Just want to start by saying I really like Obi Rope, it performs excellently and I can see a lot of potential in the platform.

Now for my issue: I am trying to simulate sewing, like thread and needle sewing. I am just having some difficulty with configuring the rope to look and feel like thread (or dental floss). To clarify, currently my Obi Rope is stretchy, bouncy, and too fluid. When I move the needle (with thread pinned to it), I need the thread to have 0 stretch, 0 bounce, and stiff enough that simple movement like up-down or left-right does not make the thread jiggle like a wet noodle. And of course, it should have enough bending that will allow for tying relatively tight knots, but that is less of a priority than the thread movement itself.

What are some options to play around with? Or at least which options should I avoid or disable completely to get rid of stretch, bounce, and spring, and add stiffness?

Thank you very much!

[niZmo]

Hello,

Just want to start by saying I really like Obi Rope, it performs excellently and I can see a lot of potential in the platform.

Now for my issue: I am trying to simulate sewing, like thread and needle sewing. I am just having some difficulty with configuring the rope to look and feel like thread (or dental floss). To clarify, currently my Obi Rope is stretchy, bouncy, and too fluid. When I move the needle (with thread pinned to it), I need the thread to have 0 stretch, 0 bounce, and stiff enough that simple movement like up-down or left-right does not make the thread jiggle like a wet noodle. And of course, it should have enough bending that will allow for tying relatively tight knots, but that is less of a priority than the thread movement itself.

What are some options to play around with? Or at least which options should I avoid or disable completely to get rid of stretch, bounce, and spring, and add stiffness?

Thank you very much!

You’ll always have some kind of stretching. Tying knots where it won’t undo will take a lot of resources, I don’t even know if it’s possible. You have to go to your solver and crank up the iterations for you distance constraint to 20-30. Same on the collision iteration. For your rope turn the resolution all the way up and turn on self collisions. To not stretch the rope you’ll have to write a custom script. You can get the total length of the rope once interacting with it, and once it’s length increases then stop the needle from being move further from the attached particle. If your rope does have a attached particle somewhere (not the needle) you can also use tether constraints to prevent the rope from stretching naturally.

To make the rope a little stiffer you need to mess with the bending constraint. The rope should have the bending constraint on it where you can set the bending amount and in the solver you can increase the accuracy of it by turning up the iterations.

You can read up on it here.

[josemendez]

Hello,

Just want to start by saying I really like Obi Rope, it performs excellently and I can see a lot of potential in the platform.

Now for my issue: I am trying to simulate sewing, like thread and needle sewing. I am just having some difficulty with configuring the rope to look and feel like thread (or dental floss). To clarify, currently my Obi Rope is stretchy, bouncy, and too fluid. When I move the needle (with thread pinned to it), I need the thread to have 0 stretch, 0 bounce, and stiff enough that simple movement like up-down or left-right does not make the thread jiggle like a wet noodle. And of course, it should have enough bending that will allow for tying relatively tight knots, but that is less of a priority than the thread movement itself.

What are some options to play around with? Or at least which options should I avoid or disable completely to get rid of stretch, bounce, and spring, and add stiffness?

Thank you very much!

Amen to what niZmo said.

To further explain the situation: All physics simulations are composed of several "parts" or "bodies" (particles in Obi's case) that interact together in some way. These interactions are represented by a set of equations that must be solved exactly or approximately.

Very broadly speaking, there are two kinds of physics solvers: direct and iterative. Direct solvers take all equations (that relate all parts in the simulation) and try to find the exact solution in one go. They are usually fast enough for small scenes (2, 3, 10 equations) but as the amount of equations grow, they can become extremely expensive. To achieve zero stretch, zero bounce, (that is, a perfect simulation) you'd need a direct solver, and these are too slow to be used in realtime.

On the other hand, iterative solvers -Obi, PhysX, Bullet, Box2D, Havok...nearly all game physics engines- do several quick passes (iterations) over all equations, getting closer to the exact solution each time. You can stop the process at any time and get a reasonably good solution. The more times you let the solver iterate, the better the solution (that is, less stretchy rope). These are much faster and you can easily adjust quality/performance. The downside is that they won't get you an exact solution unless you use a lot of iterations (and most of the time, they will still arrive faster at the solution than a direct solver).

So, direct solvers are used in scientific scenarios where accuracy is paramount (seen them used for surgical suture simulators, where all there is in the scene is a single thread). For games, iterative solvers are the way to go. So as niZmo said, it is not possible to get zero stretch in the general case. Not with Obi, not with any other physics engine. There are tricks that you can use for certain scenarios (he mentioned tether constraints), but that's all.

That being said: crank up the amount of distance constraint iterations in ObiSolver to get less stretchy rope. How high you can set the iteration count depends on your performance budget and your tolerance for stretchiness.

[ploom]

Amen to what niZmo said.

To further explain the situation: All physics simulations are composed of several "parts" or "bodies" (particles in Obi's case) that interact together in some way. These interactions are represented by a set of equations that must be solved exactly or approximately.

Very broadly speaking, there are two kinds of physics solvers: direct and iterative. Direct solvers take all equations (that relate all parts in the simulation) and try to find the exact solution in one go. They are usually fast enough for small scenes (2, 3, 10 equations) but as the amount of equations grow, they can become extremely expensive. To achieve zero stretch, zero bounce, (that is, a perfect simulation) you'd need a direct solver, and these are too slow to be used in realtime.

On the other hand, iterative solvers -Obi, PhysX, Bullet, Box2D, Havok...nearly all game physics engines- do several quick passes (iterations) over all equations, getting closer to the exact solution each time. You can stop the process at any time and get a reasonably good solution. The more times you let the solver iterate, the better the solution (that is, less stretchy rope). These are much faster and you can easily adjust quality/performance. The downside is that they won't get you an exact solution unless you use a lot of iterations (and most of the time, they will still arrive faster at the solution than a direct solver).

So, direct solvers are used in scientific scenarios where accuracy is paramount (seen them used for surgical suture simulators, where all there is in the scene is a single thread). For games, iterative solvers are the way to go. So as niZmo said, it is not possible to get zero stretch in the general case. Not with Obi, not with any other physics engine. There are tricks that you can use for certain scenarios (he mentioned tether constraints), but that's all.

That being said: crank up the amount of distance constraint iterations in ObiSolver to get less stretchy rope. How high you can set the iteration count depends on your performance budget and your tolerance for stretchiness.

Thanks for the insight! Coincidentally, I am working on a surgical suture simulator, and for my purposes the generated tether constraints are sufficient. Stiffness seems to be the the next hurdle at the moment.

Would you be able to recommend any additional iterative options I can work with through Obi, or perhaps an external resource that would be able to function in a scientific scenario such as surgical suturing? I appreciate any guidance you can send my way.

[josemendez]

Thanks for the insight! Coincidentally, I am working on a surgical suture simulator, and for my purposes the generated tether constraints are sufficient. Stiffness seems to be the the next hurdle at the moment.

Would you be able to recommend any additional iterative options I can work with through Obi, or perhaps an external resource that would be able to function in a scientific scenario such as surgical suturing? I appreciate any guidance you can send my way.

Tether constraints work based on the assumption that there's a fixed "reference point" in the rope, such that you can measure stretch relative to it. In Obi, these reference points are fixed particles, that are not simulated.

So thethers stablish a equation that relate free (simulated) particles to their closest fixed particles: "the free particle must not get further away from the fixed one than the lenght of rope between them", if that makes sense.

Unfortunately this requires that at least 1 particle in your rope is going to be fixed at all times, and that stretching in the rope always occurs in the direction opposite to that particle. In a surgical suture simulator this is not always true, so tethers may be of little help to you. The only thing left in your case is to increase the amount of distance constraint iterations, maybe crank up SOR factor to 1.5 (this is only used in emergency situations, to boost up the power of each iteration) and see if it's enough. If your thread bends/coils too easily, also increase bend constraint iterations.

Also, be aware that Obi does not consider twist/shear forces in the rope. Only stretch and bend are considered. This might be a hindrance for your purposes.

I can reccomend some research papers that have dwelved into this particular problem. However there's no commercial physics engine capable of simulating surgical thread at the required level of detail in realtime that I'm aware of.

This is probably the most appealing research work on the subject:
http://robotics.stanford.edu/~latombe/pa.../paper.pdf

They use a method known as alternating follow-the-leader (FTL) which guarantees zero stretch for simple cases. They also use capsule based collision detection for more robust knot making. They do not, however, calculate twist/shear either. Their work can be coupled with http://www.cg.informatik.uni-mainz.de/fi...t-Rods.pdf in case you absolutely need these.

[ploom]

Tether constraints work based on the assumption that there's a fixed "reference point" in the rope, such that you can measure stretch relative to it. In Obi, these reference points are fixed particles, that are not simulated.

So thethers stablish a equation that relate free (simulated) particles to their closest fixed particles: "the free particle must not get further away from the fixed one than the lenght of rope between them", if that makes sense.

Unfortunately this requires that at least 1 particle in your rope is going to be fixed at all times, and that stretching in the rope always occurs in the direction opposite to that particle. In a surgical suture simulator this is not always true, so tethers may be of little help to you. The only thing left in your case is to increase the amount of distance constraint iterations, maybe crank up SOR factor to 1.5 (this is only used in emergency situations, to boost up the power of each iteration) and see if it's enough. If your thread bends/coils too easily, also increase bend constraint iterations.

Also, be aware that Obi does not consider twist/shear forces in the rope. Only stretch and bend are considered. This might be a hindrance for your purposes.

I can reccomend some research papers that have dwelved into this particular problem. However there's no commercial physics engine capable of simulating surgical thread at the required level of detail in realtime that I'm aware of.

This is probably the most appealing research work on the subject:
http://robotics.stanford.edu/~latombe/pa.../paper.pdf

They use a method known as alternating follow-the-leader (FTL) which guarantees zero stretch for simple cases. They also use capsule based collision detection for more robust knot making. They do not, however, calculate twist/shear either. Their work can be coupled with http://www.cg.informatik.uni-mainz.de/fi...t-Rods.pdf in case you absolutely need these.

I appreciate the references, I will take a close look at those.

As for the project, I would like to clarify that the device in my suture simulator is not the classic hook-shaped needle and suture you see in simulators (ie. Lapsim from Surgical Science). The needle will always be in a fixed position on the device, which has a pinned particle of the suture attached to it. This particle does not need to move or be removed from the needle at any point.

That being said, unless I misunderstood or am overlooking something down the line, the generated tether constraints are working nicely in terms of minimizing stretching to a negligible amount - in addition to distance constraints being set at 30. Not sure if having both compound the reduced stretching or if I'm wasting resources here.

Another issue I have found is fast-moving colliders seem to phase through the suture with no collisions being detected. If I move slowly, however, I get the results that are expected. Resolution is set at max and collision constraint iterations is at 30. It seems making the colliders larger sort of works, I am just curious if there is another alternative that can allow me to use smaller colliders on an object that will be manipulating the suture.

Thanks for the all the help so far.