Bug Uncool things in 2020.1 you might have missed

enough with the positivity
dump all the annoyings things that you've tripped on
do it yesterday!

 

this is uncool

 

Talking of uncool, it's not cool to not go with the guidelines set for this subforum:

 

other uncool thing:

instead of

who thought icons + pull down menu (that eats clicks) is better than icons?
not good

 

Terrain tooling change happened way before 2020 cycle though..

I do agree it's not good change (I've ranted about it last year myself).

 

My personal pet peeve with the new UI that I reported during 2019.3 beta that hasn't been ignored by Unity yet this month:



Directional Mode and Lightmap Parameters are lists. You click anywhere on them to change their value. Generate Lighting is a button AND a menu combined together. You click on 90% of it to generate lighting and you click on the rightmost 10% around the triangle to select alternative operations. We know this, because we've used older versions of Unity where there was a nice vertical line separating the two that clearly communicated that this was in fact two things. If you're a new user who hasn't seen the good UI, only the new one, you'll have no idea. The only visual difference between them is how the text is aligned. Hands up if centered text communicates "this is a button-plus-menu combo widget" to you.

 

Yes wildcard when searching for anything in any search field.
Quicksearch has a completely different usage profile and showing which categories are bring search is confusing to the eye "oh there are hits... nope it's just the categories"

I was gonna say "the Fonz is cool and he doesn't follow the rules when he taps that jukebox", but yeah you're right it's a messy thread now, which is uncool, I created it more as a dumpster for all things cool for people to check out but off course I couldn't keep my mouth shut and had to balance it with its counterpoint Hipo, if you want to lock this thread, I won't beat you up with your "I love Cats" beer mug.

You lost me here buddy, better show the before and after.

 

Before: https://docs.unity3d.com/uploads/Main/Lightmapping-0.jpg

I'm not married to the double up/down triangles but they also helped to distinguish these two different controls even more.

 

Yeah the single down triangle should be consistent (both are drop-downs in the end) but the separator needs to return

 

Unity creating unwanted lightmapping settings file all over the place (we don't use the lightmapper at all in our project so it is just spam.

My solution:

Code (CSharp):

1. [InitializeOnLoad]
2. public static class EditorHelper
3. {
4.     static EditorHelper()
5.     {
6.         EditorSceneManager.sceneOpened -= OnSceneOpened;
7.         EditorSceneManager.sceneOpened += OnSceneOpened;
8.     }
9.  
10.     private static void OnSceneOpened(Scene scene, OpenSceneMode mode)
11.     {
12.         Scene activeScene = SceneManager.GetActiveScene();
13.         if (activeScene != scene)
14.             SceneManager.SetActiveScene(scene);
15.  
16.         if (Lightmapping.TryGetLightingSettings(out _) == true)
17.         {
18.             Debug.Log($"Clearing lighting settings for scene: {scene.name}");
19.             Lightmapping.lightingSettings = null;
20.             EditorSceneManager.MarkSceneDirty(scene);
21.         }
22.  
23.         if (activeScene != scene)
24.             SceneManager.SetActiveScene(activeScene);
25.     }
26. }

The fact that I have to change the active scene like that is Uncool in itself.
If you make a new API in a new Unity version, try to make it not suck. We have enough old bad API

 

Some proper way to tell Unity that "we do not use light mapping in this project at all".

We don't lightmap in our project either, and there's quite a few infuriating bugs that comes out of that. Here's a fun one - since we don't lightmap, some of our models doesn't have normals. If we run Unit tests using Unity's test runner, we get thousands and thousands of warning messages about meshes lacking normals for every. single. test. This means that tests takes dozens of seconds each since printing all of those warnings to the console is so slow.

This means that a side effect of running a unit test is that every single mesh in the open scene(s) is checked for proper normals. The reason this happens is that as a part of the unit test pipeline, Unity adds a new scene and sets it active, so game objects created during the test gets created there, and can be cleaned up properly. But since that scene is active, and we're not in play mode, it starts doing lightmapping stuff.

Which is a bug that never got through QA and, like... sigh? We have to close our scenes in order to run unit tests, because the light mapping gets in the way.

This is of course the unit test implementation being stupid and bad, but if there was a global way to just remove all traces of light mapping from the engine, you could actually know that it wouldn't tank the editor performance for users not using it.

So as I said, I don't use lightmapping much, so I haven't seen how much of an actual pain it is, but it seems like the Lighmapper API requires you to set the active scene to get hold of the LSA. That seems silly - if you're writing a tool that wants to get the light settings from one scene and apply it to another scene, you have to do a bunch of scene switching. I'd suggest adding overloads and methods to the API so you can get all the data from any scene, not just the active one.

 

I second this. There are too many advanced features that are on by default on Unity, if they are advanced they should be turned off by default and not on.
I lost count of how much time I lost tracking down the materials that are created with the Standard shader by default on a Android target, is the standard shader really the most common shader on mobile? I find it hard to believe.
A simple setting for changing the default shader should have come before even introducing this behaviour, cause the standard shader takes forever to compile every time I upgrade Unity and if you leave accidentally some object with it, you will see huge frame drop on low end devices.

 

You probably wrote the wrong thing there - but just to make sure that we're not talking past each other - you meant "all lightmapping", not "all lighting", right?

Because we for sure use realtime lights. We're not talking about us rolling our own lighting solution here, just that we don't have the time/need to deal with lightmaps.

 

There is a place in hell for whoever thought this was a good idea and refuses to revert it after users complain about it.

 

another uncool thing about the new terrain:

Spoiler: now you see me

Spoiler: now you don't, when painting on terrain

so yeah good luck painting terrain to match your tree's position

You made my day.

I think some folks in the UI team have no production experience so they go for certain academic ideas. The positive aspect though is that it was recognized as a regression: https://issuetracker.unity3d.com/is...l-and-blocking-requiring-two-clicks-to-switch
VOTE NOW!

 

It doesn't event make sense academically. Drop down menus with text are only good for textual things like names. Everything that can be identified with an icon should be a button with an icon.

I agree, some people at Unity lack the production experience. Take the new UI for example with it's lack of colors. Next time they'll remove the icons.

What bothers me even more is that, few years ago, I asked for better icon differentiation between 3Dmodels and prefabs on the old UI because, it created confusion for beginners and students. Now it's even worse.

Same for the package manager. That was okay with an "update" icon easily identifiable.


then still no colors but a chance for similar squared icons requiring more attention from the users. Why?


2020 is less worse but still confusing. "Preview" doesn't need to be orange, but update icon should to pop up. Also, why does it takes more space with two lines?


Just make it simple like this.

 

Look at that in the light skin. It's even worse, the contrast is less between the two shades of gray that's on it.

 

That's one of the reasons I'm strongly opposed to the light skin.

 

This is very good design.

 

This is not very good design

see how the dull orange sound icons blend in with the gray

This was far better
Plus the light theme is now far more lighter therefore aggressive on the eye.

 

Of course it was better but it's not trendy. There are certain priorities in modern UX design and usability is not popular these days.

 

I totally agree. These new icons break a lot of rules about icon readability. I opened a thread asking for an option to work with the good icons: https://forum.unity.com/threads/need-an-option-to-use-the-old-ui-icons.901952/

I invite anybody who don't like the new icons to participate on it.

 

Marketing people should ask themselves how long the users who like trendy icons over functionality are going to stay in business.

 

API that has implicit parameters in a global state somewhere are bad.

You should have an API to set/get lightingSettings for a scene, NOT the active scene.
Ever since Unity introduced multiple scenes you should assume people use it! (I know we do use it heaily.)

The simplest would be having a lightingSettings property in Scene. Then Lightmapping.lightingSettings would become SceneManager.GetActiveScene().lightingSettings which is longer but now there would be an added benefit to be able get/set this for any open scene.

If you want to put it in the UnityEditor namespace, than I guess you would need a GetLightingSettings / SetLightingSettings that accepts the Scene as a parameter somewhere (eg. in Lightmapping)

 

Why the "ForScene" suffix? If you pass a scene to these methods, it implies it's for that scene, I would argue.

 

I think it's fine that it's explicit about what it is. It'll also be easier to find for eg. google searches ("light settings scene" will give a hit)

 

Is passing null a valid use case? To what scene would the lighting then assigned to?

 

Having the overloads would work, you'd just get an "ambigous reference" compile time error if you tried to pass the literal null to the method.

So if passing null to it has a semantic meaning, then you have to have different names, but it probably shouldn't have!

 

Cant wait for an nre, my favourite

 

PostProcessingStack V2 On and Off buttons do the same thing. I have no idea if an effect is on or not.

 

If you run URP or HDRP, PPv2 isn't used by default. For URP 7.x you can manually enable it but otherwise it will just use URPs own internal PP. HDRP has had own PP since 2019.1.