Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Delay in Rope Pulling
#1
We have a classic crane setup where rope one end is attached (static) with pully at top and the other end is attached with load (dynamic with obi rigidbody and collider). Load is lifted by increasing and decreasing the rope length using the cursor.

We are facing a problem when load and rope are stable and at rest, there is a small delay in pulling up the load (specially when its grounded). It starts pulling the rope after noticeable delay sometimes more than 1-2 seconds.

Is it possible the length of rope is quite large and its taking sometime? how we can improve this?
Reply
#2
(25-04-2023, 08:28 AM)vrtraining Wrote: We have a classic crane setup where rope one end is attached (static) with pully at top and the other end is attached with load (dynamic with obi rigidbody and collider). Load is lifted by increasing and decreasing the rope length using the cursor.

We are facing a problem when load and rope are stable and at rest, there is a small delay in pulling up the load (specially when its grounded). It starts pulling the rope after noticeable delay sometimes more than 1-2 seconds.

Is it possible the length of rope is quite large and its taking sometime? how we can improve this?

Hi!

Chances are the rope is simply being stretched too much (you can check this by adding a ObiParticleRenderer component to the rope to take a look at its particles). This can happen if:

- The rope is very long and/or rope resolution is very high.
- The mass ratio between the rope and the load is very large (that is, the load is a lot heavier than the rope). As in all iterative physics engines, large mass ratios will  negatively affect convergence, causing spurious/unwanted stretching.

The potential solutions are the same as in most physics engines:

- Increase temporal resolution: in Obi you can easily do this by increasing the amount of substeps (you can find this setting in the ObiFixedUpdater component). The manual contains a very in-depth explanation of how the engine works internally and how substeps/iterations affect output quality:
http://obi.virtualmethodstudio.com/manua...gence.html

- Reduce spatial resolution: select your rope's blueprint, and reduce its "resolution" setting. This will create less particles per unit length, reducing the amount of work the solver has to do and allowing the simulation to converge faster.

- Reduce the mass ratio between the rope and the load: either make the rope heavier (you can control mass per control point in the path editor) or make the load lighter.

You can combine all 3 techniques in any way you see fit. Let me know if I can be of further help,

kind regards,
Reply
#3
(25-04-2023, 08:56 AM)josemendez Wrote: Hi!

Chances are the rope is simply being stretched too much (you can check this by adding a ObiParticleRenderer component to the rope to take a look at its particles). This can happen if:

- The rope is very long and/or rope resolution is very high.
- The mass ratio between the rope and the load is very large (that is, the load is a lot heavier than the rope). As in all iterative physics engines, large mass ratios will  negatively affect convergence, causing spurious/unwanted stretching.

The potential solutions are the same as in most physics engines:

- Increase temporal resolution: in Obi you can easily do this by increasing the amount of substeps (you can find this setting in the ObiFixedUpdater component). The manual contains a very in-depth explanation of how the engine works internally and how substeps/iterations affect output quality:
http://obi.virtualmethodstudio.com/manua...gence.html

- Reduce spatial resolution: select your rope's blueprint, and reduce its "resolution" setting. This will create less particles per unit length, reducing the amount of work the solver has to do and allowing the simulation to converge faster.

- Reduce the mass ratio between the rope and the load: either make the rope heavier (you can control mass per control point in the path editor) or make the load lighter.

You can combine all 3 techniques in any way you see fit. Let me know if I can be of further help,

kind regards,

Thanks for the detailed response with possible solutions, do you have any idea about a good mass ratio? currently particle mass is default 0.1 and load varies between 20-30KG
Reply
#4
(25-04-2023, 09:04 AM)vrtraining Wrote: Thanks for the detailed response with possible solutions, do you have any idea about a good mass ratio? currently particle mass is default 0.1 and load varies between 20-30KG

The typical maximum mass ratio in most physics engines is 10. Unity used to recommend this value in its own documentation. Yours is currently 0.1/20 = 200, so either increase particle mass to at least 2 kg or reduce load mass to around 1 kg.

Note you can spend more substeps to improve convergence (that is, reduce spurious stretching) and reach higher mass ratios that way.

In case you require much larger mass ratios, you'll need to ditch both Obi and Unity's built-in physics engine and switch to an entire different kind of physics solver, namely a direct one or a reduced-coordinates based one. Both are common in engineering environments, albeit much costlier in terms of performance than the iterative, maximal-coordinate solvers typically used in games. A good engine using direct solvers is AgX Dynamics, they used to provide a Unity plugin - not sure what their status is currently.

kind regards,
Reply
#5
(25-04-2023, 09:09 AM)josemendez Wrote: The typical maximum mass ratio in most physics engines is 10. Unity used to recommend this value in its own documentation. Yours is currently 0.1/20 = 200, so either increase particle mass to at least 2 kg or reduce load mass to around 1 kg.

Note you can spend more substeps to improve convergence (that is, reduce spurious stretching) and reach higher mass ratios that way.

Thanks, will try that now
Reply