Roadmap?

The roadmap hasnt been updated to include 2020.1, can we get that updated so we can get visibility on what is planned to go into it?

 

Besides, I think the roadmap is out of date:
- The "New Input System" package is in "Feedback Builds" and should be in 2019.3 as "Preview" and in 2020.1 as stable.
- "Linux support" is in "Feedback Builds" and is supposed to be stable.
- "Addressable Assets System" package is under "Development" and is supposed to be stable.

And many things that are not and are being worked on. There are many packages of the package manager in preview and there is nothing in the roadmap.

 

I guess we will have a new roadmap revealed in Coppenhagen later this month.

 

Yes. But they never seam to update the roadmap after telling stuff at Unite so either they should remove it or start updating it! Even under a beta period most stuff isn't included there.

 

The roadmap will be updated soon. In the meantime, please rely on the post in this forum for 2020.1 confirmed features: https://forum.unity.com/threads/preview-of-2020-1-features.742052/

 

thanks for your detailed feedback, we will update these in the next few days (when people come back from Unite!)

 

The 2020 roadmap will be shown at Unite (early today but haven't been posted on the internet yet) so please can you accually add that information soonish? I feel like the roadmap never is updated.

 

The roadmap talk from Unite copenhagen is now available on youtube:

 

Accompanying blog post w/ pdf link:
https://blogs.unity3d.com/2019/09/26/unity-roadmap-unite-copenhagen-2019/

 

What's GameObjects with Properties? it's in the slides but isn't mentioned at all.

 

The roadmap is still not up to date: https://unity3d.com/unity/roadmap

Where is the page for 2020 Alpha?

 

A shame the roadmap seems largely redundant/not worth having at this point. The information it lags behind and has no depth, so perhaps Unity is planning something better for it.

 

Apparently they ARE working on it...

"Note: we are currently working on redeveloping our public roadmap website. In the meantime, please consider this presentation our most accurate representation of our plans."​

Found at the very bottom of the blog post with the PDF roadmap: https://blogs.unity3d.com/2019/09/26/unity-roadmap-unite-copenhagen-2019/

 

Thanks for the tip!

Pity we have more and more to look for things here...

 

Don't start XR then

 

Oh I guess we'll get a replacement in like 3 years or 5? It took years for them to implement a simple delete project button for the hub so don't expect anything soon

 

What's that?

 

They also mentioned working on this at the start of the Unite LA 2018 Roadmap talk. Nearly a year has passed since then, and things didnt improve.

The roadmap talks are an inadequate replacement for a number of reasons, including that they sometimes mention stuff in one talk that doesnt happen and just doesnt get mentioned in subsequent talks, with no way for me to track the status of the missing feature. HDRP area light volumetric support, I'm looking at you for an obvious example.

 

I think SRP needs holistic approach. If we take 2019.1/.2/.3, they are different in workflows in SRPs and postprocessing.
Unity 2020 needs clear modular vision which won't change vastly from version to version, but stack new modules or fix old ones.

Why different SRP version need to be tied to only fixed Unity versions?
Unity should be one where you could use whichever SRP version you need.

 

Because not every part of the Unity engine is in a package yet. So there's dependencies. You can demand they change but they already are and cannot go faster.

 

New terrain-landscape tools should be universal across all renderers, built, URP and HDRP in terms how is user going through workflow to create landscape level.
When needed, user picks specific shaders for grass within renderer. Also for layered materials.

Main principle should be to this universal approach to make Unity recognizable through workflow.

For now, URP works differently than HDRP. Compatibility with URP and HDRP shaders would be very practical and useful.
2019 releases were very distinct to each other.

When somebody picks Unity 2020.x and beyond, it should feel like one Unity.

Please, make Visual Studio Code easy to install through Unity Hub as optional like VSC.

 

I get what you mean and it totally should, if someone imports all the packages. But I hope at this point they are running seriously beefy computers.

But it's also very cool that Unity allows those who know what they want to remove that which they do not use.

 

Yes. What I meant to say, for example,
there should be universal landscape tools for URP and HDRP. When needed, user chooses which shaders he wants.

What I find a missed opportunity is Forest and Book of the dead demo. They already have unique shaders, material layers which only work for that specific version of Unity but not in general.
It would be better and functional to built universal tool which can be scaled across all renderers simply updating the shaders for that renderer. A future forward practicality.

 

I think a better way is for them to make sure graph can do this, and supply a public resource of nodes we can all use, and maybe change instead of fixed shaders perhaps nobody can change.

It's better to give you a solution that you can control.

 

I remember seeing some terrain updates on GitHub for shader graph. It went dark a few months ago so it might have been set to private while under RND.

 

I think relying on shader graphs for all shaders is silly. Some things really fit within graphs, particularly unique shaders tied closely to the art you're making. But when you get into more complex systemic shaders, graphs break down at an interface level, and the attempt to hide small details behind nodes often results in unoptimized approaches because those abstractions hide what would be obvious optimizations in code. Unity should abstract away concepts like lighting and compatibility without trying that to one very specific, high level and closed API for what is essentially writing code.

 

Can we please have a single source of truth in one link (ie. the official roadmap) rather than having to browse through multiple blog posts, forum threads, youtube presentations?

Compare the UE4 roadmap: https://trello.com/b/TTAVI7Ny/ue4-roadmap

To the Unity Roadmap: https://unity3d.com/unity/roadmap

Why not just setup a Trello or Notion board? A lot easier to update and manage than being forced to go through the web team to update the roadmap.

Given the state of flux for URP/HDRP, this is really important information. Making the decision on starting production (for my second title, beginning production Q1 2020) with 2019.3 vs 2020.1, with built-in vs URP, is a major decision, that should be as easy and transparent as possible for the customer.

 

Decision is easy, it's 2020.1. Progressive lightmapper will have improvements for CPU and GPU.
For production this is very important.

 

Yes please Unity just follow the logic and have a person just keep a public trello going. It's simple is it not? then you don't need a fancy webmaster to become available.

 

Better performance scale for SRP is in research. I wish this could improve in 2019.3 release.

There is no roadmap for Graphine.

 

An arbitrary timetable for LTS, based on the position of the Earth in reference to the Sun and the rest of the Solar System, might not make sense for a game engine.

What was the logic to abandoning the old naming/timing system again? I still have the feeling that some features are being rushed out to hit an arbitrary deadline, instead of being released when actually ready. The rehashed prefab system which was rushed into 2018.3 (but should have been held back to 2019.1) being the clearest example.

Unreal again seems to have the best system here - extensive beta and alphas, with major, working new versions delivered about every 9 months.

Unity going through the 20xx.1, .2, .3 process seems unnecessary for what are essentially just preview versions of the fundamental 20xx.4 LTS version.

 

I have no intention of going on and on about a competing engine here, but I will say that this is not how the UE4 release schedule is timed at all. 3 major releases per year, all of which are a mix of fixes, improvements and new features. Preview releases that tend to become available approx 6 weeks before release. Github sourcecode for those that want to keep up with code changes between releases. Their roadmap is far from perfect either, but its exceeded Unity for useful info for ages now.

 

LTS release should come in the same year it is titled.
2018.4 LTS release was about half year period wait.

If another team can prepare 2020.3 to release in first half of the year, than 20xx.4 LTS could be released in the same year.

 

We are debating Unity putting a roadmap in a singular, sensible place, at the same time as Unreal rolling out free Quixel services for all users... sigh.

 

Let's not forget the awesome replacements for Simplygon. They can do HLod, remeshing and decimation. In import or in editor. That's a big feature to me

But despite all these awesome features, I'm still using Unity because for all of Unity's flaws there's a lot of great stuff here too, so it's not all doom and gloom.

It is nice that we're vocal about what we want - helps Unity improve IMHO.

 

I'm also often having problems with figuring out what Unity is doing at the moment. The roadmap is usually so out-of-date and has very little information, and the rest of the information is scattered in forum threads (that are often not pinned), blog posts, YouTube videos and even random Twitter posts from Unity developers.

Doesn't matter which tool they use (custom, Trello, something else) as long as the information is in a single place. I would be happy even if it was just a list of upcoming features and a bunch of links to the forum threads, blogs, and videos.

 

Plus it takes aaaages to retrain to the level of competency you already have in a new engine. I literally just finished trying to go down this rabbit hole like 2-3 months ago and came to conclusion that while unreal is no way near as hard to code for as I thought (either I am better at c++ than I remembered or years of being in industry has made me a better programmer - or both!), it doesnt matter because it will still take years to get to the level I am now with unity in unreal - the point where I mostly know how to at least start doing any task that comes to mind, and knowing where to find resources for the ones I dont understand.

That and I really really dislike that certain features are only usable via blueprints

 

It would be immensely easier to have just a few and stable tech releases.
Every tech build in 2019 had about 10 versions or more.

Taking a project through them is huge undertaking and not worth the time.

If there could be only a few tech builds, only one or two, we can be more productive.

Also 2019.4 LTS release should happen sooner. This is the proof of concept build I want to use it. Everybody does.

 

.4 LTS releases are really just mature versions of .3 releases, with additional fixes over the length of the long term support.

It makes no sense to release them before .3 versions have been out and improved upon for months, or before next years tech stream begins properly (I'm not counting alphas eg 2020.1 alpha).

And a big point of the Tech releases is that they happen every week so people dont have to wait long for certain fixes. Also LTS version updates are supposed to come every two weeks, so if you dont like frequent updates I dont understand why you dont complain about that. And if they released LTS versions as early as you seem to want, imagine how many more updates they would receive over their lifetimes, so there is a contradiction from you I dont understand either.

A lot of the update pains people and projects may suffer from is when moving between major versions, not the small bugfix releases. The advantages of LTS tend to be unlocked via the regular bug fixes, which are very much an essential part of the Support part of these releases.

Honestly, many of your requests in this and many other posts are pretty specific, but the detail often fails to make sense and what you are really doing is just repeatedly asking for certain things to arrive more quickly, sometimes via a pathway that doesnt make sense.

 

By the way I am always ready to consider that I may have overlooked some factors in your reasoning, so I will apologise in advance if that proves to be the case here.

Let me put what I said before another way. The point of LTS is to have support for a long time. So I actually want that version to come out as late as possible, so that 2 years later is further away than it would be if LTS came out sooner.

Right now, if I am interested in the feature set of a version that I can then get support and updates for, for a long time, I can start with the first publicly available alpha of a .3 version, and carry on all through .3 alpha and beta and release and tech updates. Then LTS arrives, and I can carry on for another 2 years.

The things I mostly see people moaning about arent to do with that timing, or the frequency of tech updates. What they tend to complain about is either features that dont quite make it to .3 (and packages compatible with that editor version), or that do make it into .3 in initial immature form, that people feel is too early to get stuck with in a LTS release. I can sympathise with that, although I'm not sure what my preferred solution would be since I dont want important new features to end up being off limits for half a year due to release timing.

 

I understand. My point was they need to re-structure whole development plan.
.1/.2 should merge into only one release.
.3 should be scheduled mid year and .4LTS in the end of the year.
I'm talking from SRP perspective.

When 2019.1 was released, SRP was in better state than in LTS.

I had to upgrade Unity because of SRP but SG didn't work as wanted, then when upgraded, SG had to be remade.
Then progessive lightmapper didn't work.

Most important is to make Unity modular that LTS release can use SRP v8 or v9.

 

Well thats an issue of packages that are still in preview and immature not being a great fit for LTS releases.

Your release timing change suggestions dont actually fix that issue, and would just cause other issues.

I have said elsewhere that part of the potential of Unity becoming modular is spoilt by how closely various packages are reliant on changes made to specific editor versions. Its a big shame, but again a big underlying cause is immaturity of the systems, and situation should improve when specific packages and editor-side code they need is more mature.

Since 2019.3 version of HDRP is out of preview, this is the first version of HDRP that really has to be supported properly for entire LTS release. But this does not mean new features, just fixes. And just like Unity itself, the .4 LTS is really a continuation of .3. Which, unless Unity change version numbers and release approach for HDRP, means that for 2019.4 LTS you will be using a 7.x version of HDRP. Not 8.x because that is for 2020.1.

 

I think there should be only 2 tech releases in first six months of year.
.1 in April and .2 in July.
.3 release should be renamed to LTS should come at the end year. This will make LTS build proven and stable.

 

Since .4 is based on .3, I dont see the merit in your plan. You are actually giving less time for the LTS version to be developed, not more!

For example Alpha 2 of 2019.3 came out in May 2019, and that code base will live right until 2019.4 is released, plus 2 years afterwards.

 

That makes little sense given .4 is built on top of .3. So there is very little difference, your basically just saying remove .4 effectively. What you describe is effectively .1 .2 .3 right now.

Everyone wants stuff sooner, but that isnt the answer to it.

 

The idea is if you have only 2 tech releases LTS can come sooner around December/January.

 

unity reflect has nice roadmap page, maybe this system could be used for others too
https://portal.productboard.com/ryk149xi2qtmns5iehpngb6u/tabs/1-under-consideration

 

That is pretty nice, but I think Unity finds it too to the point for their intended target audience.

 

But will this LTS version have no features? Because that means we'll be getting less just so you can condense the LTS in the same year.

 

Generally Unity gives you 3 major versions per year but the amount of upgrades is extremely variable. I would just treat the whole thing as a subscription to use Unity in general, not for expecting a specific thing nor expecting any set amount of things.