Official Workflow Case Study - Show us your pain!

This is a great point -- but for users who don't know what they're doing, it's because they don't understand the meaning of the word in Unity's context.
A better description of what Unity means when it says "dependencies" would go a LONG way, so when their stuff actually _is_ likely to have dependencies, the user will know, and can be prompted on how to address this.
In general, a user knows when a script is always a script or an asset is always an asset -- but an fbx might need materials/etc. (though not always, and not for all .fbx files), and in the case where they do, why not just let the user manually flag the ones that _might_ have dependencies upon importing them into the project (and let the Unity handle the ones that definitely do, unless the user chooses to override them and link them to something else -- say, an .fbx to a different texture than the one in his model file). The user could also do this later when modifying the file (or any newly-made dependencies -- i.e. when you create a new texture in Unity that should be available to different models or scripts/shaders, you should be able to mark that script's list of dependencies i.e. via drag/drop). Then we would ultimately save the resulting information / flags to a very simple list/database/asset, and therefore save users the dependency scan altogether.

For a less complex solution, why not simply give the user a button or a menu popup that lets the user choose to check certain assets based on filetype (i.e. like fbx files) who are known to typically contain dependencies, and rather than go file-by-file, let these users choose to go filetype by filetype, masking off any filetypes they don't want Unity to check for dependencies. Even doing everything the current way, it would likely still be faster with this kind of masking.

The user knows which filetypes he/she has in his/her project, and this special knowledge could easily help Unity _semi-automatically_ help the user.

 

In that case, why not make "dependencies" a link into the manual that explains what a dependency is in the context of Unity? I believe with the exception of scripts, Unity does a pretty good job at tracking the dependencies. And often, you'll just add a folder that has "all the stuff" - and then, if you have a reasonable project structure, this will very likely already include all the dependencies, anyways.

So, I'd keep things simple. Just don't make something that requires complex logic the default (resolving all dependencies of all the items that are currently selected). Instead, make the simple case the default: User wants to add to the package what they have currently selected. And then, let the user check "Include dependencies" if they want to. Don't remember what they said this time, because probably next time, it's different ... and with "Include dependencies" unchecked, filling that thing is trivial, so it just takes a few milliseconds. Don't waste processor cycles.

Back to DOTS ;-)

 

I believe they solved this with Addressables. You can use an

AssetReference

, assign a scene and use it to load that scene via the Addessables system.

 

I posted about this in the HDRP RT section, but maybe this is relevant here:

https://forum.unity.com/threads/unity-experimental-hdrp-dxr.656092/page-18#post-6180615

 

Does this work without marking them as addressable? I remember of trying that but when assigning an AssetReference in inspector with a Scene it was marking the Scene as addressable

 

I don't know I've never thought of using an AssetReference and then not making the asset addressable. But I see why that can be useful.

 

Yeah, well, I've never thought of that either haha

The point is that you can only have a strong Scene reference currently if the scene is marked as Addressable, so if we just want bundled scenes we must rely on weak references or workarounds

 

That's not a bad idea -- but I think a summarized explanation (or at least a help popup -- maybe even one that grabs a blurb from the manual perhaps?) would be more practical.

I don't know about you, but I __hate__ switching applications when I'm in the flow of something, as I easily get distracted.


And regarding making dependencies "simple" -- I proposed the more complex solution (with a simplified UX) because Unity, in general, is notorious for not being able to specify (project-specific) resource-based dependencies easily -- especially when dealing with more "complex assets", such as Unity-generated dependencies for things like art- (i.e. textures/shaders that inherently rely on other, specific, textures) and scene-specific stuff that should have a "grouping" mechanism so that it can be easily-accessed/modified in logic (sort of like swapping out an entire GUI with another one.)

I think, to some extent, asset bundles "helped" with this, and so did prefabs/variants -- but the LOGIC portion of this has never sat well with me (making me create tons of spaghetti-systems for certain kind of data dependencies), as I can't easily define a "database" with "objects" that have "behaviors/data" that I want to instantly change/swap with another one with different behaviors/data all at once.
Nested Prefabs, for example, are great -- for handling only one object at a time. But dealing with a huge number of these resources (i.e. prefabs) at once -- i.e. multiple GUIs or sets of level tiles or enemies -- gets to be a big nightmare if doing it with vanilla Unity, as tools become too specific (and spaghettified) to be reused across projects, making this a required effort for each and every project.
Addressables helps with this (in theory) -- but I really think there needs to be a clearer transition from "resource database" to "prefab/variant" concepts (on the project-resource level) for cleaner search and/or instantiation later. Being able to assign assets to be dependent upon other assets manually (i.e. via drag/drop) would be a big plus here, especially when I don't have to dig into an API to handle this inherent dependency (which is not always automatically visible to Unity in more complex projects like the ones I work on.)

Manually assigning dependencies can also help in cases where swapping assets around (such as in your case) can be sped up by sorting these yourself -- i.e. by giving a popup with the option to automatically assign dependencies based on file type (scripts, for example -- or import directory -- for example: art->models->textures or materials->shaders->textures, respectively letting all models have texture dependencies or all textures have shader dependencies, depending on the preceding directory structure upon resource imports (which could simply be a right-click menu option on a project folder to manually "import/refresh" the right-clicked folder dependencies via UI), which can speed-up the import/export process for HUGE projects in general, as Unity no longer has to "search" for data you already provide it because it can assume data exists already in the folder (or throw an error when it doesn't).
Not that you're wrong for wanting this to remain automatic -- it's just my two-cents for the other parts of the pipeline / workflow that could be improved (and probably integrated with Addressables too).

 

Also, I almost forget about this one. Polybrush equivalent for terrains. Not being able to paint multiple prefabs at once on a terrain is a real pain for our artists.

 

Or rather -- make "Terrains" have a "Mesh Mode" so that Polybrush will work on them too. This will have the added benefit of also making Unity support meshes as a terrain type.

 

Here's a new paint point for you

This behavior of not being able to move things within Prefab Variants is really annoying:


Very often I have derivatives, and I want to add some important script like this combat module, but I'm force to leave it at the bottom of my tree, rather than stick it in some parent, or nearer the top of the heirarchy.

In this case I actually would prefer to have both the additional game objects (Colliders & MonsterCombat) at the top, as those are most likely to be edited, the rest of it is inherited from the base prefab and unlikely to change.

In a similar vein, this is also very annoying:


I want to move this very important script to the top, but instead it has to stay as the 5th component down. I can collapse of course, but it's preferable for readability to just put this guy first.

Would be really nice little quality of life win to remove these restrictions if possible.

 

A few very important aspects about the very core of Unity which are very easy to fix and about actions which are being done millions of times every day:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A - Doubling an object in your Project
"CTRL+D" should never switch the position of the original and the new double - this is terrible and can lead to big mistakes. The new copy with name ending "1" is put infront of the original which numerically wrong and very confusing + only visible on larger names if you check the extended name on bottom. Very sure that is recent and a bug that needs fixing.




-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

B - Doubling an object in your Hierarchy
"CTRL+D" should never go to the very bottom of the current
folder depth but be inserted right below the original - this is extremely disorienting and unnecessary, making an object potentially swap dozens of positions with no more visible relation to the original. This is very basic and the current behavior needs to be fixed.


(I press the CTRL+D button in the gif - you dont see the copy because its so far detached)


Here in Cinema 4D or other software - copy is just next to the original - as it should
Imagine the copy coming all the way to the bottom here - its just so messy and very easy to lose track.

(Also please add proper icons and color to the hierarchy - and allow coloring a entry Mac style)

Cinema 4D offers these settings:




-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

C - Reset for the Transform
I know there is a drop down menu, but drop down menus are very clunky and I constantly see people doing it manually
.
Please just add a reset button there, it must been unending thousands of man hours wasted by people going Click X > Press 0, Click >Y, Press 0, Click Z > Press 0 dozens of times every day.
At best a small button left side of each of the 3 names but that's probably harder.

 

D - Unpacking Prefabs UX
Every 3D Artist requires a lof ot mesh unpacking every day and many others as well. Unpacking was made even more uncomfortable recently by packing it into a 2 layers deep drop down menu which is awful to handle.

1. Please add a shortcut for unpacking a prefab completely
2. Please return Unpacking to the root of the dropdown menu
3. Please add a option to this popup, its extremely frustrating to be denied, then cancel the popup, to manually go to the hierarchy, then right click, then go search the deep drop down menu option, then go to the second depth of the menu and to then finally unpack it

The new prefab system added a lot of power but also made things a lot clunkier, with these tiny changes this would be a lot smoother again.

 

File Names - Allow 2 lines

Anyone having a professional naming convention as it is common for Assets and prefabs (maybe not so for scripts) will have their file names obscured.

File names often are like "Pf_F1_SetPipes_Corner_3x3m_A" and then fully obscured on the endings, especially on lower icon sizes. Artists especially require longer file names, and they can't work with the list view (which is the only that shows full names) as it dosnt show any mesh, texture and material previews.





There can be so much more information conveyed without using more space than now.



Especially with the copy paste issue described above this is much needed.

I wanted to check how much the space would need to be extended for this in photoshop but it turns out there is actually enough spacing for two lines in any scaling sizes!

 

Mesh and Prefab Previews (Nice to have)



At a glance it is always hard to scan which item is now a prefab and which is the original mesh



Giving meshes their mesh icon over the preview would make this a lot clearer.
The gray button on the dark background is easy to miss and sure you find it but its really slow on the recognition
My first impulse was to make every prefab have a blue prefab icon in the corner but given the meshes are far rarer than the prefabs usually, it maybe more sense to keep the prefabs clean and just mark the mesh properly as mesh

But given how often the prefab displays show temporarily empty, it might also be a consideration

 

Bonus:


Just an Idea: Unity only compiles scripts in a "Plugins" folder once right? to save on recompiling assets (as far as I know) .. that leads me to this concept:

Error assessment: Unavoidable Mess in Unity Projects
One thing that also adds towards making Unity feeling very messy is the search function, as it naturally shows all things in the project. Default assets, plugins and all sorts of examples clog up your project. Especially materials and textures make your search always look like a big pile of random things. It makes using the Engine feel very cluttered and unorderly, despite the reality being everything in their proper folders and properly ordered.


Everyone knows this.

Here is how a texture search looks in a basically clean new project just for testing a couple things. Any normal Unity project will be 10x worse but this is already very bad. Nothing is related. Its just a big pile of things you don't look for.
Adding only 2-3 Asset store assets even when trying to be very selective is adding tons of bloat and it gives you a bad unclean feeling about your project despite things being properly tucked away in folders.



-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Solution:
Nice to Have Feature: Filtered Search / Filter for Plugin Bloat

A - Simple approach:
Given Unity can already discern in compilation from the Plugin folder and the others;
1. (Optional) Add the Plugins folder by default, learn users to put plugins into the folder for order
2. Filter the Search by All from Project / Totally All / Plugin Folder Assets - so your search is not clogged up and the project and Unity workflow feels clean. Just make sure to memorize the Tab to make sure people keep the Tab they prefer.



Thats it! There is already support for tabs it seems, just enable them and filter by plugin or not.
We all know how heavily plugins are part of Unity, but it should be clear what belongs where.



-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

B - Alternative Approach:
Add a color around the search results of the Plugin Folder assets, so it is clear which one are from your Project and which ones are from External plugins and could be disregarded. This keeps it messy but at least you know what is from you and what is potential external bloat.





-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

C - Complex Approach:
This would tie in with a much requested feature - Color Tags for folders - add (maybe up to a limit) Folder tags and allow people to filter by their own tags. (Maybe marker colors and filter tags would be split) This would be the best solution but also require a bit more effort but would go a long way in making Unity more clean and shake off this messy feeling of a clogged Project.



(You can also hire me for UI and UX consulting, for free if it must - Ill have a lot more feedback especially about HDRP and Interface is definitely one of my passions)

 

is anyone else experiencing lag on every action, when using 2020.1.2?

 

You probably have prefab autosave on, so when you change something it updates every link causing massive lag - I was also confused heavily at first until I discovered this

 

One thing i really would like to see was a Tree view when selecting assets, so that i can see the folder structure.
It would only show folders that have the type of asset (like Sprites for example), then you have your UI, Character, Fx, etc folders with the sprites inside.

Like you said, it makes the effort to tuck everything in its folder pretty much useless, unless you drag the asset from said folders. Things get brutally messy when tilesets are involved...

The view could be name only for folder, then thumbnails for the files inside, if it's possible.
Here's a quick sketch to illustrate:

...instead of this...

 

Most likely been mentioned already, but it would be really great if we could have a 'designer' mode and a way to set components that will be hidden in the inspector with design mode enabled. (preferably with a lightweight indicator at the top to indicate how many components are hidden) We have a few components in our project that will never have to be configured by our artists and designers who mostly just use existing prefabs. Our artists constantly complain about how there are components they don't care about because they will never have to edit values on them, not without the help of a programmer at least.

 

Automatic dark mode switching (matching the system theme on macOS) would be a wonderful addition for me. I don't enjoy going into Unity's preferences to change to light mode during the day and dark mode at night when all of my other apps do it automatically.

 

Adding/Updating IAP is unnecessarily complex.

IAP should be a package only which can be automatically added when you enable it from services.

At the moment, it's a mess: Enable it from services, add package, add unitypackages from asset store and install them by step...

 

Small thing, but having an indicator somewhere in the status bar when there are new or updated assets to refresh would be a really nice thing to have. (for those who disable auto-refresh)

 

That's the purpose of the "Workspace" concept in the mockup Unity provided I think.


However, I still believe @Unity needs a better approach to the concept of "tools" in the Editor anyway.
For example:

Workspace -> (global) Shortcuts -> Toolbox -> (local) Shortcuts -> Toolset (+options/inspector) -> CurrentTool (+options)​

If you're interested, @willgoldstone:



What I suggested above goes a bit like this:


Workspace:

Global working mode (i.e. Programming, Data/Component Editing, World / Scene Editing, Visualization/Layout). This should be easily customizable of course, but the idea is that a Workspace has its own Toolbox, which calls forth certain Toolsets (and their respective Shortcuts for their respective tools)
In other words, in the "Visualization" (Workspace) mode, the user has a Toolbox that contains a few different kinds of Toolsets -- i.e. a Toolset that is strictly for physically navigating the scene (i.e. a flycam tool, an FPS character controller tool that allows the user to "walk" around the scene, a VR mode viewer tool that allows the user to pop in VR mode to visualize the scene, etc.), and another "Visualization" mode Toolset (in its respective Toolbox) is one that allows one to see measurements of gameobjects/prefabs overlaid on top of gameobjects (i.e. for engineers/visualization), which could be activated (in their respective Toolset) and forgotten about (along with other "optional" constantly-active tools / overlays / features in this Visualization mode), while going back to the "main" Visualization mode Toolbox(es) you'd probably be working in. The Multi-Inspector workflow would be perfect for this, as these inspectors could be "linked" to the Workspace itself, rather than a gameobject/prefab (though, internally, perhaps they could behave that way -- i.e. like an Asset).

Toolboxes in one Workspace may also be copied-to (and used) in other Workspaces, though their dependencies and Toolset / Tool prioritization would have to be redefined respective to other tools. For example, a "measurement overlay" Tool (and one or more Tools in its respective Toolset in the Visualization Workspace's Toolbox) could potentially be valuable in a GameplayDesign Workspace / mode in some cases (for example, when you need to precisely check the height of certain obstacles to ensure they're jumpable/climbable), but in that same vein, this Tool (or many tools in the Visualization Workspace Toolbox, including the "measurement overlays" Toolset) wouldn't be so valuable to a Programming Workspace (or subsequent tools/toolboxes that are associated with it). And since users like me are often switching between these workspaces often and quickly, a dropdown + shortcut option should be central and easy to access.

The biggest perk to Toolboxes attached to the Unity Editor's new Workspace concept is the fact that the Toolsets/Tools contained in these "Toolboxes" would finally make Unity's "Gizmos / Tools / Shortcuts" synonymous with one another -- and with the entire Editor's workspace and workflow -- essentially bringing 'Unity' to the entire Editor. -- Don't lie. Wouldn't this be a perfect final touch to the UI overhaul?


Toolbox:

As described above, a single toolbox is typically associated with a Workspace (but not always.) The idea of a Toolbox is that it groups all tools belonging to a particular functional goal (i.e. Terrain Texturing / Layout, Greyboxing, Gameobject / Gameplay Layout, NPC/Enemy Authoring, Dialogue Authoring, etc.), leading each functional goal to have many various kinds of tool and authoring needs (i.e. Terrain Texturing / Layout would need whole different sets of tools than Greyboxing or Gameobject Layouts, despite them both applying to the "World Design" Workspace.
In both cases, you might need a flycam Tool, so having that toolbox (and allowing the flycam Tool to behave both as a 'Passive' and 'Active' tool simultaneously -- i.e. it becomes 'Active' once a user presses a Shortcut defined in a Toolset to toggle its functionality on or off -- for example, if no other Tools in the active Toolbox use WASD, the tool can become passively activated, but when there are other tools that use the shortcuts it needs, a user simply enables it by clicking on its Tool icon in the Toolset, making it the 'Active' Tool, rather than a 'Passive' one that conflicts with other Shortcuts in any other Toolbox associated with the current Workspace.)

The best feature of all? -- A huge number of conflicting assets that try to take over your SceneView or project and end up wrecking things because one asset (unexpectedly) conflicts with another, as the tools they use are similar or located in a similar place in the SceneView, causing it to be impossible to use one asset alongside another.
Beyond even that, a LOT of the .dll files people use for similar assets (i.e. geometry generation / simplification using open-source .dlls) get duplicated when importing other assets used for _very_ different functional purposes -- and this means an inherent incompatibility between the assets that neither can toss aside. From a user-standpoint, having a Toolbox concept allows these kinds of assets (especially editor-only assets) to be free of this "global" conflict w/other (usually unrelated) assets. This is a common problem for people buying Assets on the Asset Store.


Toolsets & CurrentTools:

Ideally, there would be 'Active' and 'Passive' "Tools" in these Toolsets -- That is, there can only be a single "Active" tool, but there can be many "Passive" tools (such as the measurement overlays in the Visualization Workspace example). This distinction would not only deter Shortcut conflicts in complex toolsets, but it allows other shortcuts to be activated and deactivated depending on which "Passive" tool or "Active" tools are activated, allowing users to make certain tools or shortcuts take priority over others, depending on the Workspace / Toolboxes available. This would be possible since Toolsets are associated with Toolboxes and any Shortcuts or Tools labeled as "Active" must check for (and respond to) other Tools which are labeled as "Active" since there can be only one 'Active' CurrentTool at a time.

To make it simple, any Tool defined as 'Active' can be set to "ignore" its own functionality in favor of all other 'Active' tools (or tools with a higher priority). If both tools have the same priority (or both ignore themselves), then nothing happens. To let the user know an 'Active' tool was not activated (and why the current 'Active' tool hasn't changed), a Debug.Log() message can be displayed to let the user know they probably have conflicting Shortcuts or were trying to activate two tools at once (and then point the particular Toolbox->Toolset-Tool out in the message log.)
As for 'Passive' Tools -- these just execute their functionality when a certain condition is true or when a certain other Tool is active (or not -- which is usually the case of a default tool in an active Toolset, such as the raise/lower Terrain Tool when texture/detail painting is not active). Tools, whether Passive or Active, can also detect whether other Toolboxes or Toolsets are present (or whether particular Tools are activated in those Toolboxes/Toolsets, such as conflicting Passive Tools that may make the current Passive tool behave unexpectedly -- i.e. give incorrect measurement overlays) for any Tools/Toolsets/Toolboxes in the currently-active Workspace. This allows them to be able to change their functionality accordingly (i.e. blacklist some of their functionality if a Toolset exists in a particular Toolbox -- in other words, for example, if you have the MicroSplat Toolset, don't use the Unity Texture-Painting Tools -- and possibly disable the conflicting Tools/Shortcuts -- or even the entire Toolset -- since conflict will be inevitable).


Shortcuts:

I've gone into a bit of detail in how these should work above (for Tools in Toolsets), but it boils down to "local / global" and "Unity global" in terms of shortcut functionality. Tools and Shortcuts should essentially be two sides of the same coin. The idea of a separate move/scale/rotate "tool" to click on is dated at best. However, if these functionalities still existed, but could be hidden (with only the Universal Manipulator clickable) and allowed to still activate (i.e. the move Shortcut will activate Universal Manipulator, but the move/scale/rotate shortcuts still exist), things like 3D could move forward for beginners (without alienating old users).
As tools get more complex, the idea of having a Toolbox _and_ Toolset concept becomes necessary. This allows one to have three 'layers' of shortcuts in Unity, which ultimately better-defines their scope in real-world situations and use-cases.

For example, I don't need WASD to fly the camera around when I'm programming. I need a Programming Workspace that affords speed in getting to the scripts/data I need, rather than moving around the scene.
It would be infinitely more useful to use right-click+WASD to open windows or certain data assets for editing in a single keypress, for example. I'm doing less visual work, so why the hell do I need visual shortcuts?? There are times I might want to use WASD to open four different (commonly-edited) scripts at a single button-press. This means I will simply activate a different Tool or Toolbox to enable this -- and toggle between the modes I need (by toggling through the Tools I need) with a single shortcut key to swap tool modes quickly.
In contrast -- for designers placing gameobjects -- they'd still need a flycam, but they'd also want to press a single key (i.e. "P") to open their object picker/palette while they're in flycam mode to quickly drop an asset in place and fly away to the next one. In practice, this might require a 'Passive' tool to activate that picker palette for them when "P" is pressed as long as that 'Passive' tool has been activated (in its respective Toolset and Workspace) first of course -- otherwise, maybe they want "P" to snap them to point "P" in their scene, which is where the Player should spawn. The uses are endless -- but they need to be INFINITELY more flexible than what Unity offers now.
In the end, many Unity shortcuts can still be global (i.e. Undo / Select All / Duplicate ) -- but I'd suggest trying to filter them down to a more "localized" context wherever possible for the other, extraneous shortcuts (such as flycams), as most of these Shortcuts only apply (or matter) to certain Workspaces / Contexts to begin with.
Everything else, they are just a burden.



That's all I've got for today.

 

Another small one



A feature to highlight objects in realtime in the hierarchy or in the project view when an instance of them is hovered by the mouse, such as in this image. This would make it really nice to spot things faster and at a glance!

 

This actually already works - just not on hover but on click. Personally, I prefer having to click because pinging objects (you can also do this from your own scripts IIRC) by just mouse over could easily mess up your project browser or hierarchy view (because pinging objects that are hidden deep in some hierarchy, or simply out of view, obviously has to put the object into focus, so might have to open subtrees or scroll up or down).

 

I'd like it if it was just the highlight, and not the hierarchy scroll.

 

https://assetstore.unity.com/packages/tools/utilities/sceneview-highlight-and-pickup-109667

This tool does that, ( only works on default rp )

 

You should try Retrospect: https://assetstore.unity.com/packages/tools/utilities/retrospect-102835#releases

I bought it few days ago. I didn't use it that much, mostly because it's not a reflex I'm used to, but it's worth the price.

 

Hi, not sure if this was mentioned in this lengthy thread, but it would be nice if asset labelling in the project view could be improved.
My project is growing fast and I'm using a lot of different assets so someone suggested I started adding labels to my assets, which I thought was an awesome idea.
But the workflow to set labels on objects is quite tedious. Also I feel like they are not made obvious enough.

Here's the current workflow:
1) Select your asset in your project (you may select multiple assets but the HAVE to be of the same type)
2) Expand the "asset labels" menu in the inspector.
Note: if your asset is previewable (material, audioclip, ...) then you have to expand the preview window instead (doesn't make much sense to hide asset labels in there, it burrows the feature)
3) Click the tiny tiny label icon on the bottom right
4) Select ONE label from a searchable list (or seach for a label that doesn't exist to create a new one)
5) repeat 4 for each other label you want to give

now that I've done this, I can easily filter by label in the project view, and there's a convenient filter toolbar, yay
however if I want to use what I call the "target circle" (not sure what the proper name for it is, the little dotted circle on the right of a serialised reference) I have to type in the label filter by hand "l:myLabel" now that's kinda fine, but it would be nice to have the filters toolbar available in the target search menu

Here's are some suggestions
1) make the "asset label" feature much more obvious and central to the filtering workflow
2) make it more accessible instead of burrowing it into some hard to reach hard to notice place
3) make it more flexible (allow me to label multiple objects of different types at once, and why not, let me apply labels to a folder, where anything inside that folder will get that label)
4) make it easier to apply multiple labels to an object
5) make it easier to see if an asset is already labeled or not

edit: now I just discovered that my point 4 is a bit illegitimate because I can just press TAB to add a label instead of Enter. Though that workflow is not immediately obvious to the noob, so I still leave that there because I think it's interesting that it isn't immediately obvious.

 

@willgoldstone @MartinTilo
The inspector is not functioning. Can you please suggest some solutions?
I'm on Unity 2020.1.4f1


Bugs

1. ALL Inspector components automatically expand each time a new component is added, even though they were ALL collapsed
2. Arranging components is nigh impossible.

 

Post a bug report. D:

 

Haven't said it publicly until now, because enough

Any updates on this? Can we at least expect it for 2021?

 

No idea what "it" refers to here. D:

 

"It" refers to this discourse:

TL; DR:
Selection History is an upcoming editor feature, but last time it was mentioned (in the above quotes) it was in the "feature backlog", and not a high priority.

 

I was actually referring to native hierarchy folders, which I figured weren't too terribly far off given they're being given higher priority than selection history.

 

You guys should check Retrospect, it's already further than what you expect from Unity and you don't have to wait.

https://assetstore.unity.com/packages/tools/utilities/retrospect-102835

I'd rather have Unity working on deeper features and bug fixes. Productivity features are often better left to the community.

 

Hello ! I tend to test new editor workflows in new projects, and, a lot of time, in new unity versions. Could we have an "Empty" template in Unity Hub so we don't have to create our own for every unity version we want to prototype in ?

 

Two things are really bugging me with 2019.4.11f1.

For me, the most important buttons on the console are the ones that toggle logs, warnings and errors, but they're the first to be nudged out of view if you're short on space:


And this is exacerbated by the second problem, which is that the way the new font is rendered is just not legible enough for me. There are just loads of issues with sub-pixel rendering - look at the smearing on the lowercase m and t characters, and the top of every lowercase character. I have astigmatism corrected with glasses, and the way the characters smear together gives pretty much the same visual effect as if I wasn't wearing glasses. It just makes working in the editor a really stressful experience for me.



As a workaround, I can scale the UI up to 125%, but the text is still not crisp, and I lose lots of screen real-estate (see point 1).

My issue is not with the font itself, it's the way you're rendering it. From what I can see in the UI feedback thread this issue was brought up loads and loads of times, and yet nobody from Unity ever seemed to acknowledge the problem.

Are there any plans to address the issue? It's pretty disheartening to think I'm stuck working with this every day, for the foreseeable future.

 

I went back to check the old editor and there does seem to be some slight sub-pixel rendering happening on the font. But there are also plenty of absolutely crisp lines. The extra contrast between font and background colour probably don't hurt (admittedly I am comparing light and dark themes in these shots).

 

Not sure if this has been mentioned but the Package Manager UI is still absolutely horrible.

Some standout issues:
* The forced paging of my assets is brutally slow and annoying. It wouldn't be so bad if it didn't have constant amnesia... bringing to pt 2
* It doesn't remember anything, every single time it reverts to the same default view and ordering and non-paged results,
* It constantly says no results when there are results, I have to re-type to trigger the de-bouncer.

I dunno why this is so complicated, should just be a small local stash of all the "My Assets" meta-data (title, desc and versions) lazy update the reset of the content when I select one. All my packages would load instantly and search would also be instant. Updates should be done using some dirty token where it just requests from the server any changes since last request (which 99% of the time will be no changes, and any new updates will be tiny).

I understand the paging when searching the entire Unity Registry, but it makes zero sense when trying to go through your own assets, and remembering my previous sorting order and dropdown selection is just UI 101, if I last viewed My Assets, ordered by most recent purchase, it should just remember that until I change it, if I last searched "Grass" on Unity Registry, it should remember that instead.

Funnily right after typing this, I found another issue. I clicked "100", and now the window is stick "Refreshing Packages" and has thrown an error:

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. UnityEditor.PackageManager.UI.PackageList.OnListUpdate (UnityEditor.PackageManager.UI.IPage page, System.Collections.Generic.IEnumerable`1[T] addedOrUpdated,

Good thing it's reverted to showing me the same 25 assets, ordered by name for the 5,000th time Closing the window doesn't fix the issue, looks like I need a full restart?? :/

 

Another workflow pain... at this pt, this is really not useable. I have to scroll to see everything and it's becoming really hard to find even basic items.

We could use a total overhaul of the create panel:

 

No way! -- We don't need a redesigned Create menu!
Just stop buying things from the Asset Store, then make simple prototypes for the rest of your life like Unity does!
Problem solved!

That's how Unity 'fixes' these kinds of things -- Amiright?


----

-- @Unity

----

All (hopefully constructive!) kidding aside...


What you have described here is the eternal struggle for all UI designers facing user-generated content.

That is:

"Do I keep it fast and easily-accessible (1 click) -- or do I hide it and keep the UI clean/uncluttered (2+ clicks)?"​

This question is deceptive in some cases however -- especially with popup ("right-click") menus.
Technically, in right-click menus, you only ever left-click once because you right-click to open the menu, then left-click -- the actual click -- to make your final selection. Meanwhile, every option you 'slide' over with your mouse opens-up automatically for you if it has a sub-menu, and therefore prevents multiple "clicks" and still maintains a feeling of "flow".

About UX design

A beginner in UX tends to think "I just need to visually redesign the way this presents itself to the user so it feels faster."
However, "feel" (initially) has no place in managing massive amounts of user-content.
Clearly the "trick" to fixing this problem is not in how you visualize your presentation (or even your grouping) based on a subjective sense like "feel" since "feel" is very subjective.
The "trick" to handling large content is in how you manage the scope of your grouping (and therefore how you control the "feel" yourself) in order to, first and foremost, maintain the logical functionality of the application.
In other words -- The functionality is to CREATE an item quickly, therefore you need to determine the proper scope.
Ideally, all of Unity's (huge amount of) "stuff" should be under its OWN menu (that is -- have its own scope) so it can be created quickly, and addons should have their own scope (for the same reason) too.
However, scope (alone) doesn't manage "feel" (and you still need "feel") -- rather, scope simply informs what kind of a "feel" you can offer. The widgets themselves are what determine the possibilities for "feel" in the end.
(See Blender if you don't understand what I mean -- Blender has a HUGE variety of widget variations. These widgets, and how (visually and functionally) flexible they are will determine the kind of "feel" you can provide to users. Thankfully the pop-up menu is great for "feel"!)

The unique problem with the Create menu is that it is called in other places -- and as such, you can't simply make two unique versions of the "Create" menu (i.e. a MiscCreate > Microsplat > Action and a UnityCreate > UI Toolkit > Action), which would solve the problem more generally.
However, you can make two child-versions of that menu (i.e. Create > Misc > Microsplat > etc. and a Create > Unity > UI Toolkit > etc.) Since we are using a right-click popup menu, this is just as "fast" as the two separate Create menus, just with one additional option to quickly 'slide' through before you finally "click" on your action. Sometimes a simple spacer between commonly-accessed options helps with fast "sliding" through these cascading menus (so that users don't accidentally pop open the wrong one).

In summary:

In general -- better organization is necessary in order to determine "scope" more easily, but even a central place like the (very limited) Shortcut Manager to manage what goes into the "Create" menu would be nice to have (rather than just letting scripts add things to it willy-nilly from anywhere in the project. -- But I digress.

 

Ya, putting all the Unity stuff under it's own sub-menu seems like the best KISS approach, top-most in the list for nicest UX.

Another option I thought of is a per-project filter, kinda like ScriptExecutionOrder, and we could exclude items we don't care about for that project.

 

Binary / Enums / Bitmasks

See the following for an example:
https://forum.unity.com/threads/change-enum-value-without-unity-messing-everything-up.542292/
https://forum.unity.com/threads/property-drawer-for-enum-flags-masks-download.517750/


(It would be really nice to be able to rename and rearrange Enums in the editor...)



An easier-to-use interface for working with these plz -- both in code and in the Inspector... D:

 

One of the big waste-of-time-pains for me is that I can't just drop a list of whatever objects (enums, primitives, etc) into a popup and be able to select it without having to mess around with casts and indexes.

 

Something I have been thinking lately, Why does the unity team decided to work on showing different UI for the LOD Group component when multiple LOD groups are selected?




Does anyone remember there is something called Light explorer? Custom inspector window for editing a massive amount of data?



For some reason, they have implemented this only for lights, which is rather useless. I'm using it to check if the scene is clean and only that. Outside of lightning explorer, Unity doesn't have any tools for editing a large amount of data, a big UX issue.

I think users would appreciate the "lightning explorer" but for prefabs (with LOD component). I also feel like it would be amazing to expand the tool for scriptable objects. Every team would love that, especially ones that developed stuff like inventory system, crafting system, building system, etc.

 

You forgot the best one, Approach D:

Make it so any folder can be defined as an asset 'library'. For example, if you mark the Sprites folder as a library, then all assets in Sprites will show under the collapsible Sprites library, but all descendants will be flattened so you won't see them grouped by sub-directory. Then, you can choose specific sub-directories that will also be libraries. Libraries will be nested in the window with collapsing/expanding, and the sub-libraries are flattened just as well.

Approach C should also be possible through a toggle in the window. (i.e. entire directory structure can be navigated)

You could have some settings that can be set on each library.

• Change priority to influence sorting, that way you can make the plugins folder a group and set it to a lower priority and it will always appear last (whether browsing manually or searching)
• Or just set it as hidden, and now that library and assets inside will never appear unless you unhide it. (searchable popup with toggleable entries, i.e. like the shader selection popup but with toggle entries instead of selection)
• Or you can set a tint so that assets in that library appear with a different background color, to more easily recognize them.

Once you got all that, this UI can be integrated both into the project browser (a tab to access the same UI, or top-level groups shown in a category in the sidebar and/or per-group option to put them there) and a new standalone "Libraries" editor window.

To be honest I feel like others might have already suggested the same exact architecture, this is way too obvious and intuitive for it to be brand new. This is exactly what game devs working in Unity have needed for the past 10-15 years. Really hope this or something similar is in the work or in planning for the near future. I mean showing every single asset in a single list completely disorganized is such a bad joke... it might be hilarious if I didn't actually have to use it!

 

I actually made such tools for the level designer, it actually quite easy, just use

FindObjectsOfType<LODGroup>(true);

see UnityManual and it will return all Objects with LODs in all open scenes - then you just have to run your checks (are L2 & L3 objects at the same position as L1 objects? are L2 & L3 objects disabled when the LODGroup is disabled?) , build a list with UI elements (manual has a good example how to do it), maybe some filters and you are done.



Edit: omg, that spelling mistake xD *Position

 

Gigantic, bloated menus, by default. This is my pain. Well, one of them.

Made a thread about it over a year ago, worth a second try.

Searcher everywhere would help, but on principle I would also like to be able to change what is displayed in it.