Official Workflow Case Study - Show us your pain!

Also scene directories. Parenting GameObject has an transform, memory and instantiation impact.
I mean, I remember asking that 8-10 years ago.

 

Here are my top grievances:

When making a "Custom Function" node in shader graph, I have to type in all the input/output parameter names manually, and then select a data type manually for each of them. So many hours spent on something that could be avoided, for something that could be parsed out of the file and auto-populated.

Also, the requirement that functions must end in "_float" or "_fixed" -> meaning I have to modify existing shader library if I want to use any of it in shader graph. This also means I can't use excellent shader libraries like lygia, because of course they're not going to have a "_float" or "_fixed" suffix. It's like Unity is saying, "We don't care at all about any of the code you might currently have, just rewrite it all to fit our arbitrary conventions"

Finally, it would be nice to have assets from packages show up in dialog boxes.
E.g., I want to assign a texture from a package to a material, the only ones that show up are the ones in the project, the stuff in packages doesn't show up in the texture selection dialog.

 

One of my pains would be the Scale transform Gizmo helper not having a handle to scale by two axes simultaneously, so you can only scale by one axis at a time.

 

(Case 1362892)

Is anyone else mis-clicking the vertical scroll bar... 40% of the time?

There is probably 5 pixels width to be able to select the vertical bar, before it swaps to the extension tool.


The editor seems to also get confused as it skips between the scroll and extension tool midway through. Check out the gif.

If your UX team wants beautiful narrow scroll bars, please check out how Steam does it. Its 20 seconds into this gif

 

Another one would be to quickly move an asset in Project tab to any other folder via some Search mechanic. I frequently move assets between folders and the only way to do it is to have the folder destination visible in the tree view on the left side of the tab and drag-n-drop the asset there. With a lot of folders/nesting it becomes a hurdle to the first search for the destination folder, then go back to the original place without losing sight of the dest and only then D&D.
It would be nice to have a 'Move to...' option in the asset context menu that would popup a dropdown where I could quickly search for the destination folder.

PS. I guess I could hack something myself if there's an API to display the search dropdown without issues and I'd use something from C# to search through the names of all of the folders.

 

Right Click on project tab, choose two column layout

 

@Ne0mega all of it is described from the perspective of already using Two Column layout:

It's still a chore to move assets around.
Also, lack of the Back and Forward navigation in the Project tab also adds to it, so if you click on any of the folders by accident you have to manually navigate to the previous place again.

 

What a great idea! Back and Forward buttons for the Project tab would be amazing.

Something else that would save me a lot of time when flipping between multiple folders in the Project tab: remembering the last scroll position within each folder individually. (I can't tell you how much time I spend scrolling up and down to try to get back to where I was last within a folder after exiting it for a second folder.)

 

In continuation to my suggestion to add "Move to..." action I quickly hack together this window that is triggered from the context menu in the Project tab and displays results using TreeView:



What's interesting is something that I didn't think about, but you can dock this window somewhere and then quickly reorganize your project by selecting the assets, searching for the destination folder in this window, and then double-clicking on the folder to move all of the selected assets in that folder.

But yeah, a built-in solution from Unity would also be welcomed.

 

One other thing that would make for a killer productivity boost: for developers using sprite sheets, allow batch editing of sprite properties within the Sprite Editor. (Having to individually select each frame of a sprite animation and re-enter position and pivot information over and over and over again is a huge time sink.)

 

I have a small issue that slowly starts getting irritating. Here, a project window:



If I will select a file in the project window, something like a material, then decide to go to a different folder by selecting a folder from the left side of the panel, then I will just switch folders. Everything works as expected. But If I will try to do the same (clicking a folder) on the right side of the panel, then my material will get unselected.

 

Here's a colossal pain in the [REDACTED] point:

The UIToolkit is just far enough along that I was able to make a pretty nice interface that works pretty well.
The XR Interaction toolkit is just far enough along that it works pretty well.

But it doesn't work with UIToolkit!!!!!!!!!!!!!!

I hate being sold on getting just enough rope to hang myself with these new systems.

Look, a large part of game dev is about getting multiple subsystems to play nice with each other. I mean, just look at what the Asset Store is all about! If Unity's going to make a couple of new subsystems and advocate for their use, they *have* to make these subsystems work together (XR + UI) before they can say they're complete and production-ready.

I don't want to have to keep having to kludge together temporary fixes or dig into their source and duplicate efforts that they'll later be rendering obsolete when the Unity devs finish what they started. It takes me ages! I suck at it! I don't even get paid to do it! It's an inexcusable cost! C'MON!

Sigh.

All right. As a dev I understand that these things can't be rushed. But damn it, the marketing and documentation teams need to stop baiting me with sweet little half-truths about how wonderful their new stuff is when the tried, tested and true legacy systems would have worked fine. My project would be a lot further ahead if you didn't keep sticking twigs into the front spokes of my development cycle.

PS: Please stop calling everything that works: "Deprecated".

 

This right here is one of Unity's biggest offenses. As someone who started using unity about 4 years ago, it took me 2 or 3 years to finally realize that taking that bait is going to always burn my productivity. And the worst part is that I know that I'll probably fall for it again at some point because they make the shiny sound so sweet.

 

I'll just drop this one here.

 

Here's another one: when you search for a line in the console and click it to highlight it, when I dismiss the search, please keep that particular line highlighted and make the console window scroll to show it. Finding the line is only half the battle--most of the time, I need to see it in context to really understand what's happening in the code. I shouldn't have to go back and dig through manually to find it again just so I can see it with the surrounding console lines.

 

When you lose 2+ hours because, for some reason, you updated a script which has nothing to do with the entire project, but the editor needs to scan through every texture, asset, and atom in the project. No cancel, you're just along for the ride as your day of gamedev is crushed in the palm of the editors hands. To further torture, the bar starts off at 99% and stays there because the editor has no concept of how many assets there are or it does and it just wants to grind up the little ashes of hope you have and steps on them.



Update - It ran for 9+ hours then the editor crashed

Meanwhile, the team who wrote the Editor code for scanning every asset because they never heard of hashed data deduplication, background or farmed processing threads, or packaging jobs with recovery snapshots.

 

Whenever i make the tiniest change on my very simple game (unity 2021.1.24):

I have like two hours to spare every night on my game but half of it is waiting for unity.
Adding a simple log takes 4 minutes. Scripting is unbearable now, it wasn't like this before.

 

Welcome to the post 2018.3 Unity with the new and improved project workflow.

 

Fix this bug: https://issuetracker.unity3d.com/is...nent-does-not-work-on-body-aim-and-noise-tabs

 

Open the profiler, set it to "Editor" (instead of "Runtime"), enable "Deep Profile", then change a script.

Most likely this isn't actual compile time because I have a 60GB Project with thousands of lines of code, a few dozen assets, many containing scripts and the actual compile time is 4 seconds while recompile time was over one minute and is now at ~30 seconds. I am not using any ASMDEFs at all .. because they only help with compile time.

What's actually happening is that all

[InitializeOnLoad]

and

[InitializeOnLoadMethod]

attributes are executed, this causes some Assets to scan through all assets to find their Database, it causes the NewInputSystem to recreate some files (which takes a lot of time),
Also all existing scripts are trashed and recreated = DomainReloading,
Which in turn causes all TextMeshPro, ProBuilder and all Mesh-Creating-Components to recreate their mesh and trash the old one,
As well as all (or just some?) Scriptable-Object

OnEnable()

calls.
So the bigger the scene and the more scenes you have opened and the more dynamic meshes they contain, the longer you will have to wait for recompile because all of the above leads to MASSIVE garbage allocations - which costs time to clean up, as well as time to de-serialize all required data to restore the values.
(Editor Windows are Scriptable-Objects too, they are re-created on re-compile, and for some reason, rendering the scene takes ~15 seconds after a recompile, which I still don't understand because the same scene can then be rendered in 1/60 seconds = 0.16ms I think)

I was able to cut recompile-time in half and further improve it over time by removing almost all

[InitializeOnLoad]

and

[InitializeOnLoadMethod]

Attributes, changing

OnEnable()

methods in my ScriptableObjects, disabling Gaia and other assets with an

#if DEFINE

and usually not having all our big scenes open when working on scrips but instead using my test-scene which contains just what I need and nothing more, also I changed EditorWindows to initialize in

OnBecameVisible()

, so it won't get triggered on recompile if the Window is just a Tab and not fully visible.

(PS: Also I had massive stalls up to 4 minutes when duplicating assets and doing simple stuff, deleting the libary fixed this issue.)

 

That is so true. I spend so much time taking care of not accidentally deselecting the material by clicking a folder.
If I click the folder, it shows the name of the folder in the Inspector. This is soooo stupid, it just does not make sense and forces me to locate the material again. I could click the "Lock" key icon to lock the material, but that takes too much time.
If simply a click on a folder would not change the Inspector, then all would be good!

Here is a sample:


Makes absolutely no sense to display the name of the folder and polluting the Inspector and thus removing other valuable information.

 

You can make custom inspectors for folders. It takes a bit of hacking and reflection, but you can set it up such that selecting an inspector shows a simplified inspector for the things inside the folder.

For example, we made a game with a ton of "Item" and whatnot scriptable objects, and instead of having to go into the folder and edit them there, we selected the folder they were in, and got a nice scrollable, searchable list of simplified editors for all the items in the folder.

So that's a nice reason for the feature to exist, but yeah, by default it's really annoying that folders get selected as the information isn't useful.

A potential solution is to open the material with the property editor. You can write an [OnOpenAsset] that does that automatically when you double-click the asset, if hitting the "p" key is too annoying

 

But, yeah, I literally thought I was stupid for not seeing that. Turns out, it is only available if there is an instance of the prefab in the scene. Probably why i missed it so many times, that and "context" only kind of makes sense... ..I think "prefab view" would be a more sensible label.

Also, ping exists, but is still a giant hassle and hardly worth it in many cases. ID still like to have a "ping in heirarchy" and "ping in project" option, but most of all, and Id like for it ALWAYS to only be one right click away.

Also, If I did not mention it aleady, it would be Really nice if there was a way to find all the objects in hierarchy with a component, or more specifically script. Same with in the project. (again, an option, ping in Heirarchy, ping in project, explode the trees to show them all if necessary) I delete scripts often, and I just want to keep it clean, especially since with auto-refresh off having a deleted script can cause a compile lock, where it will not refresh until you hunt down the script and remove it from everything it was attached to. It's a PITA now, and that's when I only have scripts attached to a couple object... ...this feature would also be very helpful, when say changing a public field, and then having to find every item with that script and changing what is assigned to that field.

..or maybe just an option when deleting the script, to also remove it from any and all objects at the same time.

 

To find all instances of a script in the scene, you can search with t:ScriptName. So, for example, t:BoxCollider finds all box colliders in the scene. Also works for your own scripts.

An alternative is the (experimental) dependency finder, which can find dependencies all over the project.

 

Can we have an option to disable the play button until the editor actually started playing?
I lost count of how much time I lost waiting for the editor to start playing and stop by itself because I accidentally clicked the play button two times.

 

https://twitter.com/willgoldstone/status/1352269824467066881

 

And it was working fine in 2017, 2018 or so..
in recent versions, maybe 2019 and later that always happens..

 

I contacted the QA team about the scrollbar bug. Apparently it's been flagged since 2019.4.. If we don't vote on it, I guess it'll never get addressed.

<--- That bug

Anyways who knows if voting even helps.. but vote away if you'd like the UX team to maybe, possibly fix this.

https://issuetracker.unity3d.com/is...e-editor-when-windows-are-docked-side-by-side

 

Here's another pain point: you can't keep two different instances of the Project pane open to different folders without accessing an obscure "Lock" option buried in a right-click menu. By default, the moment you click on an asset in one Project pane the other Project pane refreshes to mirror the other regardless of what it was displaying a moment prior. This completely defeats the purpose of allowing the user to have multiple Project panes open; each Project pane should be locked to its own display by default.

 

Actually there is a lock icon in the top right that does the same as the menu option.

Though I do agree some what that maybe each project window should be locked by default.

 

Just made a thread before noticing this one, but all of my pain can be summed up in 1 image:



It goes behind my taskbar, I don't even know what's down there, nor can I click them.
Nearly nothing should be outside of a submenu. Here's an example of how it should look:

If possible, a string array allowing us to override the context menu
Ex:

Basic Stuff/Folder
Basic Stuff/C# Script
Shaders/Unlit Shader
Shaders/Material

Then those options would be moved into these new paths. This would also enable us to set new menu paths for plugins, sticking them all in 1 context submenu if we wanted.

Or even hide away things we'd never use in another submenu, like:

Unused/Playable Behaviour C# Script
Unused/Lens Flare
Unused/Lens Flare (SRP)
etc.

Possibly even just support through scripts. Modify/remove existing menus the same way we can add to them.

 

Can we have an additional icons(or other marking) on assets miniatures indicating what type of asset it is.
Everyday I got this problem that I try to drag wrong asset type to wrong field.

 

Here's another workflow drag: unlike many of the other issues, it's not a UI problem but a functionality problem, and it's a problem that didn't exist in earlier versions of Unity. Unity no longer pinpoints the line where a range error occurs, instead pointing to the end bracket of the function where the exception occurred. This is dramatically less helpful, and results in hours of wasted time tracking down the offending line of code.

 

@Sinister-Design It works for me with these settings:


Though I agree that it was broken for several releases or at least I couldn't get it to work.

 

Opening Unity on a Monday morning. Exiting 'Safe Mode' because of some script errors from last week, Unity decides to reimport the entire project for no reason, and just when it reaches 100% after 20 minutes, crash.
Open Unity again, assets are reimported, phew! Change 2 lines of code, Unity reimports the entire project...
At this point, starting Unity is my biggest pain point.

 

Not sure if anyone from Unity's still reading this, but here's another one.
Seems like they swallowed the 'hide everything under the dropdowns and icons' pill completely (started with Terrain tools) and in the upcoming 2021 version they overhauled the top toolbar that now became a part of the scene view which makes it much harder to access certain very common options like Pivot modes and Gizmo settings because:
1. I first need to decipher what the icon means
2. click on the icon
3. read the options
4. select the option
when the previous flow was to just click the button.

Also, some of the options are just unaccessible now without scrolling when the scene tab is shrunk a bit. All the while there's a huge empty space just above it where these settings previously comfortably resided.



Here's my tip for your UI designers, Unity:
1. icons are not universally better than plain-old labels, especially for the most common items, as the time to convert the icons to the meaning adds up a lot, while scanning the text is instaneous. (here's an article on the subject: https://blog.prototypr.io/icon-or-label-1486425252bd).
2. hiding options under a dropdown, especially when there are only two of them, is a bad UX practice that again leads to more developer time being lost.

P.S. did you hire interns to design your UI or something? If so, I would understand that you let them practice their UX skills at your expanse, but please leave the option in the settings to revert to the previous layout while you're at it.

 

While I am not Unity, I can address/tell you the reasoning behind some of the changes.

While I understand that this may be a bit annoying/confusing. It over all is a good idea, and here is why. It moves all things related to a specific window (in this case the scene window) to be in the window that it affects. This helps keep things consistent and contained to the scope that they affect.
This is especially helpful when taking in to account other tools than just the basic ones. For example ProBuilder, it can how integrate in with the default transform gizmos instead of having to work around them. You will be seeing a lot of both Unity tools/packages/components moving to take advantage of this new system over the next few versions. I know Cinemachine's latest 2.9 beta already has started some integration along with the new Spline system using it fully.

I agree with you too a point, but part of it is like with anything, it just takes a bit of time to get used to/learn. Also, if you dragging the pivot item out and right click and set it to "pane", you get the names back (Though it cannot be in a side/title bar). Or if you right-click it in the titlebar and select "collapse" you get a dropdown button that gives you the text when clicked on.

The great thing about the new system is that you can either hide the options you don't need, rearrange them, or move them to somewhere completely different (the sidebar?).
While it may feel more inconvenient now, the previous system was simply not maintainable as Unity continues to grow. Things like asset store tools were already overlapping each other sometimes in the scene view. And Unity is only getting bigger and adding more tools, ProBuilder, ProGrids, ProPainter, Splines, new Terrain system, etc, etc. that of course is not including all of the great tools that are on the asset store.

They are aware of that, they are looking to add workspaces and may add them there, or possibly even just remove that space all together (that is what they said in one of the threads about the new overlay system some months ago).

You and I both know this isn't true. It is just needlessly rude and harsh. I understand if you don't like a UI/UX decision that they have made, and want to express that but it is uncalled to insult the people working on it. I for one vastly prefer the new system over the old one. And even if you don't, there are still very valid reason for why they made the changes they did, even if you don't like all the things they changed.

 

Here is my pain: I pointed this out 14 months ago and nothing has been done. All you have to do is add a scroll bar, how hard can it be.

Does Unity3d actually care at all, or is this simply a thread where people ventilate about their problems and then go back to accepting it in the ass?

 

ive been using this ever since found it,
https://forum.unity.com/threads/undocumented-but-public-defaultexecutionorder-attribute.530618/

 

The perfect example for why we need a selection history, posted by the official unity youtube channel:

 

https://assetstore.unity.com/packages/tools/utilities/selection-history-184204

Until there is an official selection history you can use this

 

About as painful as it gets. Tired of having to kill all the Unity processes...

 

WHYYYY is unity so slow lately?? These windows keep coming up for minutes on end.

 

Don't know if it is a bug or a "feature" but since upgrading to 2020.2 unity select the element furthest from the camera when selecting UI elements instead of the foremost one. Kinda annoying as I have to click countless times before it actually click what is under the mouse.

 

-

 

So much time wasted waiting for reloading assemblies in 2020 LFS.

(can't work out how to post log well so Csharp code format will have to do).

Code (CSharp):

1. RefreshProfiler: Total: 39.834ms
2. - Completed reload, in 145.454 seconds
3. Domain Reload Profiling:
4.     ReloadAssembly (145455ms)
5.         BeginReloadAssembly (143866ms)
6.             ExecutionOrderSort (0ms)
7.             DisableScriptedObjects (36ms)
8.             BackupInstance (0ms)
9.             ReleaseScriptingObjects (0ms)
10.             CreateAndSetChildDomain (142ms)
11.         EndReloadAssembly (1548ms)
12.             LoadAssemblies (143695ms)
13.             RebuildTransferFunctionScriptingTraits (0ms)
14.             SetupTypeCache (154ms)
15.             ReleaseScriptCaches (1ms)
16.             RebuildScriptCaches (83ms)
17.             SetupLoadedEditorAssemblies (568ms)
18.                 LogAssemblyErrors (0ms)
19.                 InitializePlatformSupportModulesInManaged (4ms)
20.                 SetLoadedEditorAssemblies (0ms)
21.                 RefreshPlugins (1ms)
22.                 BeforeProcessingInitializeOnLoad (112ms)
23.                 ProcessInitializeOnLoadAttributes (441ms)
24.                 ProcessInitializeOnLoadMethodAttributes (7ms)
25.                 AfterProcessingInitializeOnLoad (3ms)
26.                 EditorAssembliesLoaded (0ms)
27.             ExecutionOrderSort2 (0ms)
28.             AwakeInstancesAfterBackupRestoration (411ms)
29.  

 

I am just now getting into the scene workflow. Before this everything was done in one scene.
Switching between scenes.... (I think a previous scene toggle has already been requested)....
..I am dumbfounded to see that the hierarchy tree closes, pretty much losing the way everything was.

That is very inconvenient.

 

Is auto refresh completely broken in 2021.2.2f1?

I have it disabled but:

• Unity will randomly decide to do the refresh without me asking
• I can hit Ctrl-R several times and nothing happens, and then when I start the game in edit mode it does the reload
• I can hit Ctrl-R several times, start the game, and the changes aren't reloaded

The first problem is the worst because it can really eat in to my time doing unnecessary reloads.

 

I have auto-refresh turned off and Unity keeps deciding to do little auto-compiles and updates and refreshes as well. There are also times where Unity refreshes every time I create a new C# script, or when I create an .asmdef file.

Unity: "hey moat, heard you were trying to work. Well, I'mma let you finish but... [COMPILING]. did you want to do this... [COMPILING].... and I [COMPILING] thought that [UPDATING] you might want to work on some [IMPORTING] files and maybe [UPDATING] get into the groove [HOLD ON...] or a zen work mode state, but instead I'm [COMPILING]just going to [COMPILING]chop up your [HOLD ON...]time into little [UPDATING]teeny bits and [COMPILING]interrupt [HOLD ON...]you constantly."

Could we have a hotkey toggle to turn off all these overly aggressive and disruptive updates where I can create new C# files and .asmdefs and new textures and then when I hit the hotkey, it turns all that crap on? You can even make a little red light turn on that says: "pending changes...", and if I hit the Play button with pending changes, then it does all its imports and compiling and obnoxious updates.