Official Unity 2023.3 coming April 2024 with updates for graphics and performance

Good update post.
The post mentions native renderpass and it being important for optimizing performance.
If I recall correctly multiview/single pass XR (at least on mobile) does not support native renderpass. Is this a feature that will be added with the release?

 

Thx for the update.
The release milestone image has a typo - you wrote two times 2023.2 even though it should have been 2023.3 the second time .

 

Somehow the title is misleading. Like, I naturally expect 2023.3 (LTS) to be released in April 2024. So I wasn‘t sure what I was reading here and what the change really is until I read this: „the Unity 2023 LTS will ship later, toward the end of that year“.

So perhaps the title should read that 2023 LTS will be delayed, which understandably sounds negative. But hey, it may actually get more reads.
Or just add „2023.3 tech stream“ to the title since a .3 minor version has become synonymous to „LTS“ since 2020.3.

 

Besides the always welcome updates, maybe focus beforehand on some bug fixing? My list alone of reported and accepted and not fixed issues is growing longer every week, all based on 2022 / 2023 features, and I am not yet done with reporting everything I encountered so far. Some of the newly introduced features in 2022 and 2023 are just broken and not production ready.

 

Please add Split Graphics Jobs for Metal iOS and Vulkan Android too
If you need shift release on one additional month for it

 

Hi. What will happen to release schedule for Unity 2024.1 and later after this announcement?

 

The blog mentions that by making 2023.3 a tech stream it gets it into our hands sooner, that is only the case if a dev is willing to gamble with using a tech stream and the issues that have historically gone along with that. The entire point of having a verified and stable LTS as previously explained by Unity is wait to use it if you don’t want to be exposed to shifting features, api’s and unexpected bugs. So for us this new change to the release schedule is simply adding another 7-8 months we now have to wait to get access to the next major engine upgrade.

It’s as though the LTS has lost significance now, this is such a long time to wait and will make us consider using a tech stream, back to how things used to be years ago before the LTS was introduced with a higher potential to encounter major issues.

Also, with this change the naming convention has now even more confusing. We’ll be getting 2023 LTS at the end of 2024, just before it turns 2025.

I can appreciate that you need more time to do stabilisation testing before stamping the engine as LTS, but I would rather have less features and a tighter annual cycle to each new LTS, not 18 months.

 

The yearly schedule, the multiple releases and the tech / LTS tracks don't work, it's time to rethink them.

 

It would make a lot more sense if you cut the amount of tech streams to one per year instead of adding more over many years.

For example, 2024.1 beta could start 2023 Q3. 2024 Q1 it hits tech stream status. 2024 Q3 stabilisation testing starts as development teams change gear to start on 2025.1 beta. Q4 2024.2 hits LTS. This cycle is much simpler to understand, you'd have a single tech stream and a tighter annual LTS cycle.

A lot of devs will be forced to make a choice to use a tech stream in order to gain the latest platform support, cause the engine cycle to LTS is far too long in a fast moving industry.

 

The current cycle was already sorta 1.5 years since early LTS is unusable and needs 6 months to stabilize, now we're adding another 6 months at the very least for what ends up now being 2 year cycles.

I didn't expect the big Visual Scripting rewrite to happen in 2023 cycle but now that's extended. And if it doesn't land in 2024 cycle, it'll be the one after the next. So that'll be what, the year 2027 or 2028? People were meming about 2026 but at this point it'll take even longer. It's somewhat concerning.

And I concur that 2023LTS at the start of the year 2025 makes little sense. Assuming further delays, Unity will be perpetually 2 years out of date semantically.

 

As if people don't know what the purpose of this tech stream launch is.
By the way, I was glad to read the title of the blog post. I was all the more disappointed to learn that it means nothing good.
But please leave the article unchanged. This is also reflected in your work on the Unity editor.

Even if you read the article correctly, you get less than what you would actually expect according to the roadmap. Much much less!

 

Maybe Unity should consider changing how the date system works for releases? If we were starting a new project in 2025, we'd be choosing to use the version named '2023 LTS' which feels odd and confusing to explain to people who aren't as Unity savvy on the team.

Appreciate the some-what honesty that 2023 needs more time in the oven though (Even when veiled as an upgrade)! More of that, please!

 

I second the idea of a different versioning system. The year-based versioning only makes sense with regular releases, and to my knowledge it's never been regular.

I'd also like to point out the issue with less frequent LTS releases - namely asset store support. I started a project on Unity 2023 because there were several improvements that would help my game, and I didn't want a massively outdated featureset when I eventually ship.
But because assets only support LTS releases, and shaders typically break with each version, this means I will now have to wait until likely 2025 to be able to integrate any shaders from the asset store.
Not a disaster but... that's a long time.

 

And a question: The blog post mentions a new version of DLSS but what about FSR? The version 1.0 Unity currently supports is sorely in need of an update.

 

Nothing changes for Teck stream users as it looks like the 2024.1 will just become 2023.3. For LTS users, however, it means that they have to wait six months longer for the LTS. but have more features.
However, it also means that the features planned for 2024.2 are now coming to an LTS half a year later than before.

I think the main reason is that starting next year they plan to release LTS and Techstream 202X.1 at Unite in the fall.

 

I'm guessing you're not talking about 1.XX updates for FSR - although I believe Unity might be lagging on that a tad (1.1 is a version increment, but I'm not sure Unity was on the latest 1.0X before that though). FSR1 is still useful on hardware that can't handle the overhead of temporal upscalers.

There are some resources available for integrating FSR2 on Unity on GPU open, but it's not as easy in editor like FSR1 was with some check boxes. It does seem like a lost opportunity (as might lack of a XESS option).

There IS a store solution for FSR2 from Alterego Games which is pretty awesome (they're also working on DLSS2 for rendering pipelines not covered by what is built-in), but I agree it would have been nice if these options were just handled by Unity. Alterego also has a pretty accessible support for their solution and it works across a huge list of hardware/tech. I do hope that, whenever it is released, that we see FSR3 be something Unity tackles & updates though.

 

Marketing/PR at Unity forgot how time works... So you release 2023 LTS at the end of 2024 instead of Q1 of 2024 and you put some stuff in it from the 2024 tech stream but you release them at the same time you would release 2024.2 tech release. Brilliant. Same amount of stuff delivered partly later but labelled as earlier. And people at Unity said "okay" to this... ROFL. I'm sorry, but this is genuinely hilarious.

 

The sad thing is that the blog post is believed by many users. Those who know that Unity isn't being completely honest don't even have the opportunity (as before) to write something directly under the blog post.
Unity shouldn't be surprised why some people write that they give the shareholders more priority than the developers.

 

Yes, many people are asking about FSR2. Although it is desired and would suit Unity better because of its higher platform independence, Unity is more likely to choose DLSS3.
It might get even better. They will only partially implement DLSS 3. Who cares about details? if you can write later that you also support DLSS3.

 

I'm not doing gamedev right now so I have no dog in this fight, but this is farcical. You need to draw a line under the current version numbering system and start fresh. Either rename 2023.3 to 2024.1 and 2023.LTS to 2024.LTS or switch to normal numbered versions, maybe even numbers for LTS and odd numbers for Tech Streams.

 

I'd prefer to have both. The current FSR fallback for devices that don't support DLSS is jarring. FSR 1 is very poor quality.

Just semantic versioning would be best. It's how a lot of software works.

 

I'm all for a more logical versioning convention, but even if the version year lined up with the actual year or going back to the original arbitrary number format, it's all fairly insignificant really. The main issue is the LTS cycle blowing out much longer.

 

@LeonhardP nice blog post, but are there any more details about things like "Improved graphic performance"? We're pretty consistently hitting a wall with CPU performance in URP despite our best efforts. We might consider moving to the tech stream if there are significant improvements there. How/when/where can we see your profiling to show said improvements?
Thanks!

 

Hi AljoshaD. Can u also check case IN-52428 to make sure Entities Graphics is working nicely with this latest URP with solid 60 fps at least at snadragon 855 android phone at Unity 2023.3? Currently 2022.3 is perform poorly and I hope this performance issue will be fully addressed at Unity 2023.3

 

I have no comment for version naming and current naming scheme looks ok for me. Anyway I just want to know when 2024.1 alpha will start after announcing 2023.3?

 

With the added time, will more things also get into Unity 2024.x cycle?

 

Thanks for the reply. Just to clarify something, you mentioned that the 23.3 tech stream will be production ready, but the perception I think many have (myself included) is that it's safer to wait for the LTS. The tech stream might be considered production ready, but obviously there's still room for major changes and the issues that can arise from that.

I understand the engine is so vast now with countless features all being developed alongside each other, and that there's no way you could say with any certainty that the 23.3 tech stream will be as solid as it would have been if it were the LTS, but that's all we're after, we need certainty that when we upgrade that we're not going to be backed into a corner with an engine that ends up having major issues and prevents us getting our games to market while we wait for bug fixes.

So I'm still just feeling extremely uncertain about using a tech stream, but if there are any reassurances you can spreak to regarding a tech stream being used for production that would be great to know. It seems that would be a contradiction to the LTS version, but could it just be that our perception of the LTS and lack of certainty on using a tech steam for production is misplaced? or are there any assumptions we can make about a .3 tech release being more stable than a .1 or .2? or perhaps even waiting for a new tech stream being out for a couple of months to iron our initial bugs.

The short version is how do we identify stability if it's not an LTS version? thanks!

 

We're in the same place as @jason_yak - we moved to using LTS versions a few years ago and have been avoiding tech releases for stuff in production, or alphas/betas for anything at all really. They've just been too unstable to rely on and the relative stability of LTS versions has been much easier to deal with.

The issues do really hit when something like URP is in lock-step with a Unity version and the older versions of URP don't seem to have issues addressed/fixed or receive much attention at all. This is hitting us quite badly in the current 2021 LTS at the moment, and the 2022 LTS is even more broken. So, we're even between a rock and a hard place with LTS versions, let alone thinking about using a tech stream version.

Hopefully the 2022/2023 tech and LTS development cycle goes well given the long time before a 2023 LTS lands.

 

The problem is those terms mean nothing any more. Going by all your editor and feature releases in the past, say, 5-10 years, “production ready” just means beta and “fully supported” means “after you make a minimal repro, produce a video and jump through numerous hoops the QA will put you through, there is a small chance a blocking bug might get fixed in the next 6 months”.

 

Awesome!
Looking forward to testing it on standalone vr

 

It would also help if you could, for example, introduce colors for the individual years in the Unity Hub. I only see numbers and sometimes I have to look 3 times so I don't get the wrong version. Before you even had to make sure that it wasn't a 2019 version because there were 3 tech streams. Now the nonsense starts again. Now you have to take a closer look and know exactly from which year the new system was introduced. Of course people will complain again and in a few years you want to change it again?
After an accident has happened, one should not keep trying to improve the situation so that this accident does not happen. After the accident, the parameters are different.
Unity, you guys are really not good at UX.

 

Actually the actual problem behind it is not about year naming scheme but the editor stability and breaking changes. Currently according to case IN-44206 even at latest 2022.3.8f1 LTS at the time of writing, it still has serious player runtime building issue that make the build process really pain that u can't 100% guarantee u can successfully get a game build after pressing build button. Then for breaking changes what I know is at URP there's always has breaking changes that official silently change it without documentation to clearly mention those breaking changes and the resolution to fix those breaking changes. I guess that's why asset store developer tired of keep spending time to figure out the fix themselves and delay update to LTS version.

So the expectation is to bring editor stability improvement, reduce breaking changes and clear documentation to breaking changes to next level. For each tech stream, it needs to reach quality bar higher than current LTS that should not happen issue like case IN-44206 that can fail player runtime building which unacceptable.

 

Visual Studio 2022 is really 17.X so I don’t think the year matters too much. Contrary to the marketing BS blogpost, I’d guess this extra tech stream is more about them falling behind combined with needing a full year to stabilize the .NET CLR scripting change. Which is my last chance for Unity so I hope they do it right. Tech streams are glorified betas regardless how Unity labels them. So whatever the latest LTS is is all that really matter to a lot of devs.

 

? I don't think they mention this anywhere, may I ask you where you got the info that .NET Core change will be part of the 2023 release?

 

The tech stream is really not that bad. Updating your project is work but there's too much stigma surrounding it. Yes, it's work but it can absolutely be worth it. Tech stream versions can be perfectly stable, you can ship games with them, or you can update them to an LTS version if you think that would improve your project.

For me, the 2023 tech stack has countless meaningful improvements that make my project better, and starting on the tech stack makes updating to the eventual LTS much easier (if that's something I even need to do, because 2023.1 is perfectly fine).

 

My guess is 2024 based on the progress/posts in the .NET scripting forum. This added tech release also delays the .1 release of 2024 and gives them more time for that testing.

If they work for you and your dev practices, go for it. I think they can be helpful to target a feature 1+ year from release and the pain of upgrading is low (small project/team). However, trying to release a game with a 10+ users relying on it to be stable for a production release is a mistake. Unity also seems to agree that they shouldn’t be used for production work.

 

Maybe if you target one or two platforms that are very well covered by your testing such as Desktop Steam. For multiplatform releases it's a death sentence. Unity never address showstopping bugs in a timely manner so it's up to us to avoid them, therefore LTS is the safest bet.

 

Lol, then just call it 2024 LTS, i do not see the point, but...

...I see the problem and btw thank you for the info but, calling a tech version "production ready" is something we all know is bs (sorry) and the indie/less experienced devs like me (+80% of your users) are not going to use something that is not LTS for their games, it just does not have any sense at all... IDK, maybe call it "Unity 12" or "Unity 13" and use the LTS, tech, alpha or whatever internally but being in 2025 and opening unity 2023 to create a game with cool features and great graphics is not just weird but it doesn't say anything good (apart from what is already said)

 

2024 version should be skipped then. If Unity doesn't do it now, Unity will need to do it later.

 

Thanks for the blog post, but oh boy is this confusing again

Just for the record, do I get this right?
So some years ago you changed the cycle from being .4 the LTS version to .3 being the LTS version
Now we are going back to that again? Is that right?

If so: what was the reasoning for the change in the first place again and what has changed for it to make sense to go back to this numbering?

 

I think it was changed to 3 to have more time to polish each release before making something non beta, which still was not enough time this release

 

Just to get MY naming right:

initial versioning: .1 until .3 was Tech Stream, .4 was LTS

current versioning: .1 until .2 is Tech Stream, .3 is LTS

new versioning: .1 until .3 will be Tech Stream, .4 will be LTS

@DevDunk Yeah, I remember that, that's why I would like to know from someone from Unity what has changed so they decided to go back to that cycle or do I misunderstand this new versioning and it is indeed different from the initial one?