The scene window and the game window lag equally. In the editor scene 90% of the processor resources are spent on SceneView.Repaint, and in the game window 90% of the resources are also spent on GameView.Repaint. This problem is relevant from version 6.1 to 6.2. The funniest thing is that in LTS 6.0 there are no lags, everything is absolutely smooth there.
I tried to create a clean URP project, the same thing lags there too, so it’s not a problem with the project.
So what has changed? I can’t upgrade to a newer version because these lags are annoying. I’ll have to continue sitting on LTS 6.0
If this occurs in both 6.1 and 6.2 with blank projects and you have up-to-date graphics drivers please submit a bug report in the editor via Help => Report a bug …
I have the same issue! I was working with the 6.0 LTS version till now and it worked without any issues. I switched to 6.2 today and it lags a lot. I don’t know why this is happening to an empty project.
I tried restarting Unity and Unity Hub but that didn’t work.
I wouldn’t recommend upgrading to 6.2 unless you want to experiment with Unity AI or the new features.
Unity hasn’t really tried to fix any of their editors major problems in years, such as the incredibly long compiler times, scene repaint times, and domain reload times (among others). If they’ve gotten worse from 6.2 compared to 6.0, that’s not surprising because they’ve been getting worse and worse for years. They’ve pushed out a lot of new features though, which maybe are impressive to investors, except they too tend to be low quality and riddled with issues. And they still are deleting one or two star reviews from the asset store to hide the quality issues there, too.
Although they are pumping out features, the quality of their work is low, and they are trying to hide all their problems from the public. This strategy might yield a return in the short term, but since their quality of their product is getting worse and worse overtime, I don’t think there is much a long term future to look forward to. I think that Unity will self-impode at some point when its problems become so great that they can no longer supress them.
I still use Unity because I have to because I’m “hooked” on their ecosystem, but Godot and unreal are slowly catching up, and I feel like it’s just a matter of time before the majority of Unity users can finally make the jump. Or, the quality of this engine will continue to degrade overtime and reach a point where users will be forced to make the jump whether they are ready or not.
… or you could be constructive and open a thread for each issue you have, describe it concretely, and I‘m sure most of them get resolved.
There‘s a lot of things that can break your workflow experience in any engine, and throughout my Unity experience I can confirm that the majority of the issues people complain about typically turn out to be homemade.
There is an incredible amount of documentation and evidence of the issue regarding compiler loading times in Unity and how it has degraded over the years. 5 minutes of googling will show this. To deny this is being willfully ignorant, it’s a very obvious form of denial.
This is precisely part of how Unity covers up their degradation. Their own forums are filled with evangelists and apiologists who rush in to defend Unity from criticism. People need to be aware of what is going on.
Source? If it’s so easy to find, I want to see it. You made the claim, so we need to be talking about the same thing.
But don’t make the mistake of taking several people’s complaints on face value. You’ll find these everywhere for everything. You’ll also find (fewer, naturally) people saying they fixed their issues, and it was really dumb …
Every time I had Unity devs (typically on site) complain loudly and adamantly about Unity, and I had the chance to investigate their problem, it was almost always their fault (not strictly but it takes a fair amount of experience to analyse issues - it’s just so much easier to just complain and spend half your day wasting time if you get paid to do so).
Throwing 50 gigs of assets into a project for one, or throwing dozens of “fancy editor tools” into the project, or always making a full release web build (can take hours). People complain about Unity being slow in these cases and never stop to think what they are actually doing to themselves, or even actually researching whether there’s a possible solution.
I did my own tests a year or two ago - two projects, one an actual Unity 2017 production and another just throwing stuff together from all over the place. I upgraded it from 2017 to 2023 so I had the same two projects in every Unity version.
Both projects exhibited the same behaviour when it came to how long it took to load a project, and how long it took to change a script until domain reload was finished. The results were completely against popular notion where “Unity 2019 is fastest” was actually the slowest by a small margin. 2017-18-19 were successively slower, 2020 a little faster, 2021 slower again but not as bad as 2019, 2022.3 then was 20-40% faster (!) - Unity 6 wasn’t available at the time but 2023.1 proved to be even faster.
Now if only I could find where I took notes of these results.
For anyone having editor lag after interacting with the scene view (on Windows), this fixed it for me too. (well, just disabling auto graphics API fixed it). Hope it helps someone!
After updating to Unity Editor 6.3.9, I had to roll back to 6.3.4 because of severe Editor lag. The whole PC would freeze for up to a second at a time, and in Play Mode I was getting only around 30 FPS. I updated my NVIDIA GPU drivers, deleted the Library folder, and waited for file indexing to finish, but none of that helped. The same issue was also present in 6.3.10 and 6.3.11.
What made it even worse was that I had to upgrade the project to the latest version just to add localization, because in 6.3.4 Unity would crash whenever I opened the Localization Tables. After that, I had to downgrade back to 6.3.4 again just to continue working on the project and be able to test it properly in Play Mode.
Because of this issue, I could barely work on the project properly for almost two weeks.
In the end, I unchecked the Auto Graphics API option you mentioned, changed to Direct3D11 and the insane lag was gone. Play Mode is now running without any FPS drops.
Thank you so much, you saved me a lot of time and frustration.
I like when someone is trying to prove their point with nonsensical demands.
So: source does not exists. Its impossible to create any “source” regarding long term and slow coming changes.
WE are users. WE are customers. WE are using product for god know how many years. WE are source. I literally can open one of my older projects made in unity 5 and run it and see in my face difference. And its not because “projects are getting bigger” or something like this. No. Similar scope, even similar graphics fidelity (interesting huh?) but editor performance is in hell with new version.
Years and years of neglection of essential functionality and features and adding more and more features which lays on very unstable basis.
At least dont bull***t yourself. Since IPO company focus its just “oooh thats cool lets do this” instead of boring stability and QoL maintenance. And im saying this as private investor who owns small amount of unity stocks.
And looking at my unity stocks value this also doesnt really work…
Also commenting on almost one year post while encountering same problems doesnt yell “improvement in product stability”.
But hey… who am i? Just product user for almost 10 years and (granted, not huge) company stocks owner…
Source: My decade of experience with Unity and countless projects of all sizes in every viable platform.
I agree with what they said.
I am working on a project on 6.3 and facing major “Update” issues.
One of the top reasons I moved from Unreal to Unity back in version 5, was that no matter how many 3D (and other heavy GPU bound) applications I had open to do my work, even with 4GB VRAM and 16GB RAM. Unreal would often crash if you had other real time 3D applications, even if a web browser was using the GPU. And it was horrible. Unity would never contest with other applications for exclusive GPU resources like Unreal does.
That was true mostly until 6.0. In versions 20+ they started doing the redraw nonsense that they still have not fixed. I couple of years ago or so, they had promised they were looking into fixing it. Never happened. This whole “fee” nonsense threw everything in disarray and perhaps that initiative somehow got deprioritized.
The reason of this “feature” as they called it when they introduced it, was… “public demand”. People wanted to know Unity was doing something in the background. And no, they could not simply print something in the console. They had to halt everything we do for several seconds. Sometimes almost a minute.
I sincerely doubt anyone ever asked for their work to be interrupted in such random, violent, and annoying way.
That was what made me start thinking of Unreal again.
In 6.x especially the later versions, this has evolved to, (among others) the dreaded “scene update” that are a constant Russian roulette game. And a horrible nuisance of a showstopper.
These issues in the software I supervise become priority #1. With Unity it appears the solution is ‘let the user chase every conceivable random thing and blame it even on Windows installation yes! let them re-install everything, of what fun!’
That’s anecdotal at best. You mention measurable tasks so they need to be measured, not subjectively “felt”, and compared with only the Unity version changing, not the project. Every project is different, I’ve worked with terrible Unity projects that brought everything down to a halt even back with Unity 2017-2019.
A lot of the time wasted was our own fault, like an editor script that scanned the entire scene hierarchy on every selection change. Another was excessive (needless) calls to AssetDatabase methods. More were due to hooking things into the wrong event methods ie EditorApplication.update to check for changes to an asset. Most of these were attributable due to inexperience and time pressure.
In my experience Unity has noticably stabilized and sped up since 2021.3. I’ve been experiencing fewer and fewer crashes.
I absolutely can’t say the same about Unreal - it’s still as eager to crash and lose you a lot of work at any given point in time for seemingly no apparent reason. It doesn’t even “save” the assets you had recently imported and that may cost you yet another hour trying to figure out what those assets were and where you had used them. As an Unreal developer, you learn to assign Ctrl+S to an Autohotkey script that triggers every 2s.
That’s a major workflow problem Unreal has on top of serializing everything as binary. So while Unity definitely isn’t without issues, it’s IMO still far less nerve-wrecking compared to Unreal.
The main issue with Unreal is their inflexible workflows which have seriously improved with versions 5.x by becoming a bit more flexible and modern, that was when they actively tried to come closer to the openness of Unity and attract modern developers and artists.
In the meantime, I think Unity fell victim of the Unreal apologist/promoter narrative that was driving the impression that Unreal’s ridiculous pipeline and workflow rigidity was due to its “more professional approach” which, as a professional in this field for decades, I can assure you was bullshit through and through. But at that point in time that was the only PR defense card Unreal could play really. Unreal abandoned or improved all that nonsense in version 5. And keeps making Unreal more artist friendly. Yet we see Unity trying to replicate some of these UX practices in versions 2020.x forward thinking they were essential in order to attract big studios entrenched in Unreal, which is something that never happened.
According to you. The issues are well documented since 2022.x, first reported in 2020.x and existed in subsequent versions too. Widely accepted from Unity devs themselves. Issues they promised to fix but did not. They became worse in 6.x.
So not anecdotal at all. The issue tracker is rife with reports about the dreaded “Application.UpdateScene” which started showing its ugly head with the transition from 2019, to 2020.
I can confirm that, and it will remain bullshit for as long as Unreal still serializes everything as binary. I turned on the “experimental” text serialization in 5.5 or 5.6 but it still had zero effect on any new imports. It’s unfathomable how they can operate like this.
Yeah, no wonder, because everything that takes an extra amount of time is cobbled together in UpdateScene. It’s like saying that Unity builds spend too much time in Update.
I can pop up this UpdateScene message quite easily, all it takes is a Task.Delay in an Editor script in the most callbacks. Consequently, that second link has Unity staff noting that the project’s SpriteShapes are quite complex.
In my experience Unity performance issues that developers dread are in 98% of all cases homemade. Or simply not considering the scale to which they’ve developed their project … 10,000s of GameObjects in a scene or a tilemap that’s 1000s by 1000s in size or 50+ GB under Assets/ do that to any project.
This also falls in line with Unity showing that “Hold on…” progress bar since 2020.2. Guess what? People have been saying ever since that Unity 2019 was still the fastest by far. But when you actually take out a stopwatch and measure you’ll find that for every situation 2019 took the longest time to process a domain or project load (including 2023.2 which was the last version I measured and compared).
The progress bar and the UpdateScene (since Unity 5 probably didn’t have that) is merely causing psychological effects because Unity 2019 did only have a status bar animation, which also stopped far earlier than the editor became responsive again. Having that delay shoved in your face through the progress bar is when developers actually took notice, and that made it FEEL longer because it was more visible.
Similarly with UpdateScene - it’s just something visible that has a gazillion of causes and the large majority are self-inflicted.
Indeed. But not 2020 where this practice was introduced. It seems you conveniently kept the 2019 from the phrase “transition from 2019 to 2020” Coincidence or deliberate choice to discredit the well recorded, (and reported even,) facts?
And guess what!
They have been complaining and reporting about the same issue ever since. Since 2020. (in 2020.2 the issues indeed became worse as the team was still “working on it” pushing more and more to the wrong direction.) Not in 2019 just in case you try to drag the discussion back there. And it has been getting worse since 2020.1 forward, as I already said.
It is not causing “psychological effects” it is causing crashes that people report, and mysteriously Unity despite acknowledging them, has even marked some of them “won’t fix”
But because I saw your response in some similar complaints again as “self-inflicted” and other classic apologist jazz, and I see you are following a very specific and particular narrative discrediting those who report such issues, it seems to me I am wasting my time trying to discuss with you.
No, I specifically pointed out the issue started appearing with 2020.2 which fits right in that 2019 to 2020 transition period, and henceforth (since 2020.2) people have been complaining about “Hold on …”.
It’s actually the first time I’ve heard complaints about UpdateScene specifically, and I’m very active here for 5 years now, it should have rang a bell for me.
So those “reported facts” are in reality just users complaining about what they see - the “UpdateScene” message - without understanding the underlying problem, or the simple fact that this is a catch-all message that’s very common to appear for many operations.
I am not sure this is exactly the same problem as OP describes, but I found out that when scene view grid is rendered, there are huge lags when moving the camera in 6.3.
The funny part is it only lags if camera is above zero. Below it works correctly.
Disabling grid solves this problem in my case, but also changing to DX11 makes this issue less noticeable.
I reported this (IN-141484).
