Search Unity

2021 年に向けた Unity の計画を共有いたします。皆様からいただいたフィードバックを読み、皆様からのご意見に基づいた計画を立てました。

Unity の 2021 年の製品へのコミットメントはシンプルです。それは、皆様から寄せられた要望に基づいて、本番環境ですぐに使える機能、ワークフロー、コンポーネントを提供することです。Unity は、本番環境ですぐに使える機能とは、ユーザーのニーズを完全に満たし、リリースの時点で完全なサポートがあり、タイムリーなバグ修正、改善、そして明確なロードマップを備えたものであると考えています。

予測を立てて実行できるように、私たちは仕事のやり方も変えていっています。より少ない作業量で、より良い作業を行い、リリース前に首尾一貫して機能することを検証します。皆様にとって最も重要な機能と機能を開発するために、より大きく、人材の揃ったチームを編成しています。Unity は、製品、プログラム、エンジニアリング、設計チームに投資を行い、優れたワークフローを構築して皆様のお役に立ち、予測可能で信頼性の高いリリースの実現を目指してまいります。

ソフトウェア開発とはすべてプロセスです。毎月、開発者ダイアリーを通して、皆様に進捗状況を見たりコメントしたりする機会を設ける予定です。こうして、皆様に理論が現実化する様子を見守っていただけるようにいたします。

以下の図は、2021 年に向けて Unity が重点を置く分野を示したものです。

コア製品の相互運用性と安定性

Unity 2021 としてリリースする一連のバージョンは、Unity 2020 LTS(長期サポート)リリースを直接のベースとして構築します。その主な目的は、エディターの安定性と堅牢性を向上させ、バグやリグレッション、特にユーザーへの影響が最も大きいバグやリグレッションを減らすことです。私たちは、こうした取り組みを「ついで」にしたくありません。他のすべてのものの土台となり、私たちを前進させてくれるものにしたいのです。ユーザーの皆様が日々開発を進め、ゲームを完成させようとするとき、こうした取り組みの積み重ねが違いを生むものだと私たちは知っています。

もう一つの重要な変更点は、バグの数、リグレッションの数、クラッシュの数といった指標に加えて、ワークフローや相互運用性が壊れていることもバグの定義に取り入れ、その定義に従って追跡するようにしたことです。

その他、以下の分野にも力を入れています。

  • ワークフローとユーザビリティ:UI オーサリングなどの集約的なワークフローや、それらを可能にする主要なツール(シーン関連のツールシステム、検索およびフィルタリングなど)のアップグレードによる Quality-of-Life(生活の質)の向上を目指します。
  • プラットフォームのリーチ:次世代コンソール、Apple Silicon、新しい AR/VR プラットフォームなど、幅広いプラットフォームのサポートと、各プラットフォームがローンチされた時点でのコンテンツの提供を実現し、かつ、モバイルアーキテクチャ向けの継続的な最適化とサポートも進めます。
  • 性能と反復作業の速度向上:アセットのインポート、ビルドとデプロイ、およびエディター内での反復作業まで、開発ライフサイクル全体にわたるチームの生産性向上を実現します。

機能

Unity 2021 では、グラフィックス、マルチプレイヤーネットワーキング、ビジュアルスクリプティングの 3 つの機能分野を進化させていきます。

グラフィックス:スクリプタブルレンダーパイプラインとツール

Unity は、ユニバーサルレンダーパイプライン(URP)ソリューションの成熟化、および HD レンダーパイプライン(HDRP)の安定化に取り組みます。レンダーパイプラインにまつわる Unity の長期的な目標は、Unity のすべての機能との完全な相互運用性を持たせることであり、ユーザーをサポートするツールのエコシステムを使ってシーンを構築するための 1 つの方法を提供することです。

ビジュアルスクリプティング

2021 年には Bolt ビジュアルスクリプティングを Unity に直接組み込まれたコア機能として提供する予定です。これを行うことで、Unity のノードベースの開発ツール全体に一貫性を持たせます。Unity は、ビジュアルスクリプティングのワークフローを他のノードベースのソリューションと統一することが、優れたユーザーエクスペリエンスを実現するための鍵であると考えています。

マルチプレイヤーネットワーキング

Unity は安定してサポートがついているネットコード基盤を提供します。第一に、これはデータ指向技術スタック(DOTS)のネットコード空間を超えて焦点を拡大し、現在の Unity の GameObject のためのソリューションを提供することを意味します。次に、Unity はオープンソースソフトウェア(OSS)のマルチプレイヤーコミュニティにいる素晴らしい才能と共に開発を行い、主要なジャンルのフルスタックソリューションの提供を目指します。そして最後に(皆様からの要望に応え)、マルチプレイヤーゲームの制作のために、単にネットコードを提供して終わりではなく、ツール、ドキュメント、サンプルに大規模な投資を行い、ユーザーがより簡単に開発を始められるようにする予定です。

Mediatonic の『Fall Guys: Ultimate Knockout』ようなゲームの成功が証明しているように、現在の Unity を使えば、素晴らしいマルチプレイヤーゲームの開発が可能です。

製品のリリーススケジュール

2021 年の製品リリーススケジュールは、以下に示すリリースコミットメントに基づいたものとなります。

Unity 2020 LTS(2021 年第 1 四半期)

  • Unity 2020 の長期サポート(LTS)版です。Unity 2020.1 および近日リリース予定の Unity 2020.2 からの安定化されたチェンジセットを含むものとします。
  • インスペクターの配列やリストの並び替え、インスペクターのコピーおよびペースト機能の改善、ヒエラルキーの中でオブジェクトを「デフォルトの親」としてマークする機能、その他、既存の機能やツールセットについての多岐にわたる改善など、特に生活の質に焦点を当てた改善を盛り込む予定です。
  • 反復作業の速度、開発者向けツール、および IL2CPP がコード変更がない場合に不要なコードの再変換や再コンパイルを回避するようにするアップデートといったパフォーマンス改善に引き続き取り組みます。
  • アセットインポートの安定性と堅牢性の向上を実現します。
  • URP と HDRP の両方について、SRPの安定性を改善します。
  • PlayStation 5、Xbox Series X、Apple Silicon プラットフォームのサポートを提供します。
  • OSS のマルチプレイヤーコミュニティへの貢献とコラボレーションの拡大を図ります。

Unity 2021 製品リリースサイクル(2021 年 3 月~10 月)

  • Unity エディターに直接統合されたビジュアルスクリプティングを、堅牢性と安定性に優れ、本番環境での開発にすぐ使える形で提供します。
  • URP と安定版の HDRP における主要な体験を反復的に改善していきます。アセットストアでは、ユーザーがタグ付けやフィルタリングを行うことで、URP や HDRP のコンテンツを簡単に発見できるようにします。
  • 現在の Unity(GameObject)のための、安定してかつサポートのついている、拡張可能なネットコード基盤を提供します。
  • マルチプレイヤーゲーム向けツールのサポートを強化します。
  • コア製品の相互運用性と安定性の向上に関する事柄は上記の通りです。

また、データ指向技術スタック(DOTS)に関する取り組みも継続しており、将来の Unity の基礎、および初期状態で優れたマルチスレッド性能を実現するアーキテクチャの基礎を築くための努力を続けています。これについては、今後のブログ記事で詳しく説明します。

コミュニティからのフィードバックは非常に貴重なものであり、私たちのこれからの開発に対しても引き続き皆様からのご意見を伺いたいと考えています。私たちは、毎月の開発者ダイアリーで定期的に進捗情報を共有し、皆様が私たちにご意見を伝えられる場を提供します。

/r/Unity3D subreddit の AMA(Ask Me Anything)セッションにぜひご参加ください。日本時間 8 月 15 日午前 2 時 30 分(アメリカ西海岸時間 8 月 14 日午前 9 時 30 分)から、Unity チームのメンバーが 2 時間にわたって皆様からの質問にお答えいたします。さらに、モデレーター付きのフォーラムの Q&A スレッドを数日間にわたって開きますので、ぜひご質問やフィードバックをお寄せください。

117 replies on “2021 年へのロードマップ”

really people… some estimates about when will DOTS be ready?!
so many great things (new ui, visual scripting (the one with dots, the other doesn’t count), ai planet etc etc) and so many things actually finished….
when they will be ready?! DOTS will be ready this decade?! century?! millennium?!
sorry for the language but you really suck at communicating this kind of things!

All I want to do is paint high quality grass, trees and other foilage, on my terrain in HDRP. A basic, fundamental tool that works, or worked, in the standard shader, but has been taken out of HDRP. We are on the cusp of next-gen, and I still can’t do that. It’s painful to use. I’m not even sure how you are surviving right now? Fix what’s there before adding more new s**t we don’t need. It’s a crazy situation. Unreal delivers a mind blowing demo and you sit back and trundle along showing us videos of content we can’t actually create ourselves without a team of ten people manually placing grass on the ground. Just clean it up and fix it. Please.

THANK YOU UNITY! Now we no longer have to damage our eyes thanks to dark theme! I think this will boost sales even more.

Well after reading all the comments on this blog post I have come to the conclusion that the Unity community is nothing but passionate about the engine and its tooling. :)

I am glad to see the networking piece high on the roadmap as I think we are all aware that has been a needed item for quite sometime now. I personally have been using LiteNetLib coupled with SteamWorks and PlayFab with some success, but as the netcode community knows when it comes to the fast paced games and the need for lag compensation, rollback, fixed tick on multiple platforms, etc… it is not an easy task to accomplish especially for Indie developers with day jobs. I have worked with the DOTS NetCode stack since I saw the amazing FPS demo published by Unity and the other samples since have all shown great promise such as the DOTS Sample Project. 3/4 of the need is there and it does work out of the box it just isn’t as easy as people want and Unity has said they understand that and are working on it.

However the part that has been frustrating for me in following along with the development of DOTS and the Netcode portion in particular are that these demos that show promise are not updated to keep up with the changes to the stack and quickly become useless and frustrating for the community. I had to turn off my GitHub notifications as I was getting 10 or so messages a day of complaints of users not being able to compile and update the FPS-Sample repo. This to me turns something Unity had done as a positive into a very negative thing. I mean there is still an awesome webpage showing this great FPS-Sample and here is how you download it and get it up and running, but it hasn’t worked in a year and a half at least. Just wish the teams working on the DOTS/Netcode stack were as committed to these demos and learning tools as the community is. As it is now, anytime an update comes out with Netcode it seems I have to shuffle through all the demos out there to find the one that works with the latest release and they seem to be getting more watered down each time.

Only other criticism, hopefully taken as constructive, I have is that the Unity asset community leaders be reached out to and input taken at a higher priority than it is today. I embarrassingly spend a lot of time on the various Discord servers for the assets developers, many of which have decades of real world game company experience, and the common theme I hear from them is that they have had to do some workaround in their asset to fix something in Unity and that they have put in the tickets for and are basically throwing their hands up in the air with frustration over months passing and no resolution. Probably the most out spoken about this is Jason Booth the developer of Microsplat/Megasplat. There is no denying this guy knows his stuff when it comes to terrain shaders and so if you are lucky enough to have him using your engine and developing assets for it then maybe take a moment and get his input. There are others, but I always find Jason’s comments the most comical so he stands out in my mind. :) The Asset store is one of Unity’s biggest draws and feathers in its cap so it would be a shame to loose critical people from it over pure neglect.

I do want to thank the Unity team and all the work that they are putting into their engine and for working so hard to get it to the next level while trying to maintain a legacy code base. Anyone who has ever had to do that knows it is a thankless and under appreciated under taking. So seriously from me to you all I really appreciate it and I am extremely excited to see what the next year brings. Good luck with your upcoming IPO. Hope you get your 1.2 Billion ;)

Well, the software is called Unity, but it has 3 different incompatible graphics pipelines , it has many features and tools that are scattered across packages and not built in by default. The Unity name kinda lost its meaning … Isn’t that right ?

Unity needs to include all this stuff in setup and rename itself to Bloatware. It’s so uncomfortable and annoying to take only what you need in a lightweight package!

I REALY HOPE YOU WILL simplify the process for reading a Data.JSON from the StreamingFolder
When publishing to WebGL right now its a nightmare!!.
Need to write inside pligin need to update index need to include things that are outside of the unity domain.
Make it very frustrating.
Please make it simple.

I hope Unity can go above and beyond the floating point limit, because a range of 100,000 is simply not enough
.

The floating point limit isn’t Unity’s fault, it’s simply a limit of binary number representation. There are way to work around it, but there isn’t a simple “fix” because it isn’t a problem that can be solved without re-writing Unity to use 64-bit doubles instead of 32 bit floats.

I really like the 2D lights feature (introduced in 2018 I think), it’s pretty awesome, but I have a feature request: Metallic maps. We’ve got normal maps, and even Ambient-occlusion maps (through the _MaskTex secondary texture), but metallic maps would really make our space-ships pop!

A few suggestions for consistancy.
I love the way the new Input System can generate code for bindings. Please make this a consistant feature with everything that uses strings and ‘blackboards’. AudioMixer, Animator, Shader graph etc.
For all visual scripting, use vertical execution with horizontal data, like the Visual Effects Graph. ie make Bolt default to the Bolt 2 vertical layout. This is a nice layout, plus it looks similar to normal code, helping beginners and making tutorials and docs more common to both VS and code.
Also avoid pointless renaming of normal code terms, etc “Super Units” instead of functions and ‘blackboard’ instead of Variables.
The less special cases the better.

I am so happy to come across this piece of write up, very much advanced my understanding to the next top level. Great job and continue to do same.

And the recently announced IPO is going to kill all the good resolutions. I pity the fools..
Over and out!

So something most might not know is unity transport initially had the full C source, then it was removed. With all the talk about OSS will Unity open that back up?

I was surprised seeing visual scripting getting a spot in the top 3 next to SRP and Multiplayer. Is this list for tech that is in a bad state that you guys are prioritizing or is this the base from the user or studio inputs or a combination.

I really expected to see the GI in real time as a focus for 2021, are we going to have to wait any longer for that to happen?

I think this is the correct decision and gives me the confidence to keep using Unity for commercial products.

However we desperately need better terrain and vegetation tools, efficient realtime GI for URP, and inbuilt LOD/optimisation tools. I’m willing to have these locked behind a Plus subscription.

Also, please transition your Roadmap to Trello or Notion, which are common public tools used by developers. Your current roadmap is hard to navigate and often out of date. Look at the Unreal Engine roadmap for inspiration.

I wonder if it’s because I’m in the niche of solo-developer, but I have never heard “the people” ask a lot for Visual Scripting tools, much less for them to be integrated into Unity, though it is nice to hear the node tools are finally getting a strong foundation (does that mean we will be able to develop our own node editor tools?!).

I was most excited about multiplayer networking, but after reading also most confused. I do get that a lot of companies would need this, right now, but could you elaborate on the long-term goal? Correct me if I’m wrong, but I’m reading that Unity is collaborating with outside developers to make this solution happen and that it will be independant of DOTS. 2 red flags: Unity has been stepping away from outside solutions the past years (or else merging them into the company) and DOTS is being shaped up to replace the engine’s core.

Many things are in really poor shape, the Terrain tools need heavy work, there is no shader graph integration for terrain, it supports 8 layers like we are in 1999.

Enlighten has been cut while Unreal did show realtime GI, leaving Unity with absolutely nothing.

Dots is the way to the future and putting visual scripting anyone can buy right now in many variations over Dots, Lighting, Terrain, Shader Graph integration and UI is extremely misguided (atleast Multiplayer and RPs are adressed). I hoped Unity would understand from all the recent backlash and complaints about the current state.

Get the existing Tools on par, this is absolutely the worst time to play with some new gimmick now.

And desperately hire some UX talent.

I think much of the complaints could be reduced with improved UX design and clarity.
Unity needs to set up a strong UX strike team who actually go over all the features and identify all these pitfalls that made Unity from the easy to pickup Engine to this Patchwork UX nightmare of the current state, especially within HDRP.

Also how is Visual scripting now a top priority when this was just recently bought from a third party?
The last unity should do is chase a new toy which requires big refactoring, nobody actually needs at this moment. Lighting and many other things are still in a really poor state.

Focusing on the cool new toy is really sending all the wrong signals.

Hey Eric, I hear what you’re saying but this isn’t actually what is happening. What you’re describing as a New Toy is really the result of a few years of work by external developers Ludiq that we brought in house. Their system is solid and we plan to bring it further in line with the rest of Unity as we continue to develop the tech and integrate with the core of Unity. This isn’t a new toy because we’re also integrating a lot of the ideas with our internally developed Visual Scripting solution to provide an even stronger solution, whilst providing one for people that need this function today.

And yes – I hear you – lighting needs work, other UX needs work – and we’re working on this extensively, not in a strike team, but as a broad design organisation that’s getting serious investment with embedded product designers working with teams on everything from HDRP, to Lighting, to Editor, and many many more features that need a lot of UX love. In summary, I understand the optics you’re reading, but I want to assure you that isn’t the reality of how we’re working.

I already own a Visual Scripting tool that has a much better Asset Store review score than Bolt. I doubt many people would have asked for you to integrate an inferior visual scripting tool into the Unity engine. At least make it removable.

I do like the emphasis on fixing and polishing what’s there, and make it work together better. This has been a big problem the last two years. Unfortunately, you made a very similar statement a few years ago, then completely dropped the ball on it. Why should we believe you this time?

Also, on the side, why is this comment box only two lines tall? Your website team leaves a bit to be desired. Asset Store iteration has been extremely slow, and takes years to add sorely needed features and improve performance.

If you’re talking about PlayMaker, they are not comparable. PM is focused on finite state machines. Bolt is a more generalized all-access visual scripting tool and the better choice for a core engine feature than something more specialized like PM.

I must admit, I used Bolt for a little bit, just following along with tutorials. I actually paid for it after the aquisition, but got refunded, but when I used it, it felt amazing. Looked amazing. Just the appeal of using it. Obviously some of the windows seem a bit misplaced, but it was great to use.

Playmaker I know is very fast and functional and has a big library. But it’s a state machine, not suitable for an engine to adopt as VS solution.

Legends say Jim is still out there… commenting on threads, touting his superior Visual Scripting tool without actually telling anyone what it is. ¯\_(ツ)_/¯

Interesting stuff, I know the Unity team can’t get to everything, but I gotta say — nice work!

I was looking forward to visual scripting since it can help a lot with graphs and visual tools for RPGs I always wanted to make.
I also highly appreciate the bugfixing and workflows improvements, they really mean a lot to us, so thanks for that! (AND DARK THEME OMG -fanboy mode activated-)

Also random, I’m quite curious if Unity will be getting an export to Tesla cars sometime.. hehe. But I’m sure you can’t reveal anything about that yet.

I hope that DOTS will always remain a number one priority until it is fully complete – and I didn’t really get that impression from this post. The fundamental development differences and resulting performance expectations between OOP and DOTS are too vital to leave in limbo for long – and we’ve been waiting for quite a while now.

Can you elaborate more on future DOTS development and timeline please?

DOTS is becoming the backend. Update Vector* etc… are being DOTSified so we’re gonna see a 2X in performance without doing a thing. Then they start exposing it to give 100x to those who use that funky API.
Then I wake up.

So Visual Scripting (VS) is now top, top priority? In this case, I have a few comments.

How many half baked VS tools are cramped into your oven by now?

– ShaderGraph
– VFXGraph
– DOTS Visual Scripting
– DSPGraph
– And now … Bolt native integration

I understand why you want specialized VS tools – the beauty and purpose of VS is to offer simplicity. If you try to solve all the world’s problems with one visual language then the complexity will outgrow the purpose. So specialization is great, but how many native VS tools should Unity support? Wasn’t Bolt doing just fine as an Asset Store product?

I haven’t used any of your VS tools – even being a huge fan of VS in general. Why? Either because they are not mature, they don’t support the features I need, or they are too difficult to extend. Examples? ShaderGraph support for DrawProcedural, ComputeBuffers, SV_VertexID. VFXGraph support for shared memory (or just an easy way to route data from other ComputeShaders into the graph).

So please, don’t try to support all your users special VS needs. Instead:

1. Make your VS tools easily extensible. Make it the easiest thing in the world for your users to script their own type of specialized nodes (blocks or systems, or whatever the components may be called).

2. Make the very foundation of your engine easily extensible, so that users can easily build their own VS tools. Historically you have done a great job on this, but on the graphics front, with the rise of URP and HDRP, this has gone down the drain. URP now have Custom Render Pass, but still has some way to go. HDRP now have Custom Pass, but try to write a shader without tearing your hair out. UIElements is useful for UI, but the API is very alien to Unity (inspired by web tech) and can get overly complex.

I have spent ages developing my own VS tool. It has been a fun ride, but if your VS tools were easier to extend (1), I might have gone with that. And if your graphics foundation was easier to extend (2), I might have shared my VS tool by now.

Unity “First, this means expanding the focus beyond the Data-Oriented Technology Stack (DOTS) netcode space to solve for current-Unity GameObjects.” WHAT DO YOU MEAN BY “SOLVE FOR CURRENT GameObject”? What makes it inefficient anyways, if thats what you mean?

Bolt was doing fine *for itself* on the Asset store, it was not doing fine for the public perception of Unity. Unity not having generic visual scripting built-in but instead having to be paid for was a clear barrier to entry and common “Unreal is better because…” talking point. Unity absolutely needed to integrate something like this long ago, before even any of the other VS they implemented.

Would be interesting to see some numbers on how many developers are actually shipping games using Dots / URP. As i feel its probably in the <5% mark. Meanwhile it seems like mono has been forgotten (not to mention networking on mono)

Hey there Scott! You can be confident that you can continue to use monobehaviour and we will continue to support that. There are no plans to completely remove the monobehaviour workflow. That said, if we were to ever consider such a thing in the future, it would be with the understanding that its replacement would need to be something you could love even more.

Great news! Keep up the amazing work.
Though you should also lower the Asset Store share from 30% to 15% in 2021. Or less / earlier.. xD

Congrats for hosting an AMA — a great step forward building a roadmap with the community.

Hi Unity Team !
While you are making the future of multiplayer ready, could you communicate what pending multiplayer technology was used in the game you mentioned in the article please (Fall Guys)?
Thank you in advance.

The FallGuys team did their own fantastic effort to heavily modify and build their own netcode. We’re collaborating longer terms to make it easier for everyone else

Fall Guys probably just used some 3rd party paid asset, since Unity just outright removed their multiplayer lol

The FallGuys team did their own fantastic effort to heavily modify and build their own netcode. We’re collaborating longer terms to make it easier for everyone else

Ok, that’s totally fine, but I don’t think you should be trying to justify one game with their own netcode and relate that to Unity.

Bit of a cheap statement

Hi Damian, thank you for participating in the conversation, I’m sorry for the confusion that I might have caused with the blogpost copy (I wrote it). I referenced a well-known multiplayer game that is written in Unity as a way to prove that it’s indeed possible to succeed (not just succeed, they’ve toped all charts!) on the multiplayer space with Unity. However, we know that “possible”, doesn’t mean “easy”. Our Networking investments are directed to make this as easy as we can for Unity developers. Hope this adds some light.

DavidS

I just spent the last few months (only because I’ve done it for our previous engine) writing our own low-level (reliable UDP) and high-level GC-friendly net code because of the lack of support from Unity.
We have no intentions of using DOTS, so can someone from Unity please explain what non-DOTS networking features (if any) they’ll be adding and supporting?

Also, is Unity still supporting NavMesh update? There are some issues with it that we have run into but it doesn’t appear that they’ll ever be addressed.

Is the “default parent” feature used to make it so when you drag an object into a scene, it automatically parents to that? If so, awesome! That shows that Unity is really finding issues in the Unity pipeline and trying to fix them. :)) That’s something I’ve always wanted, and built a tool to do it, but I’m sure the Unity version will be integrated better!

Cool. How does this feature work? I am on 2020.2a19 and can’t find an option for Default Parent.

*Please* make sure this functionality has an exposed API. We currently have sub-areas (think top-down Zelda with multiple building interiors vs. outside) and a selector to pick which to work in. Having the ability to set the default parent to one of these areas from script when it’s selected would be very helpful.

Looking good. Make less and make them better.

Missing features/Incomplete features:
– Spline component (someone mentioned above).
– Pro Grids/Pro Builder (Why are they eternal PREVIEW packages? This should have been part of the core engine ages ago for quick prototyping. This is a must and one thing I miss coming from UE4).
– Terrain Tools (What happened? Another preview package that should have been part of the core engine ages ago.)

Pro Grids is sometimes glitchy for me, Need an editor restart to make it normal.

Also, there is some kind of snapping feature in the unity editor already, but it’s a bit clumsy to access compared to Progrids.

Hey there, Renato!

Andrew replied earlier regarding Spline:
“Good news here actually. We plan to release a public generic spline API as part of our 2021 release (exact timing tbd). This will enable you to create and edit different types of 3D splines in the Unity Editor. The first feature to use that new API will be Cinemachine for setting up camera paths. Other features will use this generic API and follow soon after.”

Regarding Terrain Tools, our Graphics PM wrote about it in the forums if you would like to follow up:
https://forum.unity.com/threads/the-road-to-2021-q-a.950158/#post-6200375

Please fix the asset pipeline 2, it is too slow and I cannot upgrade.
There are several complains that script reloading and asset importing takes much longer than before.

ok ok ok, but what are your plans to confront Nanite and Lumen.. please focus on what really matters…

really? Visual scripting? I don’t choose Unity instead of Unreal seven years ago because you have blueprints or visual tools for noobs, I choose you because your workflow is fast, is clear, simple, we write code, fast shaders compilation (and they are created writing code, not using obligatory “graphs” tools), there was good documentation, your engines were optimized and works on low computer specs and your games runs good on low-end devices or we could make amazing games for high specs, using only ONE graphic pipeline, there was realtime global illumination and every engine iterarion improves BIG changes, no this stupid thing of 2018, 2019, 2020, 2021, all looks like the same thing with nothing relevant.

You are just taking all that makes you better than Unreal and throw it to the trash, losing time in a lot of stupid things, I’m really angry and yes I paid some occasions for the Unity subscription licences if some of you have that question, and yes I also spend money on great assets from the store and some of them are deprecated because your “URP and HD pipeline” thing sucks.

I’m feeling I loosed seven years of my time on your tool and you simply don’t hear anything I said or a lot of other developers with years using Unity.

Epic offers things like Epic MegaGrands and works with it´s developers, offer free access to Megascans, or things like that, but you are just in silence, it doesn’t reassure me.

WHAT IS HAPPENING WITH UNITY!!!!

Daniel, I do agree one hundred percent with all your comments, I feel exactly the same.

Unfortunately that resonates with me as well. I was shocked when I saw Visual Scripting is one of the only three feature priorities this year. There are so many areas with time spent much better than such a tool. Please solve the hard problems again, not the easy ones. Please think even more thoroughly about strategy decisions like: is splitting the render pipeline into two incompatible streams really really worth it? This must be a big resounding no in my opinion. I am looking forward to the bug fixing and performance aspects of the roadmap. You will have to really invest into your QA team and process though. I send around 2-3 bug reports per week and I always include a standard phrase already “Please do not contact me about a reproduction project”. It is completely puzzling to me how you expect users to do the task of QA. You need better internal logging, instrumentation, maybe remote access (I’d be willing to give that for a debugging session) etc. Not more users creating test scenarios for you. This will only cause frustration.

The worst is when you spend half a day creating a repro project and then you get an answer like “it’s by design” or you see the bug sit there forever because it’s low priority.

Completely agree with Chris here. I encountered the same cold bureaucratic attitude when tried reporting even clear bugs in Addressable package. There’s no way to get developer attention, they never read forums directly. The package has some design issues and long-standing breaking bugs and missing features, yet there’s no official response and no roadmap for months… Very disappointing.

I would like to echo Robert’s shock at seeing visual scripting as a top priority. Let the Bolt guys do Bolt and make you money while they’re doing it – please, please, please focus on DOTS and overall bug resolution.

+1 for pretty much everything Rob said.

At my day job we switched to one of the new render pipelines around ~1.5 years ago before switching back to SRP because the feature set was lacking too much. Sad to see there’s still big issues with these packages.

Surprised to see the emphasis on visual scripting too but can understand if it’s just something I’ve never really come across I guess…

Let’s think of something positive… I like the direction of DOTs and the perf gains I’ve had in that. I like that you are starting to focus on editor robustness and speed again. A faster more responsive editor with better iteration times (including script compilation not just the fast enter playmode) would be awesome.

> ok ok ok, but what are your plans to confront Nanite and Lumen.. please focus on what really matters…

If all you care about are particle shaders and lighting that can only run on high-end desktops, then move to Unreal. Noone’s stopping you. No one will miss you. To 99% of indie developers (Unity’s market), Nanite and Lumen are meaningless. They don’t have to “confront” them. They still are, but they’re prioritizing users that want to ship their games, not kids playing with pretty toys.

> really? Visual scripting?

I dont like visual scripting much, either. But like it or not, a lot of professionals still use it, and it’s a highly requested feature. All they’re doing is taking an existing system, and embedding it in the engine.

> I choose you because your workflow is fast, is clear, simple, we write code, fast shaders compilation (and they are created writing code, not using obligatory “graphs” tools), there was good documentation, your engines were optimized and works on low computer specs and your games runs good on low-end devices

None of those are going away, and all of them are being improved.

> You are just taking all that makes you better than Unreal and throw it to the trash

They are improving on their foundations: Fast iteration, and user-friendly workflows.
They are doing exactly the opposite of what you’re claiming. Instead of focusing on muh pretty particles and trying to nab a AAA market they were never going to get, they’re focusing on what made their engine better for real developers in the first place.

> Epic offers things like Epic MegaGrands and works with it´s developers,

Then switch to Unreal and apply for one. Good luck.

> offer free access to Megascans, or things like that, but you are just in silence, it doesn’t reassure me.

Again, most of this stuff is largely useless to most small indie developers who want to actually ship games with a unique and coherent art style. This stuff appeases kids who are obsessed with “muh amazing graffix so realistic wow”, and AAA developers.

> WHAT IS HAPPENING WITH UNITY!!!!

What should have been happening for the last several years.

> To 99% of indie developers (Unity’s market), Nanite and Lumen are meaningless

Lumen provides virtually free global illumination, and Nanite lets you not worry about mesh resolution. Even if your game is a blocky collect-a-thon, you will benefit from both.

Also, Niagara runs as performant as any other particle solution, it’s simply more capable and more extensible.

> What should have been happening for the last several years.

Deprecating old elements before new ones reach feature-parity?

>Again, most of this stuff is largely useless to most small indie developers who want to actually ship games with a unique and coherent art style. This stuff appeases kids who are obsessed with “muh amazing graffix so realistic wow”, and AAA developers.

Wait a bit, how is free textures and models ussles?, Sure for Unity users because of the licence,but you can also buy them like other studios did. Cryengine had Realtime GI for ages, and now they use it in crysis 1 on the Nintendo switch, what AAA game has unity made so far with their engine?(None Kappa).

It is very narrow minded to say that nanite and lumen are meaningless for indies. I think you haven’t even tried the current Unreal. It’s lighting system already allows for more artistic flexibility, both on low end and high end desktops, than Unity. So we’re not talking about polygons and particles here, we’re talking about creative freedom. And yes, I moved to Unreal 3 months ago after developing for 7 years in Unity. And I develop indie games with “coherent art styles”. You should see what it means to have true render passes for your art (current feature). Tech power is just the tip of the iceberg, you’ll see the art that’ll come later. Give it a try dude.

I also very much agree with Daniel’s assessment. What happened to Unity? Basic things just don’t work and don’t get fixed. The render pipelines are half baked and the opposite of the name ‘Unity’: now half the pipeline doesn’t work with the other half of the pipeline which doesn’t work with half the asset store. Change your name to ‘Disparity.’ And WHO asked for visual scripting? I’ve been a paying customer for years, but not for much longer.

NETWORKING!!!! W00t! Please tell us you’re solving things like lag compensation, client-side prediction, and all that stuff that doesn’t come with any solution that I’m aware of (that doesn’t charge you rent to use).

It’s absolute a key goal for us to have full stack solutions for key genres, will include some sort of fwd prediction because fast paced titles will need it!

Very nice changes and a year of improvements for Unity. But there is something they should do before, and that is to give us the Dark theme for all: ‘C several improvements, these years and so far nothing. It would be excellent to give us all the dark theme in these next updates, is what several users wonder, When the free Dark theme: ´C

I hope URP performance and overall performance is a high priority. Latest versions of Unity, Post Processing stacks and SRP all brought major performance regression. I hope you can bring it at least on par with previous Unity versions.

Performance is one of the focus areas for URP. If you do have performance issues, can I please ask you to report your cases so we have better visibility to address them

A good commitment from Unity must include amazing VR support. Vulkan and Quest leaves a lot to be desired and we are approaching a year on from when the competition had it stable. Not a good look but I think all that does is highlight an oversight I’m absolutely sure you’ll sort out if it’s brought to your attention.

Hi Robert, ‘platform reach’ includes our continued commitment to supported platforms, including VR support. We’ve made headways in overall stability and performance enhancements since enabling Vulkan on Quest earlier this year. These will be reflected in upcoming releases.

Hi Ziboo – good news here actually. We plan to release a public generic spline API as part of our 2021 release (exact timing tbd). This will enable you to create and edit different types of 3D splines in the Unity Editor. The first feature to use that new API will be Cinemachine for setting up camera paths. Other features will use this generic API and follow soon after.

2D Animation (PSB Importer) -not only for Photoshop users!
-Now it is impossible to work not only with third-party programs, but even with files from Adobe Illustrator – with any change in the drawing (in the order of layers) – and all the work done in 2D Animation after first importing into the Unity – will be destroyed!

Hi Alex2D! Thanks for sharing your experience with the feature. By focusing on Photoshop support, we have taken the first step to support PSD workflows for 2D in Unity. Next up, we will be engaging our users to learn more about how PSDs fit into their workflows and what other image-editing tools are used in their pipelines. This will inform us on how best to support their productions.

“Shakeelsays:
is 2D animation currently only working with photoshop?”

No no no -The 2D Animation package itself is not tied to a graphics editor – you can create animation for ANY pictures!

But PSB Importer – is a package that greatly facilitates the import of layered images (with which it is much more convenient for me to work)
from a graphics editor in Unity – unfortunately, it is completely focused on Photoshop …
Perhaps this is just “for now” and something will change. -I hope.

Hi Rus Scammell!

Please note these comments:
https://forum.unity.com/threads/2d-animation-v2-preview-packages.599356/page-9#post-5414988

– this is exactly the same situation with layers.
A situation that makes it almost absolutely impossible (at least extremely inconvenient) to work with the 2D Animation package for everyone who will try to import their drawings made in Illustrator into Unity

There, on the attached screenshots – an example of editing a file with changing the order of layers in a drawing, separately for Photoshop and separately for Illustrator, and the difference in changing the Unity meta file in which you can see how IDs were assigned

Yes, all this has been written on the forum for a long time, but I checked – in a newer version of Unity, with the latest Animation package and Importer – everything remains exactly the same

And although I have not tested for other graphic editors, I am almost sure they will hardly use this, internal and hidden from users
ID-functionality of Photoshop!

Most likely it will be the same as with Illustrator – if Adobe himself ignores layer IDs in his own (but different) editor – what can we expect from third-party programs?
So in Illustrator, layers do not have any IDs “inside”
and all those IDs that Unity will see after importing were generated right during the export from Illustrator to PSD format, just in accordance with the order of the layers at the time of export!

And therefore, any editing of a picture already imported into Unity,
any changes in it, affecting the order of the layers (and I have no idea how to work without it)
and an attempt to then “update” the graphics in Unity – can lead to the loss of everything
made already in Unity in the 2D animation package …

I will create a new comment in the forum thread dedicated to the 2D animation package and post there a new screenshot with the same problem.

-Probably it will be more convenient to discuss it there …

Pro Grids is sometimes glitchy for me, Need an editor restart to make it normal.

Also, there is some kind of snapping feature in the unity editor already, but it’s a bit clumsy to access compared to Progrids.

These are great news! Could you please update the official roadmap reflecting what was mentioned in this article? Right now it only shows “UI Toolkit: Theming”. I use to read the roadmap on a weekly basis to get to know what’s being worked on.

In completely agree. I also look at the roadmap and it seems to not have been updated in awhile :(

Thanks João for pointing this out. We are aware of the discrepancies here between that particular online roadmap and other sources. It is very much on the radar to get addressed.

URP improvements are very welcome, currently it’s lacking features that you get for granted on the built-in renderer.

Hi Alonso – the 2D team, plus all the other teams that make up the core Unity are equally focused on the mission that we describe above. 2D, in particular, are focused on rendering performance, improving 2D workflows and continuing to evolve the features they landed in 2019.

Hi Oleksandr – the 2D team is working hard on all the Core Product areas listed above plus maturing many of the great features they added through 2019.

What about 2D, new UI and physics? There’s nothing about that. I am assuming these features will follow the general stabilisation and improvements mindset?

Hi Mike – exactly, these teams are just as focused on improving the core experience for users as the ones we specifically namechecked. You are also correct generally where these teams have their focus. For instance with 2D – they will be focusing on workflows, rendering performance, and maturing the features they’ve added throughout 2019. For UI, lots of focus on bringing UI Toolkit out of preview. Physics is focused on the general definition of stability as talked about above.

Regarding DOTS, when you share info, please share as high detailed info as possible since for many types of games it can be very beneficial and if we know roughly when we can expect stuff. It can help a lot when making decisions about using it for a project or not.

When i read multiplayer for 2021 i got hopeful that DOTS will be stable (at least Entities, Physics and Animation with NetCode) until then. It is great that you are supporting GameObjects anyways. I imagine it is the same LLAPI at least if not a bridge for the current NetCode to communicate with MonoBehaviours.

Thanks, Ashkan, we can ensure that we’re doing our best to make progress and deliver a high-quality bar. It’s going to take time, but we’ll get better at keeping the community and customers aware and involved. With regards to your GameObjects comment, we can’t comment on the internals yet, but we’ll be able soon ;)

> It’s going to take time, but we’ll get better at keeping the community and customers aware and involved…

That’s hard to believe.

There are perhaps 10 or 15 threads regarding this topic, and every time it gets brought up, the responses fall into the categories of:

– answer questions avoiding anything to do with DOTS

– make nebulous promises to talk about DOTS at some point in the future

– question simply receives no answer

Let me be blunt, and repeat the parent comment:

Regarding DOTS, when you share info, please share as high detailed info as possible since for many types of games it can be very beneficial and if we know roughly when we can expect stuff. It can help a lot when making decisions about using it for a project or not.

^ This.

in Builtin?

if you’re referencing URP and HDRP, that’s not the question.

IN 2019.4, not in a packaged add-on. In Builtin, that which is actually production ready.

Hey also please add volumetric lighting in URP it will be very helpful. And also please add a built in dynamic Clouds like unreal. Please. Good Luck unity Team you have a very bright future.

Hey there! We are committed to development and improvement of URP for long term and we envision it as the successor to our default rendering pipeline in Unity (aka the ‘built-in render pipeline’). Having said that our current focus for future versions in 2021 is to bring URP in parity with built-in, improve existing feature workflows and quality as well as enhance the upgrading experience from built-in. Once we reach that milestone we will look at adding new features based on the feedback we receive from our community such as yourself. Please visit our URP public board to vote for upcoming features that matter to you most and request for ones that are not there yet: https://portal.productboard.com/unity/1-unity-graphics/tabs/3-universal-render-pipeline. Thank you!

are you updating the animator controller??? cause its now out dated! you should change the way of using animator controller make it similar to your other node based solutions and also change the UI of it

Just please don’t rush any of these features for the sake of parity – URP should remain ‘performance by default’. Build new features and systems intelligently and optimally. Keep testing features on mobile and Switch internally, not PC, for performance.

As a solo dev I don’t have the capability to optimize every aspect of the engine and trust URP to do it for me. If there is something that cannot be rolled out on URP because it is fundamentally non-performant, even it was in built-in, then just leave it in HDRP and stick to your guns. We will work around the limitations by adjusting the design of our products accordingly.

Comments are closed.