2019.3 entered the final stages of beta testing

Nah, we’ve been in this situation and we’ve had these discussions for years now. Nothing is going to change.

 

I just want to mention that Unity specifically delayed 2019.3's release past December because they acknowledge that there are so many bugs and performance regressions and they want to fix them. The fact that it's not already out of beta and they haven't given a specific release date is a good thing, compared to if they'd released it earlier this month or if they intended to release it with 2019.3.0f4 (which I don't believe they will).

 

That would mean something if we had the old model of perpetual licenses and paying for upgrades. Now that the business model is subscriptions and the Asset Store, they are not really being hurt by the delay in release, so I don’t see why you’re trying to frame it as some sort of benevolent action.

I wish I knew when I was in school that saying “I delay the release of my homework because it’s not ready” would be viewed as a good thing.

 

They're targeting a January release and the bugs and regressions are such that that goal, in light of Unity's past development speed, even that is a monumentally optimistic goal.

 

The fact they delayed 2019.3 is quite positive and I believe it's a good decision. But something tells me that it's just because 2019.3 is a total bugfest worth an alpha state, not because they are gonna fix the performance. It's not something unexpected because they refreshed the Editor UI.

I won't be so sure about any performance regressions being fixed. If you will read @Peter77 reports through 2018-19 you will notice that engine became slower with every new version. I don't want to repeat my statement I made a few times, but in short: performance regressions were present in every major release since 2017 at least and the situation became worse. The fact that QA started using Peter's project for their internal tests doesn't mean anything. They are "highly concerned" about performance as they said on forums, but come on.

They will use their DOTS stack to improve on performance but it will be enough to get the speed of old 4.X releases, not to actually improve it to a new level, as I think. The difference between 4.X and 2019 is somewhere around x2-4 according to Peter's reports. He measured not only the editor performance but also the runtime, editor launch times, domain reloads + enter play mode, and compilation times. So the slowdown is persistent across the board.

If you want to do something good make it bad and then make it a bit better. Save that sentence for the next Unite where they will maybe show the editor speed up.

 

I'm not trying to say that it's benevolent (or that it's malevolent), just that it's a good thing they course-corrected by delaying 2019.3's release and by collecting the major known regressions at the top of the release notes.

Personally, aside from the performance issues with adbv2 this hasn't been significantly less stable for me than previous 2017 or 2018 releases (in the large 100GB project I work on). 2018.3 had the huge change to prefabs which was a significant usability regression until several months after 2018.4 LTS was released, if anyone remembers that, and so far 2019.3 has not had a design problem like that. YMMV of course though, since Unity's scope is so expansive that even the very large project I work on only covers a fraction of what Unity allows. And I don't mean to imply that stability and usability is great, just that it's around par - adbv2 aside - compared to the past couple years of releases (as of f3).

2019.3 is effectively useless for my team until the adbv2 refresh performance issues are fixed, so we're sticking with 2018.4 until that happens.

 

I have a high confidence that they're fixing the performance regressions listed at the top of their f3 release notes. You can see them here: https://unity3d.com/unity/beta/2019.3.0f3

There are other performance regressions which may or may not get fixed. Unity is so big that you could measure performance of 100 different things and only capture a single percent of the different variables involved in all the areas of performance. I'm not saying it's good that "overall performance" has declined over time, but I think it's important to frame it like it is - many different things combining to give an experience that isn't ideal, rather than one single thing that is either fixed or ignored.

I also think that's a big reason why Unity will continue to have trouble keeping performance in check without proper dogfooding (either via their own projects or better lines of communication with external teams) and with more strict performance testing for individual changes they make - there are so many small things which add up to a bad experience for real products, which by themselves don't look like a huge deal in a small demo project.

 

I'm glad Unity is noticing some of the editor performance issues with Unity 2019.3. I'm hoping Unity will fix a lot of the regressions as well as the UI Elements bugs and various crashes, all before Unity 2019.4 LTS officially releases. I think Unity took the right step by delaying the official release to January 2020.

 

https://forum.unity.com/threads/workflow-case-study-show-us-your-pain.637552/

Here is a good place to give feedback

 

Huh, I guess I have something to do after the holidays.

 

It is slower to make a game that requires a lot of workarounds. It should be unity technologies that goes through that pain as opposed to its customers. I agree that each unique feature in the game requires its own workarounds, but everything that is common to making a game should be a pleasant and hassle-free experience (in perfect or competitive world as this is what is going to bring you customers and $$$).

The ^gentleman sums it up. I can also imagine that the amount of time that goes into trying to reproducing issues on UT side is heavy. Most of them aren't even able to be reproduced therefore that time becomes wasted.

Imagine trying to reproduce an issue on a large game. How the hell are you supposed to know what caused that issue without having the entire context of the application?

100%. Also by experiencing something yourself, you understand it better. You also might bump into ideas for improving the engine for what you're trying to achieve. It is harder to come up with these ideas solely based on external feedback.

"There are so many small things which add up to a bad experience for real products". I think so too, I can imagine it is really hard to perform efficient and reliable testing on them in isolation, that is why I think integrated testing would be highly beneficial and more reliable.

 

Again, I can not stress this enough: why the hell do any of you think that Unity will learn anything from making their own games when they don't even backport the things they had to do to get any of their demos to work?

 

@Murgilod is kinda right. And here's my take:
The reason why UnrealEngine does is because they aren't in the middle of a technological shift. Unity however is rewriting all their tech into DOTS (which I applaud that btw, kudos). Epic started from Scratch with UE4 and they also had in mind from the begining two things, make games and provide every tool/feature they do to everybody. Unity was never a scalable AAA engine, so nobody at Unity though about making games with their own tech.
This is "I believe" the reason why Unity won't spend time making games. At least for now, things might change in the future, who knows.
In any case, I think now is not the moment for Unity to invest in AA-AAA games, they need to improve the Editor instability/workflow first and finish the engine DOTS rewrite.
I'm really excited about DOTS, my quick initial tests with gave me ridiculous performance improvements! Keep the great work guys!

 

Worth mention that I was a private early adopter of UE4 even before it was called UE4 and before anyone here knew about UE4 (back in 2012). And they told me all that stuff, I didn't came up with that by myself.

 

The direction Unity is going in with their tech is definitely a good one. And I agree that keeping their samples up to date is difficult when things are changing a lot. But at the same time there’s room for improvement on that front. A character controller using cinemachine and the new input system really wouldn’t hurt, for example. This just involves hiring a few extra staff. Just as being more responsive on the forums requires hiring a few more staff, to relay info/feedback from and to the various Unity teams in a timely way. The question is one of cost/benefit and I can see the benefit being well worth the cost in this case: happier users and developers who are not left stewing in the dark / unity Teams made more aware of user needs and concerns.

Looks like I’m digressing again! But it’s hard not to go off-topic on these threads because so many different woes are interrelated... the common thread to many of our problems is “communications issues”. These forums have got to go. When important info is passed down via a thread in a sub-forum, it’s pretty easy to miss it. In this thread, we’ve complained about things like camera-stacking in URP but in another post somewhere, someone from Unity has explicitly said this is ready and should arrive in the first half of January, when staff are back from holidays. A forum with better UX (something like discourse.org) would go a long way towards passing on important info like that and reassuring us that we’re being heard. You can do it Unity! Just show us a little bit more love.

 

I think it would be a better idea if UT partnered with talented game developers. UT could give aspiring developers a large team of Unity programmers with tons of experience and engine knowledge. There's several Unity developers off the top of my head I can imagine benefiting greatly from having the talent, expertise, and money that UT could provide. They could start a greenlight program where aspiring developers could put their game projects on, allow Unity developers to vote on these projects, and UT can make the final decision. UT could provide free pro and source code licenses to all members of the team, and help the project be properly developed and advertised. And this would be a great way to dog feed the improvements back into core Unity. Instead of having one core game project the team focuses on (unless they stumble across a golden goose, like Fortnite), they could branch out into various game genres, like RPGs and online shooters. I think this would be a much better investment than those tech demos that never get updated to work with modern versions of Unity.

 

They already work closely with few selected studios to gain what you mentioned here.

 

They are already doing this:
https://forum.unity.com/threads/new-standard-asset-characters-third-person.526612/

While I agree that more feedback between staff and developers would be nice, I don't think this really boils down on lack of staff atm, it seems to be more of an organizational thing, just throwing more people in doesn't necessarily mean more will come out of it all.

What is a bigger problem IMHO right now is that to get hold of various Unity staff members from different teams requires one to go through very different channels, some teams are more responsive on forums, some teams have active staff on the official discord, some teams handle issue reports way faster than others after QA delegates them through. The issue here is that there's a really mixed setup here and it takes a lot of time to figure out the most effective way to reach a specific team/staff members to get your answers/feedback through.

To give an example, there isn't always logical forum sections for some Unity components where official discord might have channels for them and vice versa. For example discord group has ml-agents channel which is relatively active but there's no clear place where ml talk would go in the forums (so that it would reach the target audience), ML-Agents staff is quite active in that discord channel as well. As opposite example, official discord doesn't have any good place to discuss the new input system while forums have dedicated section for it and input system staff is quite active on the forums. I can only imagine how hard it is for new users to figure out these kinds "paths" to get the support/feedback channels they need.

 

“Doing” sounds like an exaggeration when last update was a year ago and the readme says it’s supposed to release in 2019.

They already abandoned this sounds more accurate.

 

This doesn't look abandoned to me at all: https://github.com/Unity-Technologies/Standard-Assets-Characters/commits/master

As for release targets, you have been around long enough to know how these go with Unity.

 

You’re right, those commits make it look like someone’s developing it on their free time if he feels like it.

 

@rizu That particular character controller has in fact been discontinued, if you read the thread. I spent months trying to get it to work properly and trying to get info about it from the developers. 2-3 months ago someone from Unity advised that the project would be taken over by the “Education Team”. There is no new github repo from that team though. Also, the controller is not even hooked up to Unity’s IK and falls short on a number of fronts. Plus it’s overly complex and has crap documentation. Hence my comment and how it would be nice to have an up to date version of a character controller! I kinda think it’s a bear minimum for an engine predominantly used to develop games. But that’s for enough thread! This one is about 2019.3 being nearly out of beta. Fingers crossed that it’s a solid version, even though I’ve now moved to 2020.1!

 

I read the thread and you even replied to this comment two weeks ago:

Will told about this 1.5 months ago in November. Do note that changes like these take time, things are not going to happen over night in organizations like Unity. Code ownership has changed (and it's still Unity that maintains this) so it'll take time for people to get back into speed with the thing after figuring out how the current team wants to advance with it.

All in all, I don't get the overwhelming negativity and fact twisting here (it's very clear that project hasn't been abandoned). I guess some people had expectations for that thing to be production ready by now but these things take time due to changing priorities, plans change etc. It's also not just Unity, it's same all around this industry.

It's also good to note that while there is a need for better character controller with current Unity, most of the new engine components are focused on DOTS now. I was frankly surprised they even did the new standard assets without DOTS in the first place but I guess it's meant to carry over until DOTS is actually production ready in few years.

 

I'm not saying that making a AA / AAA Game is the only solution but just one of many. Just to get back on track with our dispute here... the discussion was around the idea that they are releasing features and marking them as "release candidate ". I understand that unity is undergoing critical changes in their engine and things will be broken. This evolution is necessary. However, my only argument/suggestion was that if you want to tag a release with "Release candidate" then please, go through a more thoughtful and thorough testing procedure.

Hence the suggestion of making big-enough games as testbeds for big releases. Also, I do not know where the AAA keyword came from, definitely not from me since I never once mentioned games of AAA scale Good and bad points all around from people, I believe it is important to remind UT that we all care about the communication between its users and them.

 

Fair enough - I did forget they said they would be starting production of this in the new year. So apologies for that. But my broader point was that the first post in the thread said it would be shipping by 2018.2. And now we’ve recently been told production is about to begin, this time with a new team. So as for it being “discontinued”, here’s what they said: “We’re going to do a complete rewrite”. Yay for that but I’ve potentially just lost a few months worth of work because they’re saying they are - ostensibly - discontinuing the existing code. So excuse me for sounding slightly disgruntled! It’s just a bit of tough love.

PS - there is a DOTS sample character available on github. But I can’t make any sense of it alas.

 

We had already some movement in this field and can be noticed to certain degree on this forum.
Few months back we had discussion on this forum, regarding needing / or not more staff, to manage forum.
The official response was, that they had at that time, at least one brand new dedicated person, to deal with that matter. It meant to be more, from my understanding. However, what I see instead, is that existing Unity staff, like engineers, are a bit more active here and there on the forum, while haven't been previously. At least this is my impression.

The consensus was, to target as many responded threads as possible, to give at least some reasonable answer.
So it was past few months, what I noticed myself. If is still, I haven't specifically tracked. But officials engagement is still rather low in my view. So I am not impressed regarding results. Maybe my expectations (rather given hope) were a bit different (naively higher)?

 

Quick side-question to the Unity guys:

Why isn't the Roadmap accessible from the Products section of the website anymore? If the design is changing, we developers would appreciate a more prominent place for the roadmap link to access it and periodically check out about current and future Unity plans.

This sudden change felt like a silent way of hiding it and that seems a bit weird.

 

The whole "under construction" status of Unity caused an awkward situation. A client asked us "what benefits our players will see from upgrading the game from Unity 2017 to 2019?" and that had us scrambling through Unity release logs to build a list. That list turned out quite short: besides from the Post Process Stack V2 looking a bit better than the abandoned Amplify post process assets we were forced to replace, there was nothing. Not even performance: the game actually became heavier on the CPU, specially on consoles, forcing us to optimize some more to match the 2017 build framerate.

Don't get me wrong: the editor did improve by a lot, our build times decreased significantly, we can use more modern C#, and we can actually debug in IL2CPP now. But pretty much all new player-facing features introduced in the past two years implies prohibitive paradigm shifts: using DOTS would require a complete overhaul of the game code, HDRP would require us to re-create all shaders manually using Shader Graph (and deal with the issues of experimental status), and URP isn't even an option as it would be a visual downgrade from deferred built-in while still requiring all shaders to be re-made.

I look at the Shaders sub-forum, all those posters merrily trading knowledge and assets that are tied to a doomed feature, utterly incompatible with its upcoming replacement, and can't help wondering if UT is aware how tumultuous things will get when they decide it's time for people to "move on".

 

Deferred is just around the corner for URP. And yes, moving on is painful but I think worth it for the neat integration of shader graph, the visual fx graph, etc. DOTS seems too big a hurdle for me right now. That requires a more radical paradigm shift in approaching game design. I tend to learn by looking at examples, and there are too few of those right now for DOTS.

 

This is an existing game, and not a small one. There are tons of custom surface shaders, many of them part of 3rd party assets. That's a lot of dragging wires around, not no mention the risk of stumbling on functionality that is not yet supported by SG. I cannot possibly justify two man months (possibly more) on a task that brings no noticeable user-facing benefits (assuming an hypothetical version of URP that has feature parity with built-in, we would end up with something that looks the same).

We may have no choice if UT ends up being jerks and make SRP mandatory for PS5 and XBSX, however.

 

The change to shader code for HDRP and URP brings it in line with shader dev from a less Unity specific angle. The SRPs, similar to how post-processing stack effects currently work, are just bog standard HLSL shaders that get cross compiled to GLSL/Metal/Other™. This is a dramatic improvement over the old method of ShaderLab containing Cg, as Cg hasn't seen an update in nearly a decade and suffers from a lot of documentation/modern use issues because of that.

You're also acting like the only way for anyone to make shaders is by using ShaderGraph, which is just outright wrong. What this does is make shader dev engine agnostic, allowing for a greater degree of skill transfer. To add to that even more, the syntactical difference between HLSL and Cg aren't huge, since both had parallel development.

Having code based on existing frameworks is a good thing, especially ones that actually have active support.

 

The benefit of URP/HDRP Is being able to look forward rather than hoping UT will support new hardware on the legacy pipeline. I personally would prefer it if UT focus on non-legacy stuff! Sounds like a tough business decision, with both options being risky so I guess it all depends on what stage of development you’re at. You still have almost a year before those new consoles are out, i think? If you’re ship date is no time soon then URP/HDRP is the less risky option and one which will leave you with less regrets in the long term, if you want to add features or improve performance. Plus you’ll have picked up the skills needed to avoid that same pain in the future. I have the advantage of being a hobbyist with no deadlines but my own!

 

The problem is that if you’re already far into production, switching to SRPs can cost a lot of money. That budget would be better spent on improving the game itself. PS5 and XBSX should be supported because people are already in production now, with plans to launch on new consoles and SRPs were not (and still are not) production ready. So it turns out that if they don’t support new consoles, people could lose tens of thousands of $ either by having to pay for work on conversion or by losing revenue on new consoles.

 

Haven't Unity shaders have been HLSL only for years now? If you have some information on how to rewrite surface shaders from built-in to SRP I'm all ears, because I found no documentation on that whatsoever, with several forum posts pointing towards shader graph.

 

...and it will require upgrading to 2020 tech stream, which adds extra development costs as we'll have to keep updating Unity mid-development for over one year. I'm not sure why a system that was supposed to allow devs to write custom renderers depends on upcoming internal engine changes to be able to handle a deferred renderer.

Here's the thing about non-hobbyst development: uncertainty is bad for business. Game development is already risky as is without jeopardizing our budget by relying on upcoming features, ever changing APIs and surprise deprecations.

 

This is what I dislike on almost all Unity systems. Pure C# packages do transition over to newer engine versions easier but as soon as there's a native code element, you get the dependency to engine and api version and you are forced to roll onwards. I REALLY dislike that they bundle everything in single player dll when they could just keep different engine components more modular, have each their own native dll's (or libs and link them at build time) and keep the thing versatile.

For example, if you use your own or 3rd party input system, you get native dll that's decoupled from Unity's own updates and is less likely to break in the future engine version, now with both old and new input systems, if something breaks on Unity's native code (like has happened on new input system few times already), newer engine versions always risk you of getting something that used to work being broken again, you can't cherry-pick things that function for you as there's dependencies to the black box side of Unity.

 

Both consoles are confirmed to have backward compatibility with the previous consoles. Since your project and other projects are already far into development that means you won't be doing anything major/special to take advantage of the new consoles so the problem is already solved.

Release for the current consoles and it will also work on the new consoles with no extra work. The next projects being made would use one of the SRPs. URP is already production ready only HDRP left to reach that stage.

 

We're far into development on PC and taking advantage of modern GPUs. For example, some levels will be built with volumetric objects, like when you fly into a sandstorm, it looks something like this



There's no way it could run on ancient PS4 hardware. And currently, it's impossible to recreate on URP/HDRP because some critical functionality is lacking (RenderWithShader). Even if we somehow make it run on PS4, it would look much worse than on PC, so there's really no sense in doing so. And even if we somehow find a way around and port this volumetric solution to SRPs, doing it again from scratch would cost us huge amounts of time and money.

URP is not generally production ready, it doesn't have many basic functionality, way more limited than builtin. It's only tagged as production ready by Unity marketing.

I mean, of course you can produce a game with URP, but not all the kinds of games that were being produced in Unity on builtin, that developers expect to be able to develop in Unity based on what Unity used to be like. No feature parity yet.

Our past game did well on PS4 and we're looking forward to working with Sony again, I hope Unity won't kill that opportunity.

 

Ah, I see. You're in a unique situation.
Have your team tried HDRP or just looked into it? Maybe the density volumes can support your implementation with the HDRP volumetric system. I'm guessing you're working on a system similar to the one in Squadron 42/Star Citizen

 

That's exactly what they are doing, isn't it? It's why we now have the package manager, each of those packages is basically a DLL (look in the Data/Managed folder of a Windows build, it's all DLLs). You can choose to cherry pick not only which packages to get but also which versions of them - you can get older packages that worked for you before, or the newest "stable" version, and in many cases a newer experimental or preview package.

 

Not sure how unique. I guess anyone who's in production, which means past the research phase, isn't too happy to go back and allocate more budget to research again. We just want to produce our game, improve and test the gameplay etc, not go back to research and tools-making phase. We might take a look into HDRP's volumetric solution when it's truly ready and documented but I don't expect it to be before 2021.

Anyway, it's not the subject of this thread, I apologize. I'll create a separate thread to try to get some answers after the holidays.

 

I think you missed the main point I was trying to make, I'll quote my comment: "Pure C# packages do transition over to newer engine versions easier but as soon as there's a native code element, you get the dependency to engine and api version and you are forced to roll onwards"

While c# side of the packages transition in general nicer from engine version to other these packages often have native code side that's in the Unity player binaries and is NOT distributed through the package system at all. This is the core thing that forces people to move to newer Unity versions with current package workflow. To give few examples of this:

- new input system has native code embedded in player binaries, this is why new input system was broken for a long time while in 2019 was in beta. 2018 Unity versions worked fine with same input system version.
- SRPs (HDRP/URP) depend on native code for perf crucial parts, we only get the scriptable C# part but if they need to add some feat for upcoming version, they can't always do it on C# package alone as you also need native code (c++) side changes and these things are not getting backported say from 2020.1 after Unity released their major version like 2019.3.
- Current DOTS packages require changes only available only on 2019.3.

The whole point I'm trying to make that this current setup is like 50% there for being truly modular. They still ship native code within the editor/engine version and only managed / C# code is shipped in packages. Of course further they go with DOTS route, more c# code we'll get but there's always going to be parts that require native code access (rendering, input libs etc).

What you referred for managed DLLs was just managed assemblies generated by each package but these don't contain native code.

 

I've yet to see a package update that's not happening at the same time as a Unity engine update or moreover tied to the new version.

 

As mentioned before, pretty much all major packages have their versions tightly tied to specific Unity versions. For example, straight from the SRP package GitHub:

Basically, now that 2019.3 reached release candidate, SRP 7.x won't see any new features, only bug fixes going forward. The packages are considered part of their respective engine versions, but now they can be bug fixed without deploying a whole new build (and we can modify them without decompiling Unity's managed DLLs). They don't allow you to get new features without upgrading the entire engine.

 

I've noticed console from time to time has errors, messages or warnings and they don´t show up even if icon is clicked. b12

 

That nobody at Unity hasn't bothered to fix this before shipping is scandalous. I have the same problem. I can't report bugs because the Bug Reporter crashes all the time. The only conclusion I can draw is that Unity simply isn't interested in OS X bug reports.

 

What Unity should do is create a web page "How To Find Us" and be transparent about this.

 

mine worked the other day when I logged an error

 

Another conclusion is that because Unity isn't receiving bugs, they don't think there's a problem.

I'm reminded of the recent situation with the asset store. Unity hid the way to access the old asset store, and based on that, concluded that people favored the new asset store, because all of the traffic was going to the new store. lol

 

While I appreciate your attempt to put a positive spin on the situation, I couldn't disagree more: if Unity doesn't even notice the absence of OSX bug and crash reports, then they really aren't interested.