Unity is not worth using right now

I would like to update this. @Tautvydas-Zilys ... one of the software engineers of the desktop platforms stepped in. With his concerted effort on the TOTD silent crashes he gave me a process to follow to gather data on the silent crashes. I sent him the data and he pinpointed the crash to be graphic driver buffer overrun. He also gave me other tests to perform to assure it was not with RAM. It pinpointed the graphics card. That card deteriorated more over the next few days and caused black screen tears and blinking. I have ordered an RX 5700 XT to replace the GTX 1080 just because the amount of complaints going back years on Nvidia drivers and Unity made me very wary of them as a company, regardless f those fears are unfounded or not. On the other crashes and inability to even open Cyclotronica on a PC and the bug QA team telling the designer [disclosure..my son, a hardcore gamer] to make a video of the process..right.the app won't open on his machine..alot of good that will do..they closed the bug. He dug that up after I sent him the bug report number and determined it was the fault of the Burst compiler issuing instructions in AVX2 which my son's computer could not deal with as it could only deal with AVX instructions and the instructions should have actually been issued as SSE. He sent a workaround by altering the Package.manifest json which instantly cured the crash.

So..do I think someone needs jacking in the bug QA team.?.yes. But, Unity has some dedicated folks on their engineering team who want their users, no matter if they are just a little ole cranky indie dev like me working on a family project or some huge studio dispensing huge bucks for hundreds of pro seats, to have a proper development experience with their application.

 

Not to hijack the thread, but it might be a good idea to check if the card is still under warranty. Might be possible to repair or replace it if it is.

Radeon cards at some point of time had an odd differences, where GLSL compiler for Radeons used to be much more strict. But that was years ago. Might not apply to them anymore, and not that relevant to unity unless you write shaders in pure GLSL.

 

What if Unity released 14 game engines:

1. 2D + Tiny + DOTS
2. 3D + Tiny + DOTS
   
3. 2D + HDRP + MONO
4. 3D + HDRP + MONO
   
5. 2D + URP + MONO
6. 3D + URP + MONO
   
7. 2D + SRP + MONO
8. 3D + SRP + MONO
   
9. 2D + HDRP + DOTS
10. 3D + HDRP + DOTS
    
11. 2D + URP + DOTS
12. 3D + URP + DOTS
    
13. 2D + SRP + DOTS
14. 3D + SRP + DOTS

That way each would have a stable basic setup that just works out of the box for the core features of a game engine 2D/3D, renderer and API.

 

Nope, managing 14 versions of the same software only would guarantee that maintaining code is super complex and basically impossible to make stable.

Package manager already complicated things. It would actually simplify if the given developer could simply update a single system he needs and ignore other ones. Like, imagine you could production-ready system prior to the next major engine release. Sweet!

The reality is incredibly difficult to isolate changes and truly compose the engine out of independently updated packages.

There are constant changes to the engine's core (doesn't matter Unity/Unreal) and keeping things separate/isolate is impossible. You'd still need to merge all of these core changes. Or you would have to develop a given package (like entire renderer!) without using change to other modules for the next few months.

Alternative: design systems in mind that code would be different in every 14 flavors of the engine? It would be a guaranteed bug fest. It would cost a lot of time and frustration. I would never want to work on developing engine in so many versions. And many programmers would hate too, obviously.

Most of the major software offers only a single branch/version and still comes with issues. Even if only one final branch needs to constantly tested and fixed.
That's what Unity done wrong - created so many flavors of engine simultaneously that's impossible to manage with 1000 engineers. It requires now LTS and entire year focused on stabilizing the engine.

 

But isn't that what Unity are doing now with so many packages* just with one editor housing all that complexity?

*Arguably they are dealing with a much higher complexity than the 14 versions which only has 8 bits of complexity (2D, 3D, Tiny, SRP, HDRP, URP, DOTS, MONO).

What about 14 project templates then, pre-configured to work out of the box?

Maybe with a couple of essential system options e.g. input, physics 2D/3D, animation, particle.

 

That would be suicidal.

No, there's a difference with a "package that runs on top of the engine" and "a different engine".

 

How would that solve the confusion? People are still making the exact same choice.

 

Arguably "14 dedicated engine builds" with 8 main components might be less complex than one engine with over 60 packages/components.

It's aligning their project with a works out of the box version of Unity dedicated to that style of game.

Or what about just 4 versions of Unity:

1. Tiny 2D
2. Tiny 3D
3. 2D
4. 3D

Each version aligned to a specific rendering target and games that require that renderer?

It's just the classic divide and conquer strategy, maybe it's time for Unity to realise it's trying to do too much and is becoming too complex.

For example early Unity Tiny 2D made great progress even though it adopted a new scripting language and built it's own ECS subsystem. Then when Tiny was re-rolled back into C# DOTS it went 3D and lost the progress it had made in 2D.

Is the growing complexity of Unity holding back it's development, with the shifting core of DOTS/Burst we are seeing lots of packages that only work with this and that version of Unity or other packages.

With dedicated versions of Unity packages would only be added/updated once they are fully integrated to that build. Also some branches of Unity could have their own dedicated packages without needing to make a generic package for all other versions.

For instance 2D games might only need mathernatics2D.

 

That's why the unity hub offers you a bunch of presets when creating a new project.

 

This is worse, actually.

The person downloading Unity for the first time now has to decide which of these they want, without having had experience with them (as opposed to adding packages as they learn).

You're making the barrier to entry higher.

 

14 engine builds is worse. Also, with "14 builds" to switch from 2d to 3d, for example, you'd need to reinstall the engine, or install second copy in parallel.

As I wrote before, the whole thing resembles "monolithic vs microkernel" debate, but, at very least in case of packages you will have bug reports directed in corresponding part of the framework, while in case of 14 builds you'll have 14 different products (instead of one), where each will likely have its own branch, and all of them will feed data into the original 60 components.

Basically, there should be ONE version of unity. The version can have optional components, acting like plugins.

But, when you try to make 14 dedicated builds, you're trying to recreate Linux approach at dominating desktop market where linux was very successful (/sarcasm). There are 500 actively developed linux distributions. And some of them have multiple build configurations.

It is just an unmanageable mess.
--------

Basically, in my opinion.

1. Good: One build, everything and kitchen sink included. (less hassle, might take more disk space)
2. Manageable: One build, multiple optional components which can be downloaded from the environment. (you can customize it, and only keep things you need)
3. Bad: Multiple slightly different configurations that differ in small detail, and discovering this detail would require investigation. (wastes user's time).

 

That would be the worst possible idea. Some users are already confused by the options. Making new users decide between 14 different "engines" would be overwhelming for those users. The only manageable solution is to have one engine and a bunch of package options. Unity already has different templates to let users select when creating a new project.

All Unity really needs to do is be more transparent about the actual state of each package, so each game developer can make the best choices about the packages for their game projects. For example, DOTS is awesome but is not going to completely replace the old school game object workflow anytime soon. DOTS will not be an effective replacement until DOTS makes game design easier instead of harder, and it may take quite a few years to develop enough tools for DOTS to really pull that off. On the other hand, URP actually can (and probably should) completely replace the built-in legacy rendering pipeline sometime soon. The latest version of URP available for Unity 2019.4 (LTS) actually does make things easier for game developers than the built-in legacy pipeline. This true even on edge cases like stacked cameras. URP is pretty solid now.

 

Probably my main gripe with URP right now is that its still not really that well documented in terms of how to get a minimal shader up and running yourself via code, and where certain old macros or ways of doing things exist. I think once I work that out it will be as good or better than built in.

Everytime I try to write one by hand the template or way of doing it has changed, and I always struggle to find where certain old macros etc now reside (or if they even still exist).

I also really disagree with the fact that there is still no plans for surface shaders within URP, which would be fine except unity themselves explained in the first place the need for surface shaders when they built them, and now a lot of the community has built workflows that rely on or are impossible without them..

 

1. 2D + Tiny + DOTS 2019.LTS
2. 2D + Tiny + DOTS 2020.1
   
3. 2D + Tiny + DOTS 2020.2
   
4. 3D + Tiny + DOTS 2019.LTS
5. 3D + Tiny + DOTS 2020.1
   
6. 3D + Tiny + DOTS 2020.2
   
7. 3D + HDRP + MONO 2019.LTS
8. 3D + HDRP + MONO 2020.1
   
9. 3D + HDRP + MONO 2020.2
   
10. 2D + URP + MONO 2019.LTS
11. 2D + URP + MONO 2020.1
    
12. 2D + URP + MONO 2020.2
    
13. 3D + URP + MONO 2019.LTS
    
14. 3D + URP + MONO 2020.1
    
15. 3D + URP + MONO 2020.2
    
16. 2D + SRP + MONO 2019.LTS
17. 2D + SRP + MONO 2020.1
    
18. 2D + SRP + MONO 2020.2
    
19. 3D + SRP + MONO 2019.LTS
    
20. 3D + SRP + MONO 2020.1
    
21. 3D + SRP + MONO 2020.2
    
22. 3D + HDRP + DOTS 2020.1
23. 3D + HDRP + DOTS 2020.2
    
24. 2D + URP + DOTS 2020.1
25. 2D + URP + DOTS 2020.2
    
26. 3D + URP + DOTS 2020.1
27. 3D + URP + DOTS 2020.2
    
28. 2D + SRP + DOTS 2020.1
29. 2D + SRP + DOTS 2020.2
    
30. 3D + SRP + DOTS 2020.1
31. 3D + SRP + DOTS 2020.2

Try something like this. Also Be careful, I removed a couple, because 2D + HDRP doesn't make too much sense.

But I think that's the point. They decided to not to support shaders by hand because they want to keep the freedom to change the actual API any time when the need arises. So they can optimize whenever it is needed.
You won't notice it if you use the shader graph.
I completely understand Jason (Booth) that it is annoying for Store Publishers, but on the other side of the coin is this freedom of the ever changing/changeable API. IDK which one is better to be honest.

 

Exactly my point, I would need an AI to help me work out which combo would be best for me and my game...

 

No.
You know your requirements. You can decide. But Unity would need to separately maintain all of these. They have three release-lines currently, which means three sign-off procedures, three head test-runs. What you're suggesting does not make your life easier, because you still need to choose, but if you choose wrong, you need to uninstall and install a new software (meanwhile right now it's just the versions, if you choose the wrong SRP/built in, you just need a couple of packages - or not). But Unity's load of bureaucracy and procedures would suffer a lot.

BTW, deciding what you do and what you use is part of the development. Any game designer, who does not like or want to make hard decisions is a very (I mean VERY) crappy game designer. (If you keep one thing as a takeaway from this post, this should be it)
Any experienced software developer does the same.

And choosing proper version and proper tools is not rocket science. If you have a lot of time you can test things out and find out which tool is the best for your requirements.
If you don't have time, forget everything and go with the tool you know the most and probably will be able to support your needs.

It is simple as that.

 

I'm going to say we already have that, it's the yearly tech versioning and package versioning

@Martin_H Yeah they closed the thread, unfortunately I wanted to say I'm using 2d mostly as a visualization to prototype algorithm, I give up on making 2d game for 3d, because I prefer 3d, sorry

 

Yes but graphs are not > hand writing, they are just another way of doing it. Its not a choice that should be made for my team, not when it is something that is actually supportable and has been in workflows for teams using unity commercially in games and for enterprise use for years. We should make that decision ourselves.

I get what your saying but I just cant get behind the choice, its a serious issue on some projects. Not everything is doable in shadergraph, or even in a graph at all. Some things get incredibly hard to manage at a graph level, due to complexity and size.

 

I get that, and I won't pretend I know anything about shader programming, because I really don't. I even need to look up every single time how to apply vertex colors. So there is that.
And I hope when SRPs finally arrive to a state where they're ready to replace the built-in for real they will revisit this decision and make documentation available and open up the API more (and restrict the number of changes of course).

 

Is one of the reasons that Unity is becoming so complex is that it has adopted a more low level approach to game development?

Now we have a vast array of quite low level API's divided into packages. Where in the past a lot of the lower level stuff was black box and under the hood of the Unity game engine built in whether we used it or not.

To address this balance of complexity could Unity introduce some mid level packages that just combine lower level packages into modules and they could also provide higher level features.

The theory being that by consolidating packages into higher level API's you massively reduce the initial complexity to the developer and get the added option to provide them with helpful features they would otherwise spend valuable development time working on.

This is very apparent in the DOTS areas of Unity and maybe a lot of potential developers could be put off by it's complexity and low level nature as well as the low level nature of it's packages.

 

You don't have those concerns? Well good for you. But I and many others do have those concerns. That's why there are so many complaints about Unity right now and it's clear that for many people it IS a problem.

Also you're kind of contradicting yourself here. Right now we have multiple specialized choices because of the "old baggage", which you'd rather they replace. Like Old Input System vs New.
The reason the decisions are confusing is because the future of the old baggage isn't clear. It isn't clear if something is intended to be a replacement or an additional choice--keeping the old feature implies that it's a choice while replacing it (so there's only one option) leads to a unified system, which you say isn't necessarily better.

I don't mind having multiple choices. That's not the confusing part, I know which ones meet my needs. The confusing part is that its not clear if the "old baggage" is going to be cleared out or if they will continue to remain choices. I can't make clear decisions without knowing that, hence it's confusing.

That wasn't the context of the question. I've been using Unity for over a decade, I'm well aware of what the documentation says about Resources.

The question was in the context of Unity's current approach to development and the concern about the possible removal of old but still good features, making planning and budgeting difficult. Meaning, am I making a mistake because Unity is going to remove this old feature at some point, despite there being good reasons for sticking with the old one in some cases.

This is precisely what I'm talking about. It IS confusing. Not necessarily just in terms of "this one has feature X, this one has feature Y, oh no I can't decide!".
But in terms of "this new one is the "way of the future" and the old one might get removed (but we're not sure), but the new one lacks feature parity."

Heck, you're saying use the new one even though by your own admission it lacks feature parity, would have added "unnecessary complexity", and the devs think it's a non issue. This is a dealbreaker for some people, they might want to stick to the old one. The only reason they'd hesitate is because they don't know if they'd be building infrastructure on something that's going to be removed in a couple updates.

 

If they need old features to be there, LTS versions exist. Feature removal only happens in tech branch releases of Unity.

 

Some games are in development for more than 3 years and get post launch support for a couple more years. The LTS lifecycle really isn't long enough to make that an answer that would take the anxiety out of looming feature-deprecation.

 

That is fair, but there are potential solutions for that.

Feature deprecations are not feature removals, though, as it is just a signal to deter new code from using it. I don't think people should worry about that when maintaining older projects unless the feature is clearly removed. The pre-Shuriken particle system, for example, still works in 2017.4 after its deprecation in 5.4 -- that's almost 4 years of transition time.

 

BTW, Unity is still worth using just for having C#. .NET Framework offers one of the best foundation to write code on.
I have not seen a lot of people mention, but after Unity upgrades the .NET runtime, people can use any packages from NuGet that has a .NET Standard 2.0 DLL, and there are a lot. No AOT bs with IL2CPP or iOS.

Also, other developer environments have package managers and way more packages than Unity's, and complexity is never an issue for them. Unity already does a pretty good job keeping their package description in simple words, so you know if you need the package when you read it.
I also just notice that they allow disabling built-in packages, which is great because I would never use JsonUtility in my project -- Json.NET for the win.

 

No, that's not the "baggage" I'm talking about.

The baggage I'm talking about is stuff like heavily relying on magic method names to hook stuff into engine events, and the lack of namespacing in Unity's early days making it harder to move some things forward now, and so much stuff relying on Resources that removing it is a major hurdle.

That last one isn't even a technical hurdle. It's an ecosystem one.

What's confusing about this, from the document you linked?


Why does it matter when they remove it? They're abundantly clear about the fact that we shouldn't be using it anyway. And for the few use cases where they say it's ok to use you can make your own, better solution trivially easily.

 

With Unity going lower level with it's APIs, Packages and DOTS is this the new Unity developers mantra?



Unity provide us with a low level game engine kit and we have to assemble the bits and build our own bits or buy bits to make it into a work system?

 

Apparently you don't know the difference between the "can" and the "have to"...

Okay, seriously, why is it a big physical pain for you that Unity is finally trying to provide lower level APIs? You don't have to use any of it, so why? Are you seriously jealous of others, who can and willing to?

 

The high level api is still there, people are making game per hour challenge now ...

 

I hope you people, who is incapable of basic decisions will be happy now, you successfully screwed up for everyone.
https://forum.unity.com/threads/visibility-changes-for-preview-packages-in-2020-1.910880/

Yes, I'm seriously pissed off by this decision. Unbelievable.

ps (edit): and don't get me wrong I blame Unity too. It is time to take the users seriously and treat us like adults who are responsible for our decisions, otherwise Unity will never ever will be a serious engine.

 

One of the major downsides of democratizing is that you attract people who are not capable of making rational decisions and must have them made for them. It's why we're constantly having to help people with very basic problems including an inability to find the correct subforum.

 

That's a separate issue, and for me it is a labor of love. I really like to help people, because I'm always trying to help on a way which brings them a little bit closer to become a better developer. That's why I refuse to write classes for people with very few exceptions (and those usually show some interest beforehand so they probably will investigate the example, not just throw in their project).
I don't mind helping beginners or confused people, but making my life complicated so some people aren't whining that much about how many options they have... this is very low.

And of course I understand Unity's economic decision, they simply don't give a crap, the important is the PR and that as many people "happy" as possible.

 

Who said anything about the document being confusing? I'm well aware of what it says, that's why I linked it. If you choose to focus on that one sentence while leaving out the rest or even the next sentence, that's on you.

Key word: it's a recommendation. I know what the reasons are. They're not applicable to my use case. I've tested it myself.

If Unity doesn't want us using Resources EVER (which is not what it says), they can remove it. In the meantime, I will continue to use it however I want and you have no business telling me otherwise. Whether or not I can make my own "better solution, trivially easily" is completely irrelevant.

And it matters when/if they remove features because some of us are in the business of making and finishing games and games can take a long time to make. We have to be able to plan and budget accordingly. My own BHB: BioHazard Bot was in development for 5 years. It started back in Unity 3.5. Here's some gameplay footage from the Steam store page.

So yeah buddy, the timing of when and if features are going to get removed matters a lot.

 

They are clear they want us to not use it, but they aren't clear on why and more importantly, they haven't produced an alternative equivalent (addressables isn't really a replacement).

As far as I understand it, the bad thing about the resources folder is that it creates an index, that has to be loaded on launch and then stays in memory. Which.... uhhh. Big whoop?

 

I think there's a miscommunication here. I'm not telling you what to do. I'm sharing how my perception is different to yours and why I don't think this stuff is "confusing". What you do is up to you, and shouldn't be based on what I might think in any case.

I know I ambiguously used the word "you" in reference to avoiding use of Resources by making an alternative, but that was a general "you" referring to everyone, rather than you personally as an individual. I apologise for my sloppy use of language.

But they can't. See "baggage".

How many Asset Store solutions would be immediately busted if Unity removed Resources? And personally I think that's a bit unforgivable on Unity's behalf. It's not as if this is a new thing that's cropped up. It's been clearly visible for years - Unity were talking openly about it at Unite in 2015 - and as long as there's no solution it'll continue to get worse as the ecosystem's dependency on Resources carries on.

Imagine that Unity updates Addressables tomorrow so that it is a functional equivalent to Resources and is included by default in projects, and deprecates Resources. How long would it take for everyone on the Asset Store to swap over to using it instead? And it probably can't be user transparent in all cases, which is its own bundle of fun for everyone.

The first step here really has to be getting an equivalent in place. Which is the main reason that Addressables not being equivalent annoys me so much. Why put in all that effort and not solve the actual problem?

Aye, I've been there too. Again, see "baggage". From my perspective Unity do a reasonably good job managing this most of the time. The remainder of the time is painful, though.

Personally I approach that stuff the same way I do any other risk. I don't know when or if it's going to change, but if it's at high risk I'll either design so I can react with minimal effort, or I'll avoid it in the first place. That doesn't remove all of the pain, but it helps a heck of a lot.

For what it's worth I don't do that specifically for Unity, and if I were working directly with target platforms I'd expect to need to do a lot more of it.

Again, to clarify, that's my approach. I'm not telling you what decisions to make.

Indeed, for many games I agree that's not a big deal. That said, I never thought it was a robustly designed system in the first place. Back when Unity was new it was a "good enough" system, but it really needed iterations in the meantime to keep it that way. Issues I have with it include:
- Lack of centralised, clear control over what is and isn't included in your build, because they opted for magic folder names instead.
- The potential for name conflicts as a result of the above. Two files with the same name in different Resources folders? Ick.
- Increased build time because the whole thing gets re-built every time. Maybe they did fix this one at some point?
- No splitting the bundle / grouping stuff together.
- The bundle can't be separated from the build (as far as I know?). Along with non-deterministic builds that makes updates to games more painful than they need to be.
- Asset Store packages coming with stuff in Resources foldrers for use by the Editor or in examples and so on. In other words it's not intended for builds in the first place, but can easily end up in them anyway. (This, and assets using Resources for runtime stuff as well, is a major piece of baggage that's not even fully in Unity's control, which is a part of why it's so hard for them to move away from it.)

Basically, it's a system that's designed to be easily accessible, rather than to scale and adapt to the needs of larger and/or varied projects.

 

All the problems with the Resources system you listed could be fixed with internal changes and both API and UX additions. The API surface exposed to developers is so small, that the entire backend could be replaced by something better with minimal breakage. They could fix the determinism issues. They could fix the stupid indexing at boot time. They could fix the useless rebuilding everythingoon every build. They could have added UX for managing and auditing resource packing.

Instead, Unity decided to built a new house on top of the old one. Asset bundles actually share a lot of backend with Resources. The serialization process is pretty much the same. Building and loading the "indices" was made manual, but since bundles are still resources deep down, fundamental flaws remain, like the terrible lack of deterministic asset serialization.

Years later, Unity builds yet another house on top of the previous one: Addressables are primarily a way to manage the assignment, building, and loading of asset bundles. Someone will inevitably come to argue that bundles are just one of the "providers" and Addressables are more than that, but that's irrelevant because the only way to load serialized Unity assets is using bundles, which are resource files packed separately.

 

Definitely. Personally I was hoping that that's what Addressables would be. But it doesn't quite get there.

Thinking aloud here, I suspect they could write a bit of code which by default sets everyting in a "Resources" folder as being added to an Addressables package, and internally change the Resources load methods to get stuff from there instead. Two things prevent that. First, there's only async loading. Second, it relies on having the Addressables package in the project.

 

I don't disagree with your points, but : Not being robust describes many Unity systems, I don't really get why they picked the Resources folder to be the one they flat out say "don't use it".

To put it another way: Collaborate is the most problematic and least robust thing ever, and instead of "don't use it" they're asking for money.

 

What if what we are seeing in the mounting complexity and issues with Unity are just symptoms of a deeper set of problems with Unity the company?

Often as companies grow, age and change, the initial groups of geeks or techies who started it up start getting displaced by the suits and businessmen who are more focused on money. Combined with employee population growth and a small tight knit group with good communication can grow to become a departmental/segmented political complex hierarchy.

Has Unity passed some threshold of complexity not just within the engine but also as a company and the two combined we see as a Devolving game Engine*?

If this is the case then maybe dividing up the Unity game engine could also allow the company to divide and conquer it's own complexity?

*It's just a phase I'm using to represent rising complexity and instability lower functionality and higher barriers to learning and mastery.

 

I think your mistake is thinking Unity know much at all about using their own product

 

I was being more than a little polite in my choice of words.

 

Here's the sequence of events that hopefully expands on my frustrations with Unity and the confusion they're causing. There's more I'm leaving out but these are some of the main ones.

• Unity introduces Shuriken, old PS component gets marked legacy
• I spend a bunch of time switching to Shuriken even though I don't need the new features
• Old PS is phased out and eventually removed--switching was the right choice.
• Unity introduces Mecanim, old Animation component gets marked legacy
• I spend a bunch of time switching to Mecanim even though I don't need the new features
• Unity introduces Post Processing Stack, old shaders get phased out
• I spend a bunch of time switching to PPS
• Unity introduces Addressables, say it's meant to replace Asset Bundles and Resources. But they're not marked Legacy and Addressables doesn't have full feature parity.
• Unity now recommends Animation component in some cases and no longer shows it as legacy in editor. So much for getting phased out.
• Unity removes Display Resolution Dialogue without warning despite costing them virtually nothing to leave it in and not offering a replacement.
• URP is supposed to be the way forward, yet still has tons of issues that Unity hasn't addressed, similar to Mecanim's performance problems compared to Built-in
• etc.

Stuff like this is why it feels like the future of all these new features are in flux and we can't plan around it. I could have finished BHB: BioHazard Bot using the original Animation component and it would have been perfectly fine, apparently. But I switched because I was essentially told it was going to be phased out just like the old particle system was. But now Unity recommends Animation component in some cases because it still performs better than Mecanim! I did all that work (literally months) for nothing when I could have just stuck with the legacy system.

So when we talk about Resources folder vs Addressables, or Old Input System vs New, or Shuriken vs VFX graph, or URP vs Built-in, or any of the others, how do we know what type of situation it's going to be?
Is it going to be like old Particle System and Display Resolution Dialogue where it gets removed? Or is it going to be like old Animation component where it stays and Unity maybe changes their mind later about it being legacy and they still recommend it in some cases?

In the Animation vs Animator thread, user @Baste says this:

This is precisely my situation too, except now expand that towards all these other new features that Unity is introducing to "replace" the old ones, but not really replace it, but maybe replace it, but who knows.

In some cases I want to use the new features. In some cases I want to use the old ones. But Unity is so vague and flip flopping and changing their mind and inconsistent between what the documentation says and what the official blog posts say and what the editor says that in many cases I'm unsure about which ones are safe to actually use.

There was no official blog post that said Display Resolution Dialogue would be removed. The documentation says Addressables is now the recommended way but Resources is also not labeled legacy. But the documentation says don't use Resources, and it says the same thing about Animation component. But then there's Unite presentations by Unity employees saying "Right now you should not be afraid of using the Animation component".
@AcidArrow posted this:




So which one is it

And then what about Display Resolution Dialogue and Particle System? I guess we should have been afraid to use those?
What about Resources, should we ignore the documentation's warning to not use it, just like we're apparently supposed to ignore the Animation component warning?

 

just want to contribute something here... although it has been a couple years since i have even touched Unity, and I have my personal beefs with it and the modularization/subscription things/ asset store et al... The developers and the support team has always been top notch and very responsive to actual problems via the forums.

That alone is noteworthy IMO.

 

Just my $0.02. I usually think game first, engine second.
So my only focus is to make the game work. Only if the engine has changes that stop my work I'll handle them. I'll pause the updates of the game and stick to the last working version of the engine till I can work on a partial rewrite. I try to work only on stuff that players see. E.g. if I replace all Animations in Mecanim, if I really don't have a sure improvement that can improve 10x or that user can see then I skip.
I think that if you have a really long development cycle and plan to support a game for years if you try to run along the engine changes you'll miss your most important goal: players.

 

Do you have any anti-virus? If so, have you tried removing it see if Unity behaves more stable?
I did it and my crashes got reduced to 1 - 2 a day.

 

Trees... Unity's poor performance at rendering large numbers of Trees. Something the engine has suffered from for a lot of years and has yet to be addressed.

Large terrain < 10 fps on mid level PC but with only low CPU/GPU usage so not limited by hardware https://forum.unity.com/threads/low-terrain-tree-fps-but-wierdly-low-cpu-and-low-gpu-usage.930963/

Maybe I should have made a Unity TreeMark benchmarking app... maybe I should make a new one?

PS It's 2020 and still no sign of large terrain support (to my knowledge?).

 

100% agree, they need to just full stop making any new features and polish and make easier to use the old ones.

 

I hit that a month ago. I was going to investigate if culling groups would help (or even work for painted on trees), but I ended up just removing the trees for now.

It sort of agree, but it isn't that simple, as developers on something like a game engine often have very specific skill sets. Where you can't just move them around to different features and expect extremely high quality work for at least half a year out of them.

 

As usual if you're waiting for Unity to address this issue you will be waiting forever. Don't look for them to fix it. They won't. It will never happen.

The way to render trees is not through the terrain system. You need to take your tree prefab, use Amplify Imposters (from the asset store) to create a rotatable billboard of that prefab, setup a new prefab with an LODGroup with LOD0 using the original tree for only very very closeup rendering and a second LOD1 for the billboard to render out into the distance. Then let GPUInstancer (also from the Asset Store) handle all the tree rendering for your terrain on the GPU. It's incredibly fast, looks dope, and you can throw nearly as many trees at it as you want. Using this method I'm rendering multiple hundreds of thousands of trees across many terrains (along with other foliage, grass, plants etc), all at 60+ fps in the editor (even faster in a build). Similar setup can be used for most game objects, but it really shines with foliage.



Stock Unity will never be able to match this feature/performance. It's simply too specific a task for Unity to be interested in or to put development time toward (despite being something thousands of game developers could use!!). After 12 years of banging my head against the Unity wall of hearing constant promises (SpeedTree? LOL!) and being let down over and over again I've stopped listening to anything they say, and now focus on getting my issues addressed elsewhere or by myself. Asset Store can be a crap-shoot sometimes, but GPUInstancer is solid gold.

I didn't want to hijack this thread for this one issue, but also didn't want you to rage about this tree problem without knowing there is a solution.

 

Yeah I've seen that suggested, but how do you actually place the trees using that method?