Unity - The slippery slope

I just want to highlight a giant concern with Unity. First some data.

2017.4.x
What's new in Unity 2017.4.40 - Unity (unity3d.com)

2018.4.x
What's new in Unity 2018.4.36 - Unity (unity3d.com)

2019.4.x
What's new in Unity 2019.4.29 - Unity (unity3d.com)

2020.3.x
What's new in Unity 2020.3.16 - Unity (unity3d.com)

Do you see the trend? Every "LTS" release the known issues list is growing by a staggering amount. 2017 LTS had 1 known issue and 2020.3.x has 33. This doesn't even count the items that broken by design. (Networking, DOTS, URP/HDRP)

You guys really need to deep dive internally into what is going on because whatever it is, it's not good. I think 2 tech releases a year is still too much. Until you can get LTS release down to 1-5 known issues again then you shouldn't start the next tech release otherwise LTS is meaningless.

 

Are these known issues something that stops you from building your games?

Personally I've found each version of Unity is getting better, despite this list growing longer. So maybe it's not that they have more issues in each build but maybe they're more aware of the issues in each build?

 

Increasing known issues is simply due to the increasing features introduced with each new release and the fact that there are way more people testing today than there were in the more early days. While it has been a while I think it's important to remember too that at one point Unity's betas were not public.

 

Are you the guy that lowered that bar to fixing the reporting of deltaTime's inaccuracies?

That never made the list of known issues, despite being fundamental to everything about the engine.

I don't think these lists get anywhere near the volume of known issues that are significant.

The problems of stability and performance - that's more anecdotal because it's not in a formal list, but the volume of folks slowed down by issues of performance and stability is huge, even if merely anecdotal.

I know, there's a million ways to obscure, placate, defer, blame others and generally deny anything being significantly wrong with Unity, and that that will be the mantra forever.

But anyone that uses Unity knows what it's actually like to use.

 

I know all of this, everyone that's used Unity for more than a couple of years knows all of this.

Yet the pace of getting things fixed (like the deltaTime reporting issues) is glacial, at best.

And that is a bug. There's no question about it, it was causing stuttering and jitters that folks were complaining about for at least a decade, and getting ridiculed for not knowing how to setup their projects properly etc... and told they were imagining things, and wrong... etc... when they weren't. What they were seeing was incorrect reporting of time affecting everything animated on the basis of that reported time, which was the way just about everything in Unity is suggested to be animated.

See all the demos and tweens doing nValue * Time.deltaTime to see how prevalent this issue was.

And not even one apology from Unity. And now you're saying it's not even a bug.

What is a bug?

 

You probably can't answer this, but it seems, to me, in my testing of the various versions after the bug fix of the deltaTime reporting, that there's at least one other fundamental flaw in how the engine loop works.

Is there something else wrong at the core loop/time level of the engine that's been at least noticed, and hopefully being worked on?

And, a third part, is that the reason for the delays in ECS/DOTS - as I'd imagine working with them in fine time granularity has probably revealed what I'm seeing to the folks trying to get time sorted for all sorts of other things/reasons.

I've done my best (which is poor, I'll happily admit) to describe what I'm sensing here:

https://forum.unity.com/threads/eas...latest-version-of-unity.1155641/#post-7415432

if you think of a setting to try, or arrangement of settings and ways and means... I can assure you, I've tried it. I'm quite serious - I think there's something else askew in how time is handled at the core of the engine.

 

As I said... I know. I eliminated all others, and came to two conclusions.

1. Time is being reported inaccurately
2. There's other mysterious issues with time and the engine

This is the pertinent quote to point 2, above:

I'm suggesting Unity has discovered a fundamental flaw at the core of the engine's ticking/rates/propagation of events, and is attempting to fix it because the high velocity and fine granularity of doing masses of things on multiple cores in DOTS via ECS is somewhat hamstrung by these time issues, and the fix won't be in anything but 2022 onwards, hence DOT/ECS being stalled out.

I'm not the OG of the OT and OP - I run tests at 30, 60, 90, 120, 144, 165, 180, 240, 360 and 720 - because these are common refresh rates and input rates. Though, having said that, if you've got an adaptive rate monitor and video card, lots of refresh rates are possible at smooth rates. Theoretically. Not sure about with Unity.

Vsync, in Unity, works sometimes in some versions, on some machines, on some OS updates, with some monitiors and with some video cards. It's a crapshoot, at best. Other times there's lots of issues with it not being nearly as wonderful as the claims made about it.

It would be nice if Unity could write a blog post about how to get stable frame rates and smooth animations, and show the setups they're using, and the project settings that achieve this, and the compromises of each approach, for each major platform and target device. Including Application.targetFrameRate and all its many foibles and quirks.

And then consider how to achieve the same smoothness with higher frame rates and lower latency input devices, like the new gaming phones and mice/motherboards used by gaming pros, etc.

I don't see this happening, because I think Unity's at least somewhat aware of the problematic nature of timing reliability, smoothness of animation and latency funkiness in Unity.

Colour me skeptical, but I think you're the only one in the company that has any idea what I'm banging on about and wants to find a way to address these issues, other than those in the DOTS team that might have come across the root issues and found them to be a stumbling block for all that they're hoping to achieve.

My suggestion, make a very light thread run super high frequency/accuracy timing assessments of Unity's activity by leaning on and contrasting with `mach_absolute_time` and/or clock_gettime_nsec_np on iOS devices, as these are quite accurate and open to use and comparison across many different types of hardware that's probably laying around the office.

 

On a personal level, thank you!

I wasn't banging on expecting an apology from Unity to me, instead; for and on behalf of the thousands of users that had previously come across these problems and not perhaps been as [un]lucky as me. I found what I thought to be a problem and a way to minimise it because, unlike most others, I'd had experience with another engine getting time and timings wrong at a fundamental level.

I'm sorry I couldn't get anyone at Unity to take my claims about timing issues seriously, then and now. Because there's still something not quite right!

Those poor other sods perhaps leant more on the incorrect assumption that they were doing something wrong and that Unity couldn't possibly have a fundamentally wrong issue at the timing level of its engine... I mean... that's the job of the engine... to tick over... accurately... right?

Especially when almost every demo relied on that time reporting's "accuracy" to position things when animating.

Yet, some of those poor folks were mocked and belittled for not being able to find smoothness etc whenever they sought assistance... when it simply wasn't possible and wasn't their fault.

 

@Tautvydas-Zilys I really appreciate the candid and honest responses from a UT dev on some of these points.

I understand people get frustrated, but venting at a developer who's being frank about problems doesn't help anything. All it does is make people less likely to be open, honest and engage with the public on these forums.

 

An increasing number of known issues can actually mean there has been improvements to the QA process, catching more issues. It can also mean that Unity is being more transparent about what known issues exist in any release (since it is beyond belief that 2017.4.0 had only a single unfixed issue in the entire product).

I don't think you can draw the conclusion that more known issues mentioned in the release notes means that the product quality is degrading over time.

 

I thought the Unity slippery slope was when you start using Unity to make games and then you decide you need to make your own models and animations so you learn Blender and then you decide you want to texture your models so you need to learn substance painter and then you decide your game needs original sound effects and music so you buy a midi keyboard and digital sound processor and and and...

 

And you've learned how to do all if this you may wonder "why the heck did I learn this stuff" and possibly lose all motivation to do anything afterwards.

 

Lucky for me, the learning is the fun part!

 

You are all wrong. The correct approach is to use PhysicMaterial and embrace poor grammar as you increase friction. I suggest 1.0.

 

As an indie, using Unity, you should be using an LTS build for the life of the project. Now, different LTS builds will have different bugs due to added features, etc. I personally use the 2019 LTS build, as im only 1-2 year out from the latest, and has less bugs than newer builds have. It all just about choice...

 

Hi @Tautvydas-Zilys. It seems like mobile platform delta time doesn't backport to 2020 LTS yet. Can u backport it since the bug become shipstopper to my project? Not 100% confirm it's the same issue but it looks very similar. Case 1346761 https://issuetracker.unity3d.com/is...kan-error-swappyvk-failed-to-wait-for-fence-2

 

All of these LTS versions have many more updates compared to 2020 LTS.
2017: 40 fix updates
2020: 16 fix updates
2020 is the most recent one, so it has less updates by quite a bit compared to the older LTS versions.

 

I'm not really sure but I build android with the same project in 2021.2 gives me extremely stable frame rate than 2020.3 LTS. I can say it's almost no fluctuating frame rate in 2021.2. What has been changed in 2021.2 to get that extremely stable frame rate at android platform?

 

Did the Time.deltaTime accuracy fix make it into 2020.LTS for Android?

 

@optimise see above - for maybe why you're getting more stable frame rate feelings.

I'd guess you've got things animating on the basis of Time.deltaTime and you're getting stable frame rates in both, but the animations look janky in 2020.3 LTS due to the inaccuracy of deltaTime's reporting.

 

It would be nice to have such a major bug back ported to LTS for those of us stuck there But I understand that might be too hard