Help Saving Rope State

[emreaa]

Hi,

I stumbled upon this thread; http://obi.virtualmethodstudio.com/forum...d-652.html
But I'm unable to locate "Set Rest State" neither on Rope Inspector nor on Solver  and  edit path tool as you can see in the images. I'm using version 5.1 by the way.
Inspector Screenshots
Thanks in advance. Have a good day!

[josemendez]

Hi!

That post is quite old, from before the blueprints era (version 3.X). Check this other one out, might help you:
http://obi.virtualmethodstudio.com/forum...p?tid=2201

[emreaa]

Thanks for the reply, solution here works perfectly in my case as well!

[emreaa]

Hi again,

I have a follow-up question, I got my rope pinned dynamically to a rigidbody which has a series of configurable joints in a ragdoll setup. Idea is basically create a puppet which can be controlled by attached ropes. Problem is whenever I move the rope away from the connected rigidbody it separates/breaks contact from it as the rope tries to carry rigidbody upwards. To eliminate this behavior I tried setting the pinned particle inside of the attached object. made sure obi collider has the same phase to eliminate these 2 colliding with each other and cranked up the pin constraint iterations as high as I can but I'm unable to prevent this separation/breaking contact between pinned particle and targeted transform/rigidbody. Any suggestions regarding how to solve this?

[josemendez]

Hi again,

I have a follow-up question, I got my rope pinned dynamically to a rigidbody which has a series of configurable joints in a ragdoll setup. Idea is basically create a puppet which can be controlled by attached ropes. Problem is whenever I move the rope away from the connected rigidbody it separates/breaks contact from it as the rope tries to carry rigidbody upwards. To eliminate this behavior I tried setting the pinned particle inside of the attached object. made sure obi collider has the same phase to eliminate these 2 colliding with each other and cranked up the pin constraint iterations as high as I can but I'm unable to prevent this separation/breaking contact between pinned particle and targeted transform/rigidbody. Any suggestions regarding how to solve this?

Hi there,

I don't really understand the question, what do you mean by the rope "breaking contact" with the collider? can you share a screenshot?

[emreaa]

Hi there,

I don't really understand the question, what do you mean by the rope "breaking contact" with the collider? can you share a screenshot?

https://imgur.com/a/4N29ICl

The rope in the screenshot is attached to the yellow object at its upper most particle with a dynamic particle attachment and that particle is placed in the yellow object, their colliders (both particle and the yellow object) has the same phase so that they dont collide. But when the rope moves, it's end separates from the object just like in the screenshot. Also the yellow object in the screenshot has rigidbody and obi rigidbody and the other and of the rope is attached to an object with a static particle attachment. Is the any way to avoid this?

[josemendez]

https://imgur.com/a/4N29ICl

The rope in the screenshot is attached to the yellow object at its upper most particle with a dynamic particle attachment and that particle is placed in the yellow object, their colliders (both particle and the yellow object) has the same phase so that they dont collide. But when the rope moves, it's end separates from the object just like in the screenshot. Also the yellow object in the screenshot has rigidbody and obi rigidbody and the other and of the rope is attached to an object with a static particle attachment. Is the any way to avoid this?

Hi,

I assume you're using a FixedUpdater and not a LateUpdater, right?

A slight separation will always exist regardless of what kind of updater you use, but in LateUpdater it would be more pronounced due to variable time stepping.

Constraints (such as the pin constraints created by a dynamic attachment) are "reactive": only when there's a slight separation between the current particle position and the position it is supposed to be, does the constraint apply a force to the particle. If you're pulling the rope from the other end with a static attachment (which simply sets the particle position every step), the constraint will apply a force to both the rope and the rigidbody to held them together at the attachment point, but won't instantaneously snap them together. This is just how iterative physics solvers work (pretty much all realtime engines).

You could increase the amount of pin constraint iterations, and/or use more substeps. This will reduce the separation, but will never completely eliminate it.

Anyway, this should be a very slight separation, not the huge gap in your screenshot. I can't tell for sure if that's the cause, or something entirely different.

[emreaa]

Hi,

I assume you're using a FixedUpdater and not a LateUpdater, right?

A slight separation will always exist regardless of what kind of updater you use, but in LateUpdater it would be more pronounced due to variable time stepping.

Constraints (such as the pin constraints created by a dynamic attachment) are "reactive": only when there's a slight separation between the current particle position and the position it is supposed to be, does the constraint apply a force to the particle. If you're pulling the rope from the other end with a static attachment (which simply sets the particle position every step), the constraint will apply a force to both the rope and the rigidbody to held them together at the attachment point, but won't instantaneously snap them together. This is just how iterative physics solvers work (pretty much all realtime engines).

You could increase the amount of pin constraint iterations, and/or use more substeps. This will reduce the separation, but will never completely eliminate it.

Anyway, this should be a very slight separation, not the huge gap in your screenshot. I can't tell for sure if that's the cause, or something entirely different.

Thank you, your suggestions alleviated the problem to an acceptable degree for me. And working around distance and pin constraint iterations (lowering distance and increasing pin for this case) has helped also I guess. I have one more question, the last one hopefully, I implemented the prewarm feature earlier thanks to the post you shared earlier, but with that GenerateImmediate function commented out I lose all control in terms of editing the rope via blueprint and edit path, control point editing is not a must have even though it's good to have but I cannot change rope thickness (or rope resolution) via blueprint(not control points, but the rope as a whole) and that's challenging terms of workflow. If I uncomment GenerateImmediate I lose my saved states across the project even in unopened scenes. Is there any way to circumvent this?

[josemendez]

Thank you, your suggestions alleviated the problem to an acceptable degree for me. And working around distance and pin constraint iterations (lowering distance and increasing pin for this case) has helped also I guess. I have one more question, the last one hopefully, I implemented the prewarm feature earlier thanks to the post you shared earlier, but with that GenerateImmediate function commented out I lose all control in terms of editing the rope via blueprint and edit path, control point editing is not a must have even though it's good to have but I cannot change rope thickness (or rope resolution) via blueprint(not control points, but the rope as a whole) and that's challenging terms of workflow. If I uncomment GenerateImmediate I lose my saved states across the project even in unopened scenes. Is there any way to circumvent this?

Hi emreaa,

It's true that calling GenerateImmediate in OnValidate() prevents manual assignment of blueprints, since they get re-generated when you drag them to the rope in-editor. Commenting the line out however, prevents them from being regenerated when needed. I've yet to find a good solution for this, as Unity calls OnValidate() in situations where it shouldn't as far as I know.

Restoring the GenerateImmediate() call and assigning the new blueprint programmatically (instead of trough the editor) should circumvent this as its OnValidate() method would not be called at any point.