Help Fishing Pole/Line

[Natty]

Hi!

The entire Obi/Samples folder can be removed.

I wouldn't recommend removing the Burst backend since it would require modifying multiple source files that assume the backend actually exists. Moreover, the source files for the burst backend are just plain text so they don't take up much space.

Awesome, thanks Jose.

[Natty]

Hi Jose,

Can you give me some tips on how to get the rope to be a little less elastic? And for the bobber to not rotate sideways and sort of "float" there unrealistically?  I have tried increasing the Substeps, and I've messed around with the bobber's rb mass, but I can't figure it out.  I also did increase both control point masses from 0.1 to 1 and played with that for a bit, I think it did help slightly, but I'm still struggling here.

https://streamable.com/cfeu7g
https://streamable.com/zlhhyf


Thank you!

[josemendez]

Hi Jose,

Can you give me some tips on how to get the rope to be a little less elastic? And for the bobber to not rotate sideways and sort of "float" there unrealistically?  I have tried increasing the Substeps, and I've messed around with the bobber's rb mass, but I can't figure it out.  I also did increase both control point masses from 0.1 to 1 and played with that for a bit, I think it did help slightly, but I'm still struggling here.

https://streamable.com/cfeu7g
https://streamable.com/zlhhyf


Thank you!

Hi Natty!

There's a couple important issues with your setup:

1) In your first video I see you're using 25 (!) distance constraint iterations but only 6 substeps. This will dampen dynamics a lot, and cost a lot in terms of performance since your rope's constraints are being enforced a whooping 25x6 = 150 times per step.

Using 10-20 substeps and only 1 iteration would yield less stretchy rope that's both a lot more lively and a lot cheaper cheaper (10-20 updates instead of 150). As indicated in the manual, you should always prefer using substeps to iterations. Only use iterations to increase the relative importance of specific constraints.

2) Your solver is placed inside the fishing rod (which is rotated) and its gravity space set to self. This means the direction of gravity will rotate along with your rod which is definitely not what you want. Set the gravity space to world instead, to set gravity in world space instead of the rod's local space. This will get rid of the weird arc the rope does and the strangely rotated bobber.

See: http://obi.virtualmethodstudio.com/manua...olver.html

let me know if I can be of further help.

kind regards,

[Natty]

Hi Natty!

There's a couple important issues with your setup:

1) In your first video I see you're using 25 (!) distance constraint iterations but only 6 substeps. This will dampen dynamics a lot, and cost a lot in terms of performance since your rope's constraints are being enforced a whooping 25x6 = 150 times per step.

Using 10-20 substeps and only 1 iteration would yield less stretchy rope that's both a lot more lively and a lot cheaper cheaper (10-20 updates instead of 150). As indicated in the manual, you should always prefer using substeps to iterations. Only use iterations to increase the relative importance of specific constraints.

2) Your solver is placed inside the fishing rod (which is rotated) and its gravity space set to self. This means the direction of gravity will rotate along with your rod which is definitely not what you want. Set the gravity space to world instead, to set gravity in world space instead of the rod's local space. This will get rid of the weird arc the rope does and the strangely rotated bobber.

See: http://obi.virtualmethodstudio.com/manua...olver.html

let me know if I can be of further help.

kind regards,

Hi Jose,

Thank you.  This helped a lot.  Still tweaking things a bit, but I want to spend some more time with it and write something up with details before asking you again. One thing I did come across though is that the method I am using to reset the fishing line is:

Code:

fishingPoleInHandCursor.ChangeLength(ropeRestLength);

I'm calling this in Update().  What I noticed is that this causes the rope to violently retract spinning erratically around in circles until it's back to its original length.  Is there a way to simply have this reset without needing it to even display that it's shortening?  Or is there a way to do it slower so that it doesn't wildly lose control?  Possibly my code is just wrong.

Still a lot for me to learn but I think I'm starting to come to terms with Obi Rope, it really is amazing how flexible it is.

Thank you!

[josemendez]

Code:

fishingPoleInHandCursor.ChangeLength(ropeRestLength);

I'm calling this in Update().  What I noticed is that this causes the rope to violently retract spinning erratically around in circles until it's back to its original length.  Is there a way to simply have this reset without needing it to even display that it's shortening?  Or is there a way to do it slower so that it doesn't wildly lose control?  Possibly my code is just wrong.

Hi Natty!

Your code is fine, it's just that changing the length of the rope to its rest length all of a sudden will of course cause it to spring back will quite some force.

Imagine if you had a box hanging from the ceiling by a 4 meter rope. Then the rope gets its length magically and instantly changed to 2 meters while still being attached to both the ceiling and the box: assuming an unbreakable rope, the rope would pull the box up at top speed (or the ceiling down, depending on build quality). Then inertia would cause the rope to swing around for a while.

A quick and dirty workaround would be to temporally set the solver's damping value to a very high value like 0.98, change the length, then set the damping back to whatever it was after a second or so. Damping causes energy to "evaporate", so the rope would go back to its original length slowly.

An proper solution would involve moving whatever objects the rope is attached to a distance equal to or smaller than the rope's length, change rope length,
and then (depending on where your cursor is located along the rope) move all its particles to a position that minimizes energy.

kind regards,

[Natty]

Hi Natty!

Your code is fine, it's just that changing the length of the rope to its rest length all of a sudden will of course cause it to spring back will quite some force.

Imagine if you had a box hanging from the ceiling by a 4 meter rope. Then the rope gets its length magically and instantly changed to 2 meters while still being attached to both the ceiling and the box: assuming an unbreakable rope, the rope would pull the box up at top speed (or the ceiling down, depending on build quality). Then inertia would cause the rope to swing around for a while.

A quick and dirty workaround would be to temporally set the solver's damping value to a very high value like 0.98, change the length, then set the damping back to whatever it was after a second or so. Damping causes energy to "evaporate", so the rope would go back to its original length slowly.

An proper solution would involve moving whatever objects the rope is attached to a distance equal to or smaller than the rope's length, change rope length,
and then (depending on where your cursor is located along the rope) move all its particles to a position that minimizes energy.

kind regards,

Hi Jose,

I seem to be struggling with this all quite a lot. I'm wondering if just restarting would be better, or if you can point me a direction. I am still using the settings described before in this post (with your suggestions added).  The rope itself is still way too "springy" and overall just out of control.  I also noticed at times that the rope "disconnects" from the bobber where it is attached, like there's a small gap of space there sometimes.

My idea was to use Obi Rope, play an animation to wind up / pull back the fishing pole, then on the animation for casting forwards, apply a forward force to the bobber and increase Obi Rope length at the same time.  Although I am getting this halfway working, the rest of it all is just a mess in terms of the rope spinning out of control and overall just how bouncy/springy it is.  I am happy to post up settings and details again if needed.

I may just need to spend more time and it's possible I'm tired today, but I am starting to feel defeated here.

Edit: In addition to the above, I can't get a semi-realistic hanging bobber. For some reason the bobber when hanging from the rope, dangles in strange ways. It almost looks like the mass is not being applied to the bottom part of the bobber. So I set the rigidbody's center of mass to the bottom part of the bobber, but that still didn't make a difference. Sometimes when running around the bobber flips upside down and almost looks like it's floating a bit. Yet gravity and mass is applied. I just want it to swing/hang properly as you would expect with a heavier object hanging from a rope. It's like the red upper part of the bobber where the rope connects is what's controlling how the bobber moves, and the center of mass at the white bottom part of the bobber is just not being counted.

[josemendez]

Hi Natty,

The rope itself is still way too "springy" and overall just out of control. 

Springyness can be reduced by using more substeps, it cannot be completely eliminated though as it would require to use infinite substeps. This is not a quirk specific to Obi, it's just how physics engines work: time is chopped up into small "steps", during each step all quantities are linearized which means objects cannot change direction or moving speed within the step. If a rope is moving fast enough, and/or has enough mass (both affect inertia) it will spring back slightly once it reaches its max length.

This is also why if you create a tall enough stack of boxes in any engine, they will slightly penetrate each other. The longer the timestep, and the taller the stack, the more "springy" collision response will be.

Still, even moderate settings in Obi should yield useable results in this regard. I'm only using 10 substeps for a thin 10 meter long rope, it's quite snappy and really stable:

I also noticed at times that the rope "disconnects" from the bobber where it is attached, like there's a small gap of space there sometimes.

Dynamic attachments are constraints, which mean they work by applying forces on both the bobber and the rope (as opposed to static attachments, which just set the rope's position kinda like a parent-child relationship). Since time is discrete (see my first paragraph) this can mean the bobber can only move in a straight line within each physics timestep. This may or may not be enough to match its position with the rope during violent motion. You can see this in the video above too, when I flick the rope around randomly.

A simple solution to get rid of the visual gap would be to just move the end particle to the attachment position every frame. You'd be trading the gap for a slightly crooked look at the end of the rope. This is akin to what the "projection mode" in rigidbody joints do: snap the position of the rigidbodies even if it's physically incorrect, to try and hide gaps. Should be a simple thing to write, in fact I believe I have some sample code around that does this. Let me look for it and get back to you.

My idea was to use Obi Rope, play an animation to wind up / pull back the fishing pole, then on the animation for casting forwards, apply a forward force to the bobber and increase Obi Rope length at the same time.  Although I am getting this halfway working, the rest of it all is just a mess in terms of the rope spinning out of control and overall just how bouncy/springy it is.  I am happy to post up settings and details again if needed.

Not sure what you mean by "spinning out of control", that sounds weird. Position-based dynamics (the framework used by Obi) is generally very stable and well-behaved even under extreme conditions. Could you share a video of this behavior?

Edit: In addition to the above, I can't get a semi-realistic hanging bobber. For some reason the bobber when hanging from the rope, dangles in strange ways. It almost looks like the mass is not being applied to the bottom part of the bobber. So I set the rigidbody's center of mass to the bottom part of the bobber, but that still didn't make a difference. Sometimes when running around the bobber flips upside down and almost looks like it's floating a bit. Yet gravity and mass is applied. I just want it to swing/hang properly as you would expect with a heavier object hanging from a rope.

Did some tests with center of mass (above video) but results look ok to me. Never had any issues reported regarding center of mass tbh. The rope mass I used is 0.01 kg per particle and the bobber is 0.1 kg, so a mass ratio of 1:10 which is about the recommended maximum for an iterative engine.

It's like the red upper part of the bobber where the rope connects is what's controlling how the bobber moves, and the center of mass at the white bottom part of the bobber is just not being counted.

How have you changed the center of mass? Have you set a new position programmatically? (ie rigidbody.centerOfMass = whatever) or just placed a larger collider at the bottom?

In the video above I just placed a sphere at the bottom of the rigidbody to lower the CoM and relied on Unity to automatically calculate it.

Imho I guess the best course of action at this point is for me to take a look at the project itself, otherwise it's a lot of back and forth guesswork. Would this be possible?

kind regards,

[Natty]

Hi Natty,


Springyness can be reduced by using more substeps, it cannot be completely eliminated though as it would require to use infinite substeps. This is not a quirk specific to Obi, it's just how physics engines work: time is chopped up into small "steps", during each step all quantities are linearized which means objects cannot change direction or moving speed within the step. If a rope is moving fast enough, and/or has enough mass (both affect inertia) it will spring back slightly once it reaches its max length.

This is also why if you create a tall enough stack of boxes in any engine, they will slightly penetrate each other. The longer the timestep, and the taller the stack, the more "springy" collision response will be.

Still, even moderate settings in Obi should yield useable results in this regard. I'm only using 10 substeps for a thin 10 meter long rope, it's quite snappy and really stable:




Dynamic attachments are constraints, which mean they work by applying forces on both the bobber and the rope (as opposed to static attachments, which just set the rope's position kinda like a parent-child relationship). Since time is discrete (see my first paragraph) this can mean the bobber can only move in a straight line within each physics timestep. This may or may not be enough to match its position with the rope during violent motion. You can see this in the video above too, when I flick the rope around randomly.

A simple solution to get rid of the visual gap would be to just move the end particle to the attachment position every frame. You'd be trading the gap for a slightly crooked look at the end of the rope. This is akin to what the "projection mode" in rigidbody joints do: snap the position of the rigidbodies even if it's physically incorrect, to try and hide gaps. Should be a simple thing to write, in fact I believe I have some sample code around that does this. Let me look for it and get back to you.


Not sure what you mean by "spinning out of control", that sounds weird. Position-based dynamics (the framework used by Obi) is generally very stable and well-behaved even under extreme conditions. Could you share a video of this behavior?


Did some tests with center of mass (above video) but results look ok to me. Never had any issues reported regarding center of mass tbh. The rope mass I used is 0.01 kg per particle and the bobber is 0.1 kg, so a mass ratio of 1:10 which is about the recommended maximum for an iterative engine.


How have you changed the center of mass? Have you set a new position programmatically? (ie rigidbody.centerOfMass = whatever) or just placed a larger collider at the bottom?

In the video above I just placed a sphere at the bottom of the rigidbody to lower the CoM and relied on Unity to automatically calculate it.

Imho I guess the best course of action at this point is for me to take a look at the project itself, otherwise it's a lot of back and forth guesswork. Would this be possible?

kind regards,

Hi Jose,

As always, I sincerely appreciate the in-depth responses.  Here's a video of how my bobber is, along with some casting, but a lot of the casting issues is just my code at the moment, and probably needing some tweaks to the rope settings. Just wanted to give you an idea of the set up: https://streamable.com/fl6za5

My bobber just floats upside down like that when running around and doesn't react in a realistic way. The rope's mass is 0.1 at the two points that I have (one static at fishing rod tip and one dynamic at the tip of red stick).  The bobber in that video started with 0.1 mass and then I changed it to 1 mass to try to show a difference.

The sample code for patching the gap would be awesome.

For the center of mass I was setting it through code, but in the video I removed that and just used the red stick with the white sphere childed to it.

As for sharing the project for you to have a look, I'd certainly be interested, but I'm unsure of the best way to do it. I have a few other paid for assets in the project, so I'm a bit reluctant to give access to the private GitHub repo, since technically that would be a violation of the asset rights (as I'm sure you understand).  However, I would be down to jump on a Discord video share call or so? I'm also open to other ideas and/or what's easiest for you.

Thank you.

[Natty]

I am getting a little closer, but still struggling with:
(1) Bobber hanging realistically.
(2) The rope when reeling back in (when bobber touches ground) and it spinning so much.

I've tried to set the bobber position to the pole and then do the ChangeLength() but I wasn't quite getting it.

I will try again tomorrow, but just wanted to give an update: https://streamable.com/e80qvg

Thank you!