scripting ropes with pin constraints & tethers

[josemendez]

Hi Jose – 

Based on your suggestions, I've been attempting to fix all the problems I'm having, but nothing seemed to be helping. So I started to suspect that there was something more going on, and I thought it might be useful to build a test scene with a simple comparison between an normal ObiRope and the one I'm trying to script. 

For some reason, this forum won't let me attach either a Unity package or a zip file ("The type of file that you attached is not allowed" – is there some sort of trick?) so I've put it up on Dropbox (the package and the zipped package just in case – both are the same) – here's the link:

https://www.dropbox.com/sh/00ax1phu767el...CLb2a?dl=0

The package includes the scene (ropeComparison3), my script (ObiRopeScriptTest.cs), a prefab (Breeze) with an ObiAmbientForceZone and a simple script (Rotator.cs) to move the ropes around a bit.

As you'll see when you run the scene, the rope that I'm creating through my script is behaving nothing like one that that was built in the Unity editor. 

There are two ropes: the one to the left is the normal one, and the one to the right is the one I'm scripting. Each is pinned to an kinematic rigidbody at the top and a second rigidbody at the bottom. There are two solvers, one for each rope. 

The scripted rope has a much longer resting state than the normal rope. Why?

The normal rope has a Resolution of 0.25, which generates six particles. If I set the resolution of my scripted rope to 0.25, I get about 24 particles. To generate six particles, I had to lower the Resolution to 0.06. Why?

The scripted rope is much more jumpy when it's initialized. Why?

Each rope has its own solver. If I assign the same solver to both ropes, the scripted rope fails. Why?

Thanks again for all your help!

- pH

Hi there!

First thing that catches my eye is that your scripted rope's spline already has some control points (CPs for short) created in the editor, but you're adding more trough scripting. So the resulting rope is of course longer. Changing the code in ObiRopeScriptTest.cs to this:

Code:

path.controlPoints.Clear();
path.controlPoints.Add(localStart+(localStart-localEnd));
path.controlPoints.Add(localStart);
path.controlPoints.Add(localEnd);
path.controlPoints.Add(localEnd+(localEnd-localStart));

makes things all better . What I'm doing here is first clearing the CP list (so that we start with a fresh spline, instead of appending additional CPs to the existing ones), then adding 4 cps: first tangent handle, first control point, second control point, second tangent handle. As pointed out in http://obi.virtualmethodstudio.com/forum...hp?tid=233, splines mathematically require duplicated endpoints to control curvature, so the minimum amount of CPs to create a meaningful curve is always 4. You could use 2 or 3 points, but the resulting curve would be "collapsed" into a point.

As you can imagine, this also solves the issue regarding the amount of particles: a shorter rope needs less particles, so you can set the resolution back to 0.25. A rope with less particles has less constraints, so the convergence speed is the same for both ropes --> both have the same "stretchiness".

Also you'll see some minor differences in the way pin constraints are created: lowerPinObject B has a Y coordinate of -1.1, while lowerPinObjectA is at -1.0. ropeA's spline CPs are not exactly at the center of the upper/lower pin objects, so the pin constraints have been created with a non-zero offset value (that is, they pin the rope to points away from the pinObject's center). However the scripted rope creates the pin constraints with a offset of zero, so the behavior is slightly different.

Ironing out these small things yields twin ropes.