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.

4 Likes

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.

2 Likes

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.

3 Likes

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.

1 Like

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

1 Like

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.

1 Like

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.

1 Like

@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! :slight_smile: 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 :slight_smile:

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

1 Like