Help Some questions & requests

[josemendez]

When I’m spawning a fresh one (coming from Instantiate) it works just fine. But if it is coming from the pool (a disabled object in the scene) the attachment works, but the rope is misplaced.If I do the usual Instantiate/Destroy it works just fine as well. So I was assuming the problem is with re-attaching ropes, but I should have mention that it is not exactly the case.

Hi again!

Not sure what you mean by "misplaced": during simulation, ropes don't really have a position/orientation (for obvious reasons, each particle can be in a completely different position). How can it be misplaced? do you mean the initial transform? are the particles not attached to the positions you set?

Yes, that’s precisely the case.  The ropes are very stretchy because they are attached to heavy objects.

A simple solution is to increase the mass of the rope particles. You can set mass per-control point in the path editor.
Note that iterative, maximal coordinates-based engines (which account for pretty much all realtime engines) have issues with large mass ratios. You can check this in Unity by simply placing a 10000 kg box on top of a 1 kg box and watch it explode .

If you want resilience against arbitrarily large mass ratios, you must use either a direct solver, or a reduced-coordinates approach (Featherstone's ABA is a good candidate). Both are considerably more expensive than Obi. Unity provides a built in reduced-coordinates solver in the form of articulations.

Tried everything but it’s still not working when it comes from the pool.

I'm still not sure what you mean by "not working": you mention the attachment itself works ok but the rope is misplaced, can you show an example of this?

If you see in the official Unity’s documentation about changing Time.timeScale: https://docs.unity3d.com/ScriptReference...Scale.html
They do like this:

Code:

if (Time.timeScale == 1.0f)
    Time.timeScale = 0.7f;
else
    Time.timeScale = 1.0f;
// Adjust fixed delta time according to timescale
// The fixed delta time will now be 0.02 real-time seconds per frame
Time.fixedDeltaTime = this.fixedDeltaTime * Time.timeScale;

This is just a terrible idea, regardless of it being in Unity's official docs. What this does is it scales down the duration of the physics step so that the amount of steps per frame are constant. This will alter the physical behavior of objects depending on the timescale, which is something you want to avoid: when in slow motion, joints will become stiffer, contacts snappier, etc. My advice would be to only do this when recording an in-game video for instance, but never during gameplay.

What you typically want is for physical behavior to remain constant regardless of the timescale, and interpolate render state in-between.

And that’s what I’m doing as well, because only changing the Time.timeScale without changing Time.fixedDeltaTime makes the physics based objects have a not very smooth slow motion.

That's what physics state interpolation is for! both Unity rigidbodies and Obi solvers have an interpolation option that smoothes out physics. When you reduce the timescale, in-game time goes slower, however real-world time does not so the physics engine is stepped less often. In order to render something during the frames where the physics engine is not updated, the engine can smoothly interpolate between the current and the previous physics state.

See:
http://obi.virtualmethodstudio.com/manua...olver.html
https://docs.unity3d.com/ScriptReference...ation.html

If you want to learn more about fixed timestepping and interpolation, I can recommend this article:
https://gafferongames.com/post/fix_your_timestep/

Yes, this is what I’m doing:

Code:

_ropeReturnTween = DOVirtual.Float(_rope.Length, 0f, 0.1f, UpdateRopeLength);
void UpdateRopeLength(float value) => _rope.SetLength(value);

The only thing I have inside the SetLength is:

Code:

_cursor.ChangeLength(Mathf.Min(length, _maxLength));

So basically, a tween transition from the rope’s restLength to 0 with a duration of 0.1 seconds. Sometimes, not always, doing it triggers this mentioned ArgumentOutOfRange exception.

Thanks! will try to reproduce it and get back to you.