What happened to Unity?

So after a bit of a hiatus on Unity to work on some 3D projects I have come back to...I don't know what to call it.

In the first half-hour of using Unity 2020.1 I have had issues with getting packages I own from the package manager as it said I was offline, even though I could click on the asset store link fine...only for it to magically work for no reason after restarting the engine maybe 3 times over the course of a day. [NB : This can be maybe fixed by turning off VPN if you have it]

Loading up a package into the URP to find all the textures broken, and changing a shader BREAKS the textures cos you couldn't even keep to a naming standard? So that's going to take ages to fix as it's not my assets and I have to match up all the texture names manually...unless there's some magic way to do that I don't know about. I have a feeling I'm going to get sick of seeing that pink shader if I decide to continue using Unity.

I'm interested in using multiplayer for my next project....but that's in no man's land by the looks of it. Releasing a whole engine without a basic networking tool inbuilt is...kind of dumb with how games are going nowadays. [NB : Photon looks promising, I've heard Mirror might be good]

The whole URP, HRP, standard pipeline is a MESS. You've fractured the whole process into three different engines basically. So any assets from past builds are a gamble. And will require a lot more work than needed. [NB : Just use the SRP if you can. That's what I'm sticking with but who knows how long that will stick around for]

I haven't even got into the deeper side of things. Personally I'm wondering if I'll even bother.

I have been talking to a friend who is much more invested in the engine and has been using it for 10+ years. And I don't think he's said one good thing about it yet. Not one.

The tutorials are also basically void in many cases due to the fracture over the last year or two...so finding things that apply to the latest engine/s, depending on which version you use, is...also not very good.

For an engine that prided itself on being good for indies and making things quick to set up and prototype you have dropped SO MANY BALLS AT ONCE. Basically every step so far has been fighting the engine.And I haven't even got into the programming side of things.

So rather than having to RElearn Unity basically from scratch, I'll probably be looking elsewhere. Which is a pity. I DID like it. But personally I can't trust anything in the engine anymore basically if it can't even get some basic name conventions down.

I'd hate to be someone coming to the engine for the first time. They stand no chance.

 

2019.4 LTS is working great for me. I just ignore all the newfangled stuff like DOTS until it's good and ready, which is probably another 3-5 years. All of the tried-and-true "classic" Unity still works great. It's true that multiplayer is in limbo now, but better for them to pull the plug on a system they'll no longer support than have people starting with it. There are alternatives.

Good luck with whatever engine you choose.

 

personally 2017.4 seems like best release so far, 2018.3 not too bad either,
anything later keeps getting slower and slower (on a high end desktop with latest gpu's)

 

My experience was that 2017.x was the slowest with editor load times. When I read a few comments on the forums that suggested that 2019.x was noticeably better on editor performance, I decided to give it a try and I too have noticed the improved editor load times.

 

Good luck with that. I don't know your history with other engines but be prepared to discover that (a) Unity's naming is nowhere near the worst, and (b) Unity's backwards compatibility is far more extensive too. Unreal is a fantastic example.

Unity has GameObjects. Unreal has Actors, Pawns, Characters, and Controllers. Actors are basically their GameObjects but they're not capable of performing every task like a GameObject. Pawns are Actors capable of being controlled by the player or AI. Characters are Pawns with additional functionality like skeletal mesh support.

Finally backwards compatibility. Unreal 3 is around the point when I started paying attention to engines and I know the migration from 3 to 4 involved learning just about everything from scratch because aside from the terms used everything was rewritten. Unreal 5 is supposed to not be a rewrite but I'm not holding my breath for it being easy to transition.

Remember the other side may look greener but it isn't necessarily green or even grass and that's assuming it's even alive.

 

Are you saying its the engine's fault that a third party package didnt stick to a naming convention? Or that its the engine's fault that it doesnt mandate a texture naming convention?

 

It seems that the shaders diffuse texture name between URP and standard are different, so when changing the shader the texture gets dropped (normal map was the same, so that stayed for example). So, it's all in Unity from what I can tell as they are both 'unity' shaders. Luckily, in my case, the number of textures was small in number, so didn't take too long to correct...but it's such a small thing to get 'wrong' that can have such a large impact on the process especially for a larger project or larger asset from the store. This makes me worry about half the other simple decisions they are making between pipelines...I can't even imagine what they are doing deeper in the engine.

I agree that every engine has its issues for sure. I have started using Unreal lately and find it has its own quirks. But I find that it falls under 'different' rather than 'this makes no sense', which I seem to be coming up against a lot in Unity.

Another thing today was you can't edit animations by using gizmos in the animation editor from a humanoid gameobject. From what I can tell. You have to do it numerically, if I have it correct?

The idea of going back to an earlier build could work...it's a good idea tbh. It's just ridiculous that that is the option here that is most workable.

 

I don't understand the deal with the textures. what does the name matter? that is going to be different for every user/team.

Are you saying that when converting materials from SRP to URP the connection gets broken because it requires a specific naming criteria?

 

If a feature was working in a previous build have you checked to verify that it was an intended change and not just a bug?

 

If a team is working on their OWN shaders, sure. But if it's the UNITY shaders, that most people use I would say (?), then it's...to be honest it's a tiny thing. But because it's so tiny, and they made that mistake...My faith in the new 'pipelines' is significantly dropped. Most users do not edit the shader naming specifics. Especially the first texture that you learn about when making materials eg. Diffuse.

The 'label' of the diffuse texture in a material using the standard unity shader is 'Albedo'. In the URP it is 'Base Color'. Because they are different all the connections break if you have a project (or an asset from the store) go from one to the other. So, from what I can tell, you would have to manually go through all the materials and change the diffuse texture. Of course I could go into the shader itself and rename it. But that's not the point here, it's trust in a company having reasonable quality control. Note this isn't the ONLY issue I've had with the new pipeline/build...it's just a really simple mistake.

As noted, this wasn't a big issue for a small project like mine, but if I had 100's or 1000's of textures on a project or an asset I bought...that would be a nightmare. Luckily it's just the diffuse. Normal worked OK as that had the same label. I didn't use any others though so can't say for all of them.

I have a feeling the new pink shader is going to be the new red wax shader joke from ZBrush. Everyone is going to get really sick of seeing it.

My last ditch effort on this project is going back to 2019.4.5 and using the standard render pipeline. From what I can tell that will have a higher chance of any assets from the store working, and tutorials online still being more accurate.

 

Warning: I'm describing the situation from position of pre-URP pipeline.

Materials - standard materials, at least pre-URP - store material parameters as names. You can see those names by switching to debug inspector view in the editor.

For example, Albedo is actually _MainTex, specular map is _SpecGlossMap, metallic is _MetallicGlossMap, normalmap is _Bumpmap, and so on. You can also see the names by opening material in a text editor/viewer.

When you switch shaders, the datablock does not change. So if your old shader used _MainTex, and the new one expects _Diffuse, the old _MainTex will not show up in inspector, and the shader will use a blank texture until you re-configure it again.

Another very fun part is that standard (pre-urp) material does a LOT of configuration by setting hidden keywords. Possible keyboards are _NORMALMAP, _DETAILMULX2, _ALPHABLEND_ON, _EMISSION and so on.
Those are actually set by the custom shader editor in the inspector, and not by the user, and messing those up will make the shader fail to function properly, at least as long as it is using standard material.

The naming scheme of standard shaders is actually quite messy, and supporting it is fairly unpleasant endeavor.

 

We stay away from assets that have too many custom shaders for this very reason. Get ugly to maintain pretty fast.

 

I did note that the _Maintex is the thing...not the Albedo/Base color...so maybe THAT is different in the URP in comparison to the SRP.

This wouldn't be an issue if it was from two different vendors. As I agree, different studios/developers have their own thing. But when the default shader/material for the SRP is (partially) incompatible with the default shader/material for 'other' pipelines (I haven't checked the HDRP so can't say) from the SAME company...especially the ENGINE developer...it's a little frustrating.

But as noted, this is just one of many issues...but it stands out as it's just such a small thing to trip up on.

As it stands, using 2019.4.5 with standard render pipeline seems ...functional so far. But it also means, in MY mind, the URP and HDRP is a complete waste of time and I won't be looking at upgrading until...well I probably won't.. All the assets I've bought on the asset store will need to be converted by hand unless the original developer makes a version for URP/HDRP/SRP...perhaps. So I'll stick it out at that and see how that goes.

 

I do not understand why unity has to use 2 different render pipelines, and re creating the material stuff. We should stick to the legancy renderer for a longer time I think (at least until it will be get marked as deprecated). Currently these render pipeline stuff could be good for a new project, but even then, there could be a lot of big changes and the fear is there that material definations etc. (like mentioned above) will be changed again...

Let's hope for the best.

 

The built-in has strangely exaggerated fresnel effects (get side on to any slightly shiny material and it becomes really bright).
Is that better in new pipelines?

But to OP you can use everything as it was for now, new stuff varies in quality and readiness!

 

Yup, and thats what I'm doing (2019.4.5 with SRP) but already find a ridiculous amount of Deprecated and soon to be obsolete. SO that's always fun knowing that I am at the whims of Unity's continued support (or not)

So that's the key word...'for now'.

Don't even get me started on today's three hours spent trying to get a button press from the XR motion controller input. the old system will be deprecated, the new system...doesn't seem to have XR functionality yet? Or if it does it's poorly documented. I did manage to find how the keyboard and gamepad work easy enough as a last resort...so I am forced to use them for now. But a button press? a BUTTON PRESS!!! At this point, I'm just using this as a venting thread trying to figure out why everything is just so damn hard with Unity now!

Does anyone know if there is a better thread to post these issues with, these don't feel like unique issues anymore? It feels like the whole 'structure' of Unity is just...unstable, broken, half-finished, half made... or is it just me. And everyone thinks it's business as usual? I realize one build to the next will ALWAYS have issues, but the level of...scatteredness...seems excessive for this transition.

Surely Unity realizes how much they've dropped the ball on the transition from 2019 to 2020?

 

Once again though this is not unique to Unity. You will always be at the mercy of the game engine developer's continued support for a feature. Like I mentioned in my first post Unreal 3 to Unreal 4 was a complete rewrite with everything being abandoned. Instead of just learning a new pipeline you'd be learning everything from the beginning.

To be blunt if your worry is having to learn a new feature set after the current one has been abandoned my only real thought aside from building your own game engine or sticking to an older release for each project is that maybe you chose the wrong field to pursue. Because this is very much par for the course in programming let alone game development.

We have a thread once every few weeks where a few people are having major problems, but just about everyone else on the forum doesn't seem to have them at all. I'm inclined to believe it's a very specific combination of hardware, software, and the way they're using the engine that is causing the problems.

Because if it were truly widespread and not merely a very specific combination we would be having many threads about this on a regular basis and not one small thread every few weeks. We've actually had more threads about the dark theme over the past few years than we've had about the engine being broken.

 

@Ryiah I get your point, I really do...And I agree this is par for the course. But, in my opinion, I've never seen anything as messy as the transition from 2019 to 2020 in all of the programs I have used. And as much as game engines are a different beast, Unity's approach has been...less than organised.

Personally they should have just gone with 2019 as the last 'old' system. And then start with Unity 2.020. Rather than basically build the whole engine from the ground up, INSIDE their own engine, in pieces. At least then the expectation, the ability to find tutorials, and the assets that can be purchased, would all be at least somewhat uniform across the board. I understand they made a choice and ran with it, but...yeah.

And you're right. Maybe game dev isn't my calling. And in the last two weeks, in comparison to the several years of dabbling in it so far, I have definitely started considering that fact...but in all the years as a hobbyist developer previously, with all the issues I HAVE had with development (And there have been a lot).....I have not considered that. I managed to power through because it 'made sense' that something wasn't working and it was probably me. But now there's a 40/20/10/5/etc/etc/ chance that it's me/the engine/the package/incompatibility/the tutorials are on the wrong one/the render pipeline doesn't like it/that feature 'isn't finished yet' even though it's labeled 1.0 (which they mentioned was an error but still...versioning MATTERS)...just as some examples.

I'm willing to learn from scratch, but the current project is a time based one that needs a prototype quickly. So I was hoping to go back to 'what I knew' to create something 'quickly'. And because VR has changed so much since last time I used it...all the things are different...and that's fine, I'm cool with that. I am not a coder, but in the past I could at least get a button press pretty easily. And that's what I'm comparing Unity to, itself.

I've wasted a day trying to get a motion controller button press to function properly because I figured it shouldn't be THAT hard surely! And that's what I've faced for every thing I've wanted to do. At least 3-4 hours trying to find what the 'current' method of doing anything is, and when I find it...it's half baked.

And that's my end rant on all that tbh. It's not like anything is going to change from this...I was just seeing if other people are as frustrated as I am. Especially less advanced users who are trying to figure this out for the first time.

Or perhaps if someone could point me to the right 'combo' for stable development with older purchased assets etc. as a VR project? Maybe 2020.1 with the SRP, XR integration toolkit and legacy input system perhaps?
Would that work better than my current 2019.4.5 with SRP, XR integration package and input.System 1.0?

Thanks for listening though! Good luck with your projects. I assume you are having better luck than me

 

Is there a reason you're trying to use 2020.1? The XR integration toolkit works with Unity 2019.3, the first stable release of the new input system supports Unity 2019.3 (I'm the one responsible for getting it working for my company so I know first hand that it's stable if a bit of a pain to learn at that release), and both of the SRPs are stable with 2019.3.

My experience with mixed reality headsets is limited solely to an Oculus Rift (non-S model). I want to say that I heard about the XR integration toolkit and simply forgot that it existed, but it's very possible I was too busy at the time the blog post came out. Either way I will be checking it out sometime soon. I just need to set up my headset again as I built a new machine and it takes a while to do (my internet connection is slow and the sensors need to be calibrated).

 

At least there, there was a clear advantage to using Unreal 4 though. Things looked better, things performed better etc.

Unity often asks us to migrate to new things that have no obvious benefits (but they might have them in the very far future or something).

 

True. Unreal 3 was an awful experience for me. That said at the time of release Unreal 4 was missing a good number of features that had been in Unreal 3 for years. Volumetric lighting and fog was a major one. UE4 took two years to gain it.

 

Yeah, but...

UE4 got released 6 years ago and it was something different than today Unity upgrades.
Many engine core systems were revamped "at once".
- like a terrible UE3 asset system (where assets had to part of a bigger package, ending up with sending 500 MB every time a single asset has been changed) to a civilized UE4 system (every asset gets separate asset on disk).
- barely-useful Kismet upgraded into general-purpose visual scripting
- renderer refactored, we got deferred renderer and architecture better supporting different platforms
- skeletal animation, AI and UI systems integrated out of the box - UI itself utilized a brand new framework written for UE4
It was a totally new engine

Although many systems remained initially unchanged, i.e. material editor.

Remaining legacy systems got replaced by new systems gradually with a consecutive UE4 upgrade. New systems got a "production-ready" label only if got feature-parity and performance-parity with the older systems.
- UE3's Matinee it's still available in UE 4.25 (yes, 25 versions later) even though Sequencer it's 100x times better and usable for a long time
- Audio rendering - old system replaced by default just half a year ago, the audio team spent a lot of effort to make the old system working along to writing a new one from the scratch. Actually, there was no single audio renderer in UE3, every platform got a separate implementation. That's why it was very primitive and supporting it until UE 4.24 must have been a huge burden...
- Niagara is a brand new and amazing particle system, but UE3's Cascade is still here, all functional.

It's nowhere near the current Unity's way of doing things. Abandoning or even removing systems before providing a feature-parity replacement? It's a mess, sadly.
Actually they should schedule these new huge systems to be part of the next-gen Unity. They should work on their UE4-style upgrade

There was any volumetric not-baked or not-faked lightning in UE3?
I mean, I might not remember that. Done only a single game on UE3, with baked lights.

I remember we missed some things in an early version of UE4 while porting the UE4 game, i.e. Lightmass working with foliage properly. And artists had to recreate all the materials. Generally, it was working though...

 

I'd rather have an update every 1-3 weeks than look forward to everything being updated all at once at some point next year or whenever. And this or that is broken, sure, but you know that just means it's not done yet - there's always something else to spend time on meanwhile. And if a feature is more of a priority for me than Unity, that means I will just have to roll my own solution - at least for the time being. Without Unity I'd have to roll my own everything (speaking as a hobbyist), for how many platforms? And if you think maybe you should be using another engine.. well maybe you should (and I don't mean that derisively). This engine is free for probably 99% of the users, and has enough existing capabilities that do work either perfectly or well enough anyway to make a game for probably 99% of the users. Maybe come up with a different idea for a game if what you have in mind is just proving too difficult? You can always revisit the concept again later, with the benefit of all you will inevitably learn along the way while developing something more reasonable to develop with the tools you have chosen. If another tool is more suitable for something in particular then by all means make use of that instead. I'm not speaking to anyone in particular just rambling - I have a great time with Unity and if I can't work around something I just do something else. I do get there's another demographic here with more at stake than having a good time or not.. I don't mean to be insensitive, someone whose client or boss is like "okay so it's done tomorrow for sure right??" and you already had it done but there's some glitch you're at the mercy of other people to fix and nobody but another developer is going to understand because it's just broken and you're the only person they will hold responsible for that lol "the dog ate my homework" == "there's a problem with the engine"

 

This or that being almost everything at this point. Oh and also current features are deprecated.

I guess Unity is fine if you don't have to release a game, so you don't mind things being broken.

It's the perfect engine for tourist game developers who like to complain about other people taking things too seriously.

 

I was frustrated by Unity doing the URP/HDRP switch (why, oh why) but the automatic material upgrade is working very smooth by now and even most old assets load just fine. Custom shaders are always a gamble but I stay away from these mostly. Then the VR switch, ripping out build it in favor of a plugin concept. That was my biggest blocker, but ok, I took on the challenge and changed everything (to be honest, I needed to do this anyway, I was on VRTK 3 btw).

I am now on Unity 2020.1 and could easily upgrade to Unity 2020.2. I have no more technical roadblocks and can always profit from the latest advances.The editor is, at least for me, sooo much faster. Entering playmode takes not even a second. Asset import time is down from 16 hours to 4. The package manager is great and I am developing a great custom package with it for my players. Graphics performance is better than ever and I can now also switch to Vulkan once that stabilizes. GPU light-baking is incredible. Addressables are a blessing once you manage to understand the internals. Editor crashes, which I had constantly with 2019.3, are nearly gone completely.

Of course there are still many gaps, Visual Studio gets confused if you also use Visual Studio Code. Valve just gave up supporting Unity XR Input which is a mess. But I am actually positive again after being torn during the 2019.2 and 3 cycles. The engine starts to just work again, things do click together, the strategies start to converge. I would personally recommend Unity (2020.1+) again to everyone.

 

This effect is also more noticble in stereoscopic (VR) rendering. It has annoyed me for a long time

 

@Ryiah I started with 2020.1 and the universal pipeline, as I was aiming for lower end devices eventually...but found the URP to be...troublesome with asset store assets I wanted to use (as per part of the original post).

I think after that I started the project again with 2019.4.5 and SRP because that is what I knew in past projects and have had better luck with it so far. Until I hit the XR / input issues. Unfortunately Rewired doesn't really cater to VR stuff, and as a non-programmer the programming side of getting simple information such as 'A' button input (which hasn't really been an issue before) from the XR integration toolkit isn't great. And the new Input System seems to work great for gamepad and keyboard, but I haven't found the equivalent for XR yet (I have the feeling it's not in yet even though it's at 1.0)...so I've rolled that back too (I have yet to see if the legacy input manager works with the new XR integration toolkit. Fingers crossed.)

At some point I might look at the SRP in 2020.1 as an option but sounds like there are a lot of things that just aren't there yet. And if I'm not using HDRP/URP/ECS...is there anything in 2020.1 that's worth risking the upgrade for, apart from some speed performance (which is less of an issue on a small project like mine)?

So I've found ways to make it work, but in nearly every case it's rolling things BACK not forward. Which I guess is my gripe. It's also taken 2 weeks to figure that out, because one would 'assume' that a full release (2020.1 for example) would be ready for prime time (with bugs for sure) but not relatively important sections/functionality missing/half baked. So I've battled the systems trying to make things work thinking that it was me, but in fact 'it's coming', 'we're working on it', it 'mostly' does what you want it to do and have to code the rest yourself', even though they hit their first 'full' release has been a struggle.

I'll probably end up just sticking with 2019 for good tbh. It's back to my USUAL issues for the most part...not as many WTF moments