The road to 2021

 1 year ago
source link: https://blogs.unity3d.com/2020/08/13/the-road-to-2021/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
The road to 2021

Search Unity

We are excited to share our plans for 2021. We’ve listened to your feedback and established our plan based on what we’ve heard.

Our 2021 product commitment is simple. It’s about giving you production-ready features, workflows, and components based on what you have told us you need. We consider a feature production-ready if it fully meets your needs, is fully supported from release, and has timely bug-fixing, improvements, and a clear roadmap – in other words, features you can rely on throughout your production.

To execute predictably we are also changing how we work. We’ll do less, we’ll do it better, and we’ll prove it works cohesively before we release it. We’re bringing bigger, complete teams together to develop the features and functionality that are most important to you. We’re investing in our product, program, engineering, and design teams so we can increase our focus on supporting you with great workflows and commit to predictable, reliable releases

All software development is a process. Every month, we will invite you to view and comment on our progress through a series of developer diaries so you can see the theory become reality.

These are our focus areas for 2021:

Learn more about Unity Pro

Core product interoperability and stability

The Unity 2021 release series builds directly on the Unity 2020 LTS (Long-Term Support) release. Its key focus is to increase the stability and robustness of the Editor, to drive down bugs and regressions, particularly those with the greatest user impact. We don’t want this to be a side note. We want it to be the foundation upon which everything else stands and takes us forward. We know this is what makes the difference when you’re trying to both make day-to-day progress and take a game over the line. 

Another important change is that in addition to #bugs, #regressions, and #crashes, we are incorporating broken workflows and interoperability in our definition as bugs and logging them as such.

Additional areas of focus include:

  • Workflows and usability: quality-of-life fixes through upgrading aggregate workflows, such as UI Authoring and the key tools to enable those, e.g., Scene Tooling System, Search & Filtering.
  • Platform reach: platform support and launch-day content for next-generation consoles, Apple silicon, new AR/VR platforms, and continued optimization and support for mobile architecture.
  • Performance and iteration speed: improving your team’s productivity across the development lifecycle from asset import, build and deploy, and in-Editor iteration.


For Unity 2021 we are evolving three specific feature areas: graphics, multiplayer networking and visual scripting. 

Graphics: Scriptable Render Pipeline and Tools 

We will mature our Universal Render Pipeline (URP) solution and stabilize the High Definition Render Pipeline (HDRP). Our long-term goal with our rendering pipeline is to have complete interoperability with all Unity features so there will be one way to build your scene with an ecosystem of tools to support users. 

Visual scripting 

In 2021, we will provide Bolt visual scripting as a core feature, built directly into Unity. As we do this, we will bring consistency across all our node-based development tools. We know it is key for a great user experience to unify the workflows of visual scripting with other node-based solutions. 

Multiplayer networking 

We will deliver a stable and supported netcode foundation. First, this means expanding the focus beyond the Data-Oriented Technology Stack (DOTS) netcode space to solve for current-Unity GameObjects. Second, we are committed to delivering full-stack solutions for key genres by building alongside the incredible talent in the open source software (OSS) multiplayer community. And finally (we heard you), multiplayer creation needs more than just netcode, so we plan to make a significant investment in tools, docs, and samples to make it easier to get started.

As evidenced by the success of games like Mediatonic’s Fall Guys: Ultimate Knockout, great multiplayer games are possible in Unity today, and we will keep making it easier.

Product release schedule

Our product release schedule in 2021 will be anchored in these release commitments:

Unity 2020 LTS (Q1 2021)

  • A long-term support (LTS) version of Unity 2020. A stabilized change-set from Unity 2020.1 and the upcoming 2020.2 releases.
  • Improvements specifically focused on quality of life, like reorderable arrays and lists in the inspector, improved inspector copy/paste, the ability to mark an object as “default parent” in the Hierarchy, and a long list of improvements to existing features and toolsets.
  • Continued focus on iteration speed, developer tooling, and performance improvements such as updates to IL2CPP to avoid unnecessary reconverting and recompiling code when there are no code changes.
  • Improvements to Asset Import stability and robustness.
  • SRP stabilization improvements for both URP and HDRP.
  • Support for PlayStation 5, Xbox Series X and Apple silicon platforms.
  • Increased contributions and collaboration with the OSS multiplayer community.

Unity 2021 Product Release Cycle (March–October 2021)

  • Provide visual scripting integrated directly into the Unity Editor that is robust, stable, and production-ready.
  • Iterative improvement of the core experience for URP and stable HDRP. In the Asset Store, enabling users to discover URP and HDRP content easily through tagging and filtering. 
  • Stable, supported, and extensible netcode foundation for current Unity (GameObjects). 
  • Enhanced multiplayer games tooling support.
  • Core Product interop and stability improvements as above.

We are also continuing our efforts for our Data-Oriented Technology Stack (DOTS) to lay the foundation for the future of Unity and the architecture that delivers multithreaded performance by default. More on that in future blog posts.

The feedback our community provides is priceless, and we want you to come on this journey with us. We’ll be sharing regular updates via monthly developer diaries to keep you informed on the progress we’re making and will provide ways for you to get in touch. 

Please join us for an AMA on the /r/Unity3D subreddit tomorrow, Aug 14, at 9:30 am PST/12:30 pm EST. Unity team members will be on hand for two hours to answer your questions. Additionally, we are also hosting a moderated Q&A thread in the forums for the next couple of days to give everyone the chance to ask questions and provide feedback.

117 replies on “The road to 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!

*”and so many things actually finished….” – and so FEW things actually finished….

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 in diversity.

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!

rendering pipeline to unity 2019 and 2020 no fixed for old mobile

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?

We’re actively working on defining the solution for our customers for real-time GI, fully understanding how impactful dynamic global illumination is to modern games and many of our customers’ use cases. While we are not on track to provide a replacement in time for 21.1, we are still aiming to share the plans by the end of 2020.


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’m thinking he’s referring to NodeCanvas and FlowCanvas — Not PlayMaker. :/

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.

Unity 2020 loading speed is very low ! really disaster.

So you wanna do less….less…

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?

We are still 100% committed to DOTS, however it’s clear that the roadmap and expectations for DOTS have been confusing quite a few of our users. We intend to clarify the road to DOTS in a future blog post for everyone.


It’s sounding like no hope for Dots until 2022. 😔

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.

Hire this guy.

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

Seconded. 30% and exclusivity to AssetStore is highway robbery. :(

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

what multiplayer did Unity do for fall guys and how did you make it easier?

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.


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!

Yes, it’s exactly that. Try it out in current 2020.2 alpha builds.

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:

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.


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

I think someone needs some time out from the internet

Agree with you too

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 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

Dark mode is free in 2020.1.2. Go to preferences < general.

Literally yesterday, for 2019 and 2020 versions

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.

We need Splines !! please :)

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.

is 2D animation currently only working with photoshop?

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:

– 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.

The great forgotten are the 2D features, very sad :'(

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.


Yes, what about new 2d features?

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.

Great news!

Thanks! It’s greatly appreciated coming from you :)

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?

liquid fun

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.

Platform support (for next gen) needs to be added to 2019.4 LTS.

Next gen support will be included in both 2019 and 2020 LTS versions in addition to 2021

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.

About Joyk

Aggregate valuable and interesting links.
Joyk means Joy of geeK