rope climbing

[Alexander34]

   
Hello again. I need to make it so that the rope, when playing on the player animation of climbing on it, realistically behaved with respect to the points of contact. Clearly on the attached screenshot. How can I implement this with your Asset in the least costly and simplest way? 
I can only think of creating a particle group on the fly, but that would be very costly

[josemendez]

Hello again. I need to make it so that the rope, when playing on the player animation of climbing on it, realistically behaved with respect to the points of contact. Clearly on the attached screenshot. How can I implement this with your Asset in the least costly and simplest way? 
I can only think of creating a particle group on the fly, but that would be very costly

Why would it be costly to create particle groups on the fly? they're a very small/simple object with a list of particles, and in the case of ropes they always contain just one index.

Code:

// Create the attachment:
var attachment = rope.gameObject.AddComponent<ObiParticleAttachment>();
attachment.attachmentType = ObiParticleAttachment.AttachmentType.Dynamic;
attachment.target = bodyA.transform;

// Create a particle group and use it in the attachment:
var group = ScriptableObject.CreateInstance<ObiParticleGroup>();
group.particleIndices.Add(particleIndex); // index of the particle in the rope
attachment.particleGroup = group;

You could also reuse the same particle group and just change the particle index: disable attachment, change particle index, re-enable attachment, in that order. This way you don't even have to allocate any memory at runtime, as you're reusing the same attachment/group.

There's another option too: note that dynamic attachments use pin constraints internally to couple particles and rigidbodies, so another option if you don't want to deal with groups/attachments is to create and manage your own pin constraints manually. Note this is a lower-level approach and considerably more complex. The manual contains information about how to create your own constraints at runtime: http://obi.virtualmethodstudio.com/manua...aints.html

There's also a "GrapplingHook" sample scene included that shows you how to create pin constraints at runtime, see Obi/Samples/RopeAndRod/SampleResources/Scripts/ExtendableGrapplingHook.cs

kind regards,

[Alexander34]

Why would it be costly to create particle groups on the fly? they're a very small/simple object with a list of particles, and in the case of ropes they always contain just one index.

Code:

// Create the attachment:
var attachment = rope.gameObject.AddComponent<ObiParticleAttachment>();
attachment.attachmentType = ObiParticleAttachment.AttachmentType.Dynamic;
attachment.target = bodyA.transform;

// Create a particle group and use it in the attachment:
var group = ScriptableObject.CreateInstance<ObiParticleGroup>();
group.particleIndices.Add(particleIndex); // index of the particle in the rope
attachment.particleGroup = group;

You could also reuse the same particle group and just change the particle index: disable attachment, change particle index, re-enable attachment, in that order. This way you don't even have to allocate any memory at runtime, as you're reusing the same attachment/group.

There's another option too: note that dynamic attachments use pin constraints internally to couple particles and rigidbodies, so another option if you don't want to deal with groups/attachments is to create and manage your own pin constraints manually. Note this is a lower-level approach and considerably more complex. The manual contains information about how to create your own constraints at runtime: http://obi.virtualmethodstudio.com/manua...aints.html

There's also a "GrapplingHook" sample scene included that shows you how to create pin constraints at runtime, see Obi/Samples/RopeAndRod/SampleResources/Scripts/ExtendableGrapplingHook.cs

kind regards,

Thanks, it's roughly clear how I can make the particles between two groups of particles stationary, as in the screenshot in the hat. So that we hold on to the rope with our hands and this segment all the way down to our feet is stretched out of physics?
I'm also wondering how to exclude rope collisions with a player's capsule collider but not ignore collisions, e.g. with ground

[josemendez]

Thanks, it's roughly clear how I can make the particles between two groups of particles stationary, as in the screenshot in the hat. So that we hold on to the rope with our hands and this segment all the way down to our feet is stretched out of physics?

Just set the particle's inverse mass to zero, this will disable physics for them. Then override their position with your own calculations.

I'm also wondering how to exclude rope collisions with a player's capsule collider but not ignore collisions, e.g. with ground

You can use collision filters for this. You can also calculate and set them at runtime, see the very bottom of this page: http://obi.virtualmethodstudio.com/manua...sions.html

kind regards,

[Alexander34]

Just set the particle's inverse mass to zero, this will disable physics for them. Then override their position with  your own calculations.


You can use collision filters for this. You can also calculate and set them at runtime, see the very bottom of this page: http://obi.virtualmethodstudio.com/manua...sions.html

kind regards,

The thing is that when I turn off the mass of a certain section of rope and reduce its length using _cursor.ChangeLength(_obiRope.restLength + lengthChange * Time.deltaTime);

Then instead of shrinking on both sides, it shrinks only on the side where all particles have mass greater than 0.

[josemendez]

The thing is that when I turn off the mass of a certain section of rope and reduce its length using _cursor.ChangeLength(_obiRope.restLength + lengthChange * Time.deltaTime);

Then instead of shrinking on both sides, it shrinks only on the side where all particles have mass greater than 0.

Where the rope shrinks from is determined by the cursor placement ("cursor mu") and direction. You can't have a rope shrink from both sides using a single cursor, btw. See:
http://obi.virtualmethodstudio.com/manua...ursor.html