First try feedback (v1.0.9)

[EnterUserNamePlease]

Hi!

First of all I want to thank you for your work! PrimeTween has every chance of becoming a top.
I had tried to migrate from DOTween and faced some functionality I miss in PrimeTween.

So here is my list:

1. SetSpeedBased() (plus, after the tween started I need to find out the duration, what DOTween can)
2. SetUpdateType (Normal/Fixed/LateUpdate)
3. Callbacks OnStart (I use this one for tweens with delay), OnUpdate
4. Scriptable Object with default settings (for example default ease, loop type, autokill)
5. DOPath

I use often all of this methods.
And as for DOPath, there is some issue in DOTween variant. If the distance between your waypoints is very different, the target will follow the path with no constant speed. So the more distance between points, the faster the speed is, but I need the target moves with the constant speed. This trouble is fixed for example in Bézier Path Creator by Sebastian Lague.

[KyryloKuzyk]

Huge thanks for the feedback! I'm glad you enjoy using PrimeTween!

SetSpeedBased() (plus, after the tween started I need to find out the duration, what DOTween can)

I already know how to add this feature seamlessly to PrimeTween, and will add it in the next version.
In the current version, it's already possible with a simple method like this:

public static Tween PositionWithSpeed([NotNull] Transform target, Vector3 endValue, float speed, Ease ease = Ease.Default) {
    Assert.IsTrue(speed > 0);
    var duration = Vector3.Distance(target.position, endValue) / speed;
    return Tween.Position(target, endValue, duration, ease);
}

SetUpdateType (Normal/Fixed/LateUpdate)

While adding this is totally possible, I don't currently understand the use cases.
FixedUpdate() is used for physics manipulations, like adding force. But PrimeTween doesn't deal with physics.
LateUpdate() is used for something like camera follow because you want the CameraFollow.cs script to update after all character movement calculations in the current frame. Following one object with another is a 'damping', and PrimeTween doesn't currently solve the damping problem either.

I would very much appreciate a real-world example that can help me to understand the use cases better.

Callbacks OnStart (I use this one for tweens with delay), OnUpdate

This is already possible with PrimeTween but in a slightly different way. Let's suppose we have the following code that uses DOTween:

transform.DOMoveX(endValue, duration)
    .SetDelay(delay)
    .OnStart(() => print("Delay done"))
    .OnUpdate(() => {
        OnPositionUpdated(); // delegate allocation! 'this' reference is captured inside a closure 
    });

The above code can be implemented with PrimeTween in the following way. Although it looks less pretty, it prevents delegate allocation. I will add the OnUpdate() equivalent in the future for more convenience.

Tween.Delay(delay, () => print("Delay done"))
    .Chain(Tween.Custom(this, transform.position, endValue, duration, (_this, val) => {
        _this.transform.position = val;
        _this.OnPositionUpdated(); // no allocation
    }));

Scriptable Object with default settings (for example default ease, loop type, autokill)

I didn't want to pollute users' projects with additional files, so all settings in PrimeTween are located inside the PrimeTweenConfig class. You can choose the default ease with the help of PrimeTweenConfig.defaultEase property.

LoopType is called CycleMode in PrimeTween and I believe it shouldn't be a global setting for the whole project. Every animation is different, and explicitly setting a CycleMode for every animation is a more readable and reliable approach in my opinion.

As for the autokill, PrimeTween doesn't have such a concept by design. Animations in PrimeTween are non-reusable; that is, you can manipulate the tween only while it 'isAlive'. But once the tween finishes (or you call Stop() or Complete() manually), it becomes 'dead' automatically. This prevents common performance pitfalls and makes the code much more simpler and reliable.

DOPath

Yes, I have the path animation on my roadmap and I will add it in future versions. Although, as you mentioned, this feature can have a lot of caveats, so I don't want to hurry with it.

I had tried to migrate from DOTween and faced some functionality I miss in PrimeTween.

I should also mention that the migration is optional and you should do it with care in the existing projects. PrimeTween doesn't conflict with DOTween, so you can migrate only those parts that are critical for the performance.

[KyryloKuzyk]

@EnterUserNamePlease Can you please tell me what types of animations you use with the speed-based setting? I assume it's only position/localPosition? Or do you use rotation/localRotation and others too?

[EnterUserNamePlease]

Yes, I use rotations too. And DOPath again) Well, these can be different cases, in most of which the player's input matters.
Example: there is a character, he must turn to the point indicated by the player. Suppose the player can tap any point on the plane, and the angle at which the character should turn can be from 0 to 180. So if the tween plays with the same duration, for example, 1 second, then the turn on even a very small corner will last 1 second. And I want the char to spin at a certain speed, no matter the angle. Of course, I can calculate the duration of the tween myself, depending on the angle, but it is much easier to add .SetSpeedbased() =)

[KyryloKuzyk]

@EnterUserNamePlease I added speed-based tweens in version 1.0.10 with the help of Tween.PositionAtSpeed() and Tween.RotationAtSpeed() methods. Please tell me if this new API works for you.
More details in this post.

[samanabo]

Personally I think having an equivalent to SetUpdateType (Normal/Fixed/LateUpdate) would be very helpful (at least for FixedUpdate). The use case would be a physics based, simple moving platform or even something like a wall moving towards the player, and pushing them.

Additionally, providing a function to allow users to manually update the entire tween system would be useful. With a feature like this users could force the update to happen in a specific order that they want, potentially allowing for custom integration with other physics engines/features or perhaps a custom character controller.

[KyryloKuzyk]

The use case would be a physics based, simple moving platform or even something like a wall moving towards the player, and pushing them.

It's already possible with PrimeTween. Updating a kinematic Rigidbody in Update() instead of a FixedUpdate() is perfectly fine for this purpose. Or at least I can't come up with a test that will show the difference. If you have such a test, please share it.

Here is a quote from the Rigidbody2D.MovePosition docs:

It is important to understand that the actual position change will only occur during the next physics update therefore calling this method repeatedly without waiting for the next physics update will result in the last call being used. For this reason, it is recommended that it is called during the FixedUpdate callback.

The docs say that if you call MovePosition() multiple times before waiting for FixedUpdate(), then only the last position will be used for physics simulation. This behavior is perfectly suitable for tweening and will produce the same results as with FixedUpdate().

The docs say it's recommended to call MovePosition() from the FixedUpdate(). And as I see it, there are two main reasons for this recommendation:

1. Performance. FixedUpdate() is typically called less frequent than Update(), so updating the position from FixedUpdate() will lead to fewer calculations, hence better performance. But, in my opinion, the performance benefits of this are very slim and aren't worth the added complexity. PrimeTween is already extremely fast, so optimizing for this specific use case has diminishing returns.
2. Better code quality. Dealing with physics in FixedUpdate() makes it easier to reason about the code, which improves its quality and makes move maintainable. But when using PrimeTween, its users will never notice the difference between updating RigidBody in Update() versus FixedUpdate().

While I fully support this official recommendation, I don't think it's applicable to a tweening library.

Additionally, providing a function to allow users to manually update the entire tween system would be useful. With a feature like this users could force the update to happen in a specific order that they want, potentially allowing for custom integration with other physics engines/features or perhaps a custom character controller.

PrimeTwee has a simple API and I wish it to stay so for years to come. While I may come up with a hypothetical example where a custom manual update is needed, I don't currently see how it would be useful in real-world projects. I'm constantly listening to the users and constantly adding features they request, but I have to first understand the reasons behind these feature requests.

[tpnet]

How to replace the DoTween.IsTweening API?

[KyryloKuzyk]

PrimeTween doesn't currently support this. I will consider adding it in the future.
I should mention that the DOTween.IsTweening() method is slow because it loops through all currently running tweens. It's much faster to store the reference to a tween and check if it's running directly.

[KyryloKuzyk]

I added a new Tween.GetTweensCount(onTarget) method in version 1.0.10. You can use it to check if any tween is currently running on the target: if (Tween.GetTweensCount(transform) > 0). However, for better performance, I would strongly suggest storing the tween reference and checking if tween.isAlive instead.

Also, you can use this new method to check the total number of running tweens by not providing any target: Tween.GetTweensCount()

[tpnet]

Sequence How to set CycleMode

[KyryloKuzyk]

This is currently not possible in PrimeTween because of performance reasons. Sequences in PrimeTween work by 'grouping' tweens, so they don't support SetEase(), cycle modes, or playing in reverse.
I have a few ideas how to address these limitations in the next versions, but this will take time. Performance benefits sometimes come at the cost of some features.

[KyryloKuzyk]

@EnterUserNamePlease I added the OnUpdate() callback in version 1.0.12. Usage example:

// Rotate the transform around y-axis as animation progresses
Tween.PositionY(transform, endValue, duration)
    .OnUpdate(target: transform, (target, tween) => target.rotation = Quaternion.Euler(0, tween.interpolationFactor * 90f, 0));

// Call the OnPositionUpdated() method on every position change
Tween.PositionY(transform, endValue, duration)
    .OnUpdate(target: this, (target, tween) => target.OnPositionUpdated(tween.progress));

[KyryloKuzyk]

@EnterUserNamePlease I added FixedUpdate() in version 1.1.4. Here is the documentation for the feature: https://github.com/KyryloKuzyk/PrimeTween#fixedupdate

[KyryloKuzyk]

@EnterUserNamePlease

And as for DOPath, there is some issue in DOTween variant. If the distance between your waypoints is very different, the target will follow the path with no constant speed. So the more distance between points, the faster the speed is, but I need the target moves with the constant speed. This trouble is fixed for example in Bézier Path Creator by Sebastian Lague.

As you've correctly pointed out, path (spline) is a quite complex domain, that hard to implement correctly. After long consideration, my current conclusion is that PrimeTween should not have its own spline implementation (which will most likely be not suitable for everyone), but it's best for my customers to choose their own third-party splines solution.

More info: https://forum.unity.com/threads/1479609/page-4#post-9522451