Add global default for useFixedUpdate

[cmann1]

I'd prefer to be able to set this once for the project instead of having to specify it for every tween.

[KyryloKuzyk]

Can you please elaborate on why you need to update all tweens in your project from FixedUpdate()? useFixedUpdate is an uncommon setting that is meant to be used only when animating RigidBodies, but when applied to all animations in the project, it may result in unsmooth animations.

[cmann1]

You may want to run game logic in fixed step for more deterministic results, and potentially performance reasons.

https://gafferongames.com/post/fix_your_timestep/

[KyryloKuzyk]

@cmann1 I don't think that running tweens in FixedUpdate() will produce "more" or "less" deterministic results. Unity engine is inherently a non-deterministic engine, and running animations in FixedUpdate() will not change that.

If you have performance problems in your project, I would suggest investigating their root causes instead of trying to fix them with FixedUpdate() too.

[cmann1]

While yes, I'm not sure about what it would take to make something truly deterministic in Unity (I understand some math functions etc. may not be guaranteed to be deterministic across platforms), running something with a variable timestep is most definitely less deterministic than running it with a fixed timestep.

I also never suggested that fixed update would magically fix some specific performance issue, but why try run game logic at 300 fps on every frame when running it at 60 or even 30 fps would suffice?
Separating the logic and rendering like this is not uncommon, e.g. https://deepnight.net/tutorial/using-my-gamebase-to-create-a-heaps-game/#4-5

In fact some built in Unity systems (cinemachine and the input system at least, if I remember correctly) already have this exact option.

[KyryloKuzyk]

Have you considered using Application.targetFrameRate? It will ensure the game doesn't waste computing resources while maintaining consistent and smooth deltaTime.

On the other hand, FixedUpdate will produce jagged animations when the app can't satisfy target framerate.

[cmann1]

That is an option. But I don't know that Unity makes any guarantees about returning the exact same deltaTime each frame.
Even so this is still coupling logic and rendering. I might want to run logic at 30 or 60 fps, but allow the user to run at whatever frame rate they want, or with or without vsync.

And regardless of how or what you're doing, if you can't reach the target fixed update rate, then the game is just running badly and everything is going to be "jagged", so I don't really see that as an argument against this.

To be fair, I do understand that mostly tweens will probably be used for "cosmetic" things and arguably should be run every frame for the smoothest results regardless of where you run your game logic.
But this may not always be the case, and I really don't see the harm in giving users the option (especially since this functionality does already exists, there's just no way to set the default).

[KyryloKuzyk]

The whole point of Time.deltaTime is that it varies based on the framerate. When animations use that deltaTime, their speed is independent of the framerate, which creates a smooth motion regardless of framerate or framerate dips. And in the case when the app doesn't meet its Application.targetFrameRate, all animations will still have the same speed (they will be less smooth, of course, but they will have the correct speeds and durations).

I really don't see the harm in giving users the option

At first glance, it looks like there is no harm, but there is. Adding such a setting will encourage users to "fix" something that's not broken. The recommended way to do time-dependent things in Unity is to use Time.deltaTime. The useFixedUpdate setting is there to animate Rigidbody, but it should only be used in those rare cases of animating physics objects.

[cmann1]

I'm sorry but I think you're misinformed.
Did you read the articles I linked? Separating logic from frame rate is not uncommon and is in no way "wrong".
And just because Unity beginner tutorials assume variable time step for the sake of simplicity that doesn't make it "right".

but they will have the correct speeds and durations

They will have approximately the correct speeds and durations.
Which is also true of fixed update as it will try to run as many times as necessary to maintain the same in game delta time and real world time.
You're also making the incorrect assumption that all games must prioritise matching real world time.
This is not true where determinism is more important - for networking, physics, or for example a game with a replay system.

Unity physics already uses a fixed update, and as I said before, multiple Unity systems already provide the user an option to run in fixed update.
If it's "wrong", then why would they give these options, and why doesn't Unity physics just run in update like everything else?
There's a reason that physics engines use fixed updates - because calculating things with a variable time step does not produce stable or deterministic results.

At first glance, it looks like there is no harm, but there is.

Well then the harm is already done, because as I've said both Unity and your library already provide this option.
You're just refusing to add a way to change the default for some reason.

[KyryloKuzyk]

I'm not judging by beginner tutorials, that's my accumulated experience throughout more than a decade working with Unity.

The articles you referenced are good educational resources when you're working on your own game engine. But when using an established engine like Unity, you have to play by its rules instead of trying to bend it in an unexpected way.

multiple Unity systems already provide the user an option to run in fixed update

I don't know any system in Unity that has an option to run in FixedUpdate except of physics. Can you please provide examples?

calculating things with a variable time step does not produce stable or deterministic results

Neither as updating things in FixedUpdate. If you want determinism or custom networking/replay solution, then using a tween library is likely not the best option.

You're just refusing to add a way to change the default for some reason.

I have my own vision for the product and I do my best to consider all the consequences before merely adding a new feature. This is the main reason why PrimeTween is so clean, consistent and reliable. I'll think more on adding the setting for the default useFixedUpdate, but I'm not convinced yet it would make a better product.

Saying that, PrimeTween comes with full source code available, so adding this feature yourself is extremely easy.

[cmann1]

you have to play by its rules

What "rules" are your referring to? Unity itself provides this callback to use - nothing is being "bent" in unexpected ways.
99% of my game logic is related to triggers, bodies, raycasts, velocity calculations, etc. so naturally most of it's going into fixed update.

Can you please provide examples?

I already did - both cinemachine and the input system have this option.
https://docs.unity3d.com/Packages/[email protected]/manual/Settings.html
https://docs.unity3d.com/Packages/[email protected]/api/Cinemachine.CinemachineBrain.UpdateMethod.html
(As a side note, a manual update mode could actually be a good alternative which would give the user full control over when tweens happen)

Neither as updating things in FixedUpdate

I'm really not sure why you would think that, because it is - that's not my opinion or "experience", it's just a fact.
Updating something at a fixed timestep, given the same starting point, and same inputs, will produce exactly the same results every time.
Whereas a variable timestep will diverge over time.
Which is exactly why Unity runs physics in a fixed update in the first place.

then using a tween library is likely not the best option

Why though? Interpolating gameplay related things, at fixed and deterministic timestep is a completely valid use for a tweening library.
You seem to be assuming that the only thing anyone would ever want to tween/animate are purely visual or aesthetic things.

I have my own vision for the product

Fair enough. I just don't understand your reasoning.

Anyway feel free to close this - you seem pretty set against it, and I don't really have any more to say on the subject.

[KyryloKuzyk]

Thanks for providing examples!

Updating something at a fixed timestep, given the same starting point, and same inputs, will produce exactly the same results every time.

It's not that simple. Floating point is not deterministic and the result will be slightly different, especially when different cpu architectures are involved like in the case of a multiplayer game.

Which is exactly why Unity runs physics in a fixed update in the first place.

Unity runs its physics in fixed intervals for many reasons (performance is one of them). But Unity's physics engine itself is not deterministic.

[cmann1]

Yes I have already acknowledged that it's not that simple (compiler, architecture, etc.), but as I understand it the floating point standard is deterministic.
And the same starting point and inputs will produce the same results on the same machine at the very least.

[KyryloKuzyk]

@cmann1 Hello again 🙂
Good news! I added the feature you requested in version 1.3.0:
https://github.com/KyryloKuzyk/PrimeTween/blob/main/changelog.md

It took me longer than I expected, and I had to introduce an API breaking change by changing the bool useFixedUpdate parameter to UpdateType updateType. I also included an automatic migration tool that scans all useFixedUpdate occurrences and replaces them with updateType. But please back up your project before updating to 1.3.0.

And I also added the PrimeTweenConfig.defaultUpdateType as you requested. Would love to hear your feedback.

[cmann1]

Awesome, thanks!
Everything seems to be working fine.