Speed Up Rope Tracing Attactchment?

[Renman3000]

Hi there, 
I have a rope with everything works fine but my effector, or particle attachment is a little ahead of the end of the rope, or vice versa, the end of the rope is just a frame or two behind the currect effector position. 

How can I speed the rope tracing up a tad?

[josemendez]

Hi there, 
I have a rope with everything works fine but my effector, or particle attachment is a little ahead of the end of the rope, or vice versa, the end of the rope is just a frame or two behind the currect effector position. 

How can I speed the rope tracing up a tad?

Hi!

Depends on what kind of attachment you're using (static or dynamic) and how/when you're updating the effector/object attached to it. Could you give more info about what you're trying to do?

kind regards,

[Renman3000]

Hi!

Depends on what kind of attachment you're using (static or dynamic) and how/when you're updating the effector/object attached to it. Could you give more info about what you're trying to do?

kind regards,

Hi thanks!
So the Particle Attachment is set to Static. 
And In Update, I am moving the effector position, relative to the body. 
Also, it should be noted the effector has a sphere renderer in it set to localPostion zero. This is where I notice the tracking issue, as the sphere of the effector is slightly ahead of the end of the rope, by a frame or two. 

So, let me explain my game. 

Imagine an octopus and the tentacle is the Obi Rope. To keep a consistent look as the player octopus moves, the effector, which is the second and last, Particle Attachment (where the first is the body), moves to a position offset to the body. This way his tentacles are localized to himself as he moves about. This is great, but that said, he moves pretty quickly and as mentioned there seems to be a slight mis step between the two positions.  

I was using Leap, on the effector (particle attachment), where step = time.deltaTime * 100, even step = 1.


If I am using Update, Lerp, is this the most accurate?

[Renman3000]

Hi!

Depends on what kind of attachment you're using (static or dynamic) and how/when you're updating the effector/object attached to it. Could you give more info about what you're trying to do?

kind regards,

Bump

[josemendez]

Hi thanks!
So the Particle Attachment is set to Static. 
And In Update, I am moving the effector position, relative to the body. 

Hi!

Physics in Unity (including rope physics) are updated in FixedUpdate(), which takes place before Update(). See:
https://docs.unity3d.com/Manual/ExecutionOrder.html

If you move the effector in Update(), you're moving it after the rope has been updated. This means there will always be a 1-frame delay in the position of the rope relative to the effector, since the rope has no chance to update the attachment position until the next FixedUpdate() if you move the effector in Update().

You must move the effector before physics are updated. You can do this easily by subscribing to the solver's OnBeginStep event: http://obi.virtualmethodstudio.com/manua...olver.html

kind regards,

[Renman3000]

Hi!

Physics in Unity (including rope physics) are updated in FixedUpdate(), which takes place before Update(). See:
https://docs.unity3d.com/Manual/ExecutionOrder.html

If you move the effector in Update(), you're moving it after the rope has been updated. This means there will always be a 1-frame delay in the position of the rope relative to the effector, since the rope has no chance to update the attachment position until the next FixedUpdate() if you move the effector in Update().

You must move the effector before physics are updated. You can do this easily by subscribing to the solver's OnBeginStep event: http://obi.virtualmethodstudio.com/manua...olver.html

kind regards,

Ok, thanks.

So upon further inspection i think the issue for me is that (since the effector has a renderer) the particle attachment of the rope, tied to the connector, is slightly behind the effector position, or the renderering itslef, of the rope is slightly behind. 


Assuming I am moving my effector in FixedUpdate, is there a way I can speed up the particle attachemnt, in tracing the pos of the effector?

[josemendez]

Ok, thanks.

So upon further inspection i think the issue for me is that (since the effector has a renderer) the particle attachment of the rope, tied to the connector, is slightly behind the effector position, or the renderering itslef, of the rope is slightly behind. 

Assuming I am moving my effector in FixedUpdate, is there a way I can speed up the particle attachemnt, in tracing the pos of the effector?

Hi!

"tracing" as you call it is instant, there's no way to speed it up. Every FixedUpdate(), all rope particles attached to an object are set to the position they're attached to relative to the object. As long as the object is at its final position for that frame when the rope is updated, there will be no delay / gaps.

Also note that moving the effector in FixedUpdate() won't fix anything. It has to be moved before the rope simulation takes place in FixedUpdate(). That's why using one of the solver callbacks, or using a different ObiUpdater component to update the rope are the only robust solutions.

[Renman3000]

Hi!

"tracing" as you call it is instant, there's no way to speed it up. Every FixedUpdate(), all rope particles attached to an object are set to the position they're attached to relative to the object. As long as the object is at its final position for that frame when the rope is updated, there will be no delay / gaps.

Also note that moving the effector in FixedUpdate() won't fix anything. It has to be moved before the rope simulation takes place in FixedUpdate(). That's why using one of the solver callbacks, or using a different ObiUpdater component to update the rope are the only robust solutions.

Hmm... ok... I think I may remove the renderer from the effector and create a secondary transform renderer which will trace the position of the effector as well, but see if i can slow the pace so the renderer appears correct. 

Thank you

[josemendez]

Hmm... ok... I think I may remove the renderer from the effector and create a secondary transform renderer which will trace the position of the effector as well, but see if i can slow the pace so the renderer appears correct. 

Hi,

I think either one of us is misunderstanding the issue. A transform having a renderer or not doesn't matter in this case, anything drawn by the renderer will be drawn at the current position of the transform - i other words, the mesh and the transform can't get out of sync. So having a secondary transform won't be of any use.

Have you tried my suggestion of moving the effector transform in the solver's callback events (either OnBeginStep or OnPrepareFrame) instead of Update()?

let me know whether this helps!

kind regards,