Search Unity

유니티에서 사용자 피드백을 기반으로 완성한 2021년 계획을 공유합니다.

2021년에는 다양한 사용자 요구 사항을 반영하여 정식으로 제작에 사용 가능한 기능, 워크플로, 컴포넌트를 제공할 예정입니다. ‘정식으로 제작에 사용 가능한 기능’이란 사용자의 요구 사항에 부합하고, 릴리스된 시점부터 완벽하게 지원되며, 버그 수정과 개선, 명확한 로드맵을 제공하는 기능을 의미합니다. 다시 말해 최종 제작 과정에서 신뢰하고 사용할 수 있는 기능을 의미합니다.

유니티에서는 이러한 약속을 실현하기 위해 업무 방식에도 변화를 주고 있습니다. 새로운 기능은 릴리스 전에 확실하게 기능을 검증할 예정입니다. 또한, 사용자에게 가장 유용한 기능을 개발하기 위해 더 큰 규모의 완벽한 팀을 꾸릴 것입니다. 유니티는 제품, 프로그램, 엔지니어링, 디자인 팀에 투자해 오고 있으며, 보다 효율적인 워크플로를 통해 사용자를 더 효과적으로 지원하며 예측 가능하고 안정적인 릴리스를 지향합니다.

모든 소프트웨어 개발에는 과정이 있습니다. 사용자가 개발 과정을 직접 확인하고 의견을 낼 수 있도록 매달 개발 일지를 작성하여 공유할 예정입니다. 이를 통해 사용자는 제안된 의견이 구체화되는 것을 지켜볼 수 있습니다.

2021년 유니티에서 중점을 둘 분야는 아래와 같습니다.

핵심 제품 상호호환성 안정성

Unity 2021 릴리스 시리즈는 Unity 2020 LTS(Long-Term Support) 릴리스를 기반으로 합니다. 에디터의 안정성과 성능을 높이고, 특히 사용자에 영향을 미치는 버그와 회귀(regression)를 억제하는 것이 주요 목표입니다. 유니티는 이 목표의 중요성을 인지하고 있으며, 엔진 개발 과정의 핵심 사항으로 생각하고 있습니다. 유니티는 이러한 노력이 일상적인 작업을 진행하고 게임을 한 단계 발전시키는 데 있어 큰 기여를 할 것이라고 확신합니다.

#버그, #회귀, #크래시 이외에도, 손상된 워크플로와 상호호환성도 버그로 간주하고 이를 기록하고 있습니다.

그 밖의 중점 분야는 아래와 같습니다.

  • 워크플로 사용성UI 제작과 같은 총체적 워크플로의 업그레이드와 이를 지원하기 위한 핵심 툴, 예를 들어 씬 툴링 시스템(Scene Tooling System)이나 검색 및 필터링(Search & Filtering) 등을 통해 편의성을 높인 수정 사항을 제공합니다.
  • 플랫폼 도달률:차세대 콘솔, Apple Silicon, 새로운 AR/VR 플랫폼을 위한 플랫폼 지원 및 출시일 콘텐츠, 그리고 지속적인 최적화와 모바일 아키텍처에 대한 지원이 제공됩니다.
  • 성능 반복 작업 속도: 에셋 임포트, 빌드 및 배포, 에디터 내 반복 작업까지 개발 라이프 사이클 전반에 걸쳐 팀의 생산성을 높입니다.

 

기능

Unity 2021에서는 그래픽스, 멀티플레이어 네트워킹, 비주얼 스크립팅이라는 세 가지 영역의 기능을 개선해 나갈 예정입니다.

 

그래픽스: 스크립터블 렌더 파이프라인  

유니버설 렌더 파이프라인(URP) 솔루션을 개선하고 고해상도 렌더 파이프라인(HDRP)을 안정화할 예정입니다. 렌더링 파이프라인의 장기적인 목표는 Unity 모든 기능과 완벽한 상호호환성을 갖추는 것으로, 사용자는 툴 생태계를 이용해 씬을 통일된 방법으로 제작할 수 있게 됩니다.

 

비주얼 스크립팅 

Unity 2021에서는 Bolt 비주얼 스크립팅을 Unity 핵심 기능으로 제공할 예정입니다. 이를 통해 노드 기반의 개발 툴 전반에 일관성을 부여할 수 있습니다. 비주얼 스크립팅의 워크플로를 다른 노드 기반 솔루션과 통합하면 사용자 경험이 향상됩니다.

 

멀티플레이어 네트워킹 

안정적이고 지원 가능한 넷코드 파운데이션이 제공될 예정입니다. 첫째, 기존 Unity 게임 오브젝트의 문제를 해결하기 위해 데이터 지향 기술 스택(DOTS) 넷코드 영역을 확장할 것입니다. 둘째, 오픈 소스 소프트웨어(OSS) 멀티플레이어 커뮤니티의 의견을 바탕으로 주요 장르에 대한 풀스택(full-stack) 솔루션을 제공할 것입니다. 마지막으로, 멀티플레이어 제작에는 넷코드 제공만으로는 부족하므로, 사용자의 의견을 반영하여 툴, 문서, 샘플에 많은 투자를 할 예정입니다.

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(게임 오브젝트)에 안정적이고 지원 및 확장 가능한 넷코드 파운데이션이 제공됩니다.
  • 멀티플레이어 게임 툴 지원을 개선합니다.
  • 핵심 제품 상호호환성 및 안정성이 위와 같이 향상됩니다.

멀티스레드를 바탕으로 엔진 내에서 자체적으로 성능 최적화를 수행하는 아키텍처와 Unity 발전의 기초가 되는 데이터 지향 기술 스택(DOTS)을 계속 발전시킬 예정입니다. 이에 관한 자세한 내용은 향후 블로그 포스팅을 통해 설명하도록 하겠습니다.

유니티는 커뮤니티에서 제공하는 피드백을 매우 중요하게 생각하며 앞으로도 지속적인 참여를 부탁드리는 바입니다. 매달 개발 일지를 통해 정기적인 소식을 공유하여 진행 상황에 대한 정보를 나누고 유니티 개발자와의 소통의 장을 마련할 예정입니다.

8월 14일 태평양 표준시 오전 9시 30분/미국 동부 표준시 오후 12시 30분에 /r/Unity3D subreddit에서 진행되는 무엇이든 물어보세요(AMA) 세션에 참여하세요. 두 시간 동안 유니티 팀원이 다양한 질문에 답변해 드립니다. 또한, 향후 며칠간 Q&A 포럼을 개최하여 모두에게 질문의 기회와 피드백을 공유할 시간을 제공할 예정입니다.

114 replies on “2021년 Unity 로드맵”

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.

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 ?

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.

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.

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

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

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!

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

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.

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.

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.

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다