Official Workflow Case Study - Show us your pain!

Isn't this what "Align to view" is for? I'm not at my computer so I can't check the exact menu item, but there are a couple related functions in the menu. One is to align the view to the selected object, the other is to align the selected object to the current view.

 

No cut & paste in project or hierarchy panes!!
this hurt my soul to even type out

UI to add scripts to execution order in Project Settings is a terrible experience
The popup uses the generic OS menu which does not allow searching. Unity is being used for large projects, in case you did not know. In our current project, I was able to calculate that it would take ~23 screens stacked vertically (at 1600 pixels each) to be able to see every entry at once. If my class starts with a Z (assuming no namespace), it takes around a minute to scroll to the bottom by holding the down key on my keyboard.

 

Useful for cameras yes. I imagine you could use Align to view then just scroll out a little to see the object, but still a roundabout way to achieve my particular use-case which is a common thing to do when working in 3D. Also the rotation of the object would become messed up; what if I just want to position my object without messing with the rotation? Now I also have to reset the rotation.

 

Yeah, that UX is terrible. But it is possible to drag&drop scripts from Project to Script Execution Order.

 

My pain is within the Slice menu of the Sprite Editor. This menu allows me to slice a sprite sheet and set a custom pivot point for each sprite using float value, but not in whole pixel units?!

This "Pivot Unit Mode" is already available in the main Sprite Editor window when editing individual sprite, so why not add it to the Slice menu?

Most of our game's sprites are drawn in pixel art styles so any slight offsets are visible within the game, hence why a pixel-perfect precision is crucial. Some current solutions amongst my team are:

1. to open the sprite in an external editor, determine its size & the desired pivot point and then divide these values to get the exact float value.
2. Slice with the pivot at (0.5, 0.5) and manually adjust it for each sprite

It really bugs our workflow!

 

Here's a tiny thing that keeps infuriating me; I can't interact with the foldout of a scene in the hierarchy view unless I can see the root object of the scene? Example:

Can't collapse


Can collapse:

 

Speaking of collapsing a scene in the hierarchy view: I'm often annoyed when the scene is reloaded due to version control changes or what-have-you, that the hierarchy collapses the scene. Why? I'm not even using multi-scene editing. It's the only scene in the hierarchy; Why would I want it collapsed?

 

Is it possible to have two project windows open? ( I do this all the time with system folders )
If not please add to the feature requests

 

Why does Unity not give naming conventions? Everyone seems to e. g. name textures differently. The ones use "<name> a", others "<name> albedo", then "<name>_albedo", "<name> diffuse", "<name> Diffuse", etc.

This can be done outside of the scope of Unity itself, no engine change required.

Would be also interesting regarding asset store: I'd love to give a dedicated rating whether an asset sticks to conventions or not.

 

It is possible, just very unintuitive to do.

 

About conventions again: I tested several HDRP assets yesterday and it's quite noticable that every publisher has their own convention about how to store the HDRP unitypackage, where to extract it, etc.

It would be nice if Unity would provide at least a recommendation about how publishers should handle the situation, now that it's still fresh.

 

Procedural Art / Instancing / Mesher Tools -- (either suck or don't exist!)


Tools like these are pretty much a no-brainer for DOTS, but (especially with the advent of VR) basic, general-use, procedural meshing (and instancing) tools would benefit all users, whether they're artists, programmers, or designers.

For example, you guys are making a scatter system for your terrains/grass -- but why? Meshes need scatter systems too. And biomes. And snow accumulation. And trigger volumes. So, rather than killing yourselves making all these "special-cases" -- I urge you to TAKE IT A STEP FURTHER (yey CAPS!) and generalize the process (for everyone's sanity), then show them how it's done. You see the big "H" doing this right now with their "GameDev Toolset" -- and it is working very well for the few who know about it -- and aren't scared to use it.

Meshing/Instancing is a major part of the gamedev pipeline in general, yet it becomes critical when it comes to design-time workflows. Something like Vegetation Studio, for example, could be setup in 20 minutes (in a special secret software with an "H" in the name) -- with all the bells and whistles. Yet, you've currently got to rely on "in-and-out" authors of major and minor (sometimes incompatible) "assets" (assets that are merely called "tools" in a super-secret software) to fix your broken/buggy tool when you don't know all the complex math to do it yourself (the math which is typically only a very small part of the overall tool development process -- because, after all, many of the more complex tool workflows tie into shaders and texture-processing too.)

However, even BASIC support for meshing / instancing along a shape is not considered a workflow requirement in Unity.

Yet it is critical in even tiny mobile games...


Traditional approaches to special meshing/instancing tools require hard-to-learn mega-tools or heavy programming and math skills, yet despite all this, these approaches are rarely supported at runtime. Even the most basic access to procedural meshing/instancing routines or workflows require both a heavy monetary investment by the user as well as a very steep learning curve, yet basic meshing is what really provides the "magic" we see in the prettiest indie games.


@willgoldstone

I really think that you guys should consider focusing more in this area to inform your other workflows.

The mega-tools I speak of are a standard-but-relentless-and-unforgiving requirement for even the most basic designs, yet these kinds of workflows are still alien to most Unity developers. Unity should remedy this with its own toolset, yeah? -- Talk to me. I'll help you guys out in this area if you would like. This is kind of my "thing" -- and I enjoy it a lot.

 

I hopped back into a shader graph after a month of not monkeying with it.
In Blender you can rename nodes, and you can color them.
Be nice to see that in shader graph too.
Because I cant remember what anything does any more.

 

You may say I am a dreamer, but I'm not the only one, and if I can't have world peace, I would like to be able to select multiple fields at once by holding down ctrl + alt as I click fields to edit. (a la visual studio)

Actually, I believe ctrl + click is more standard, but whatever, as far as I can tell, any combination of ctrl and/or alt and/or shift does not do it.

 

+1 for inbuilt Optimisation:

Mesh baking, material combining, LOD auto-generating (partner with Simplygon).

All of this stuff is standard in Unreal. The asset store assets for all this with Unity are not user-friendly or reliable. Simplygon is only unofficially supported thanks to an old 5.6-era unitypackage.

I'd be fine if these were 'power tools' for Plus/Pro users.

 

Another huge one..

More flexible sub-assets

Why is it that I need to write a bunch of custom editor code to create a sub-asset? I reckon it should be possible to drag and drop sub-assets freely, parenting them at will. The editor is written to encourage the use of assets (aka ScriptableObjects) to represent game data and edit it in the editor. However it can quickly lead to an explosion of assets (read: complete and utter mess) if you have highly reusable systems. For example

In our game, we have monsters where each limb of the monster is separated into a different spritesheet. If we embraced assets, each limb would be comprised of the following assets

• Limb asset itself
• Spritesheet asset (spritesheets as first-class citizen, allows getting a sprite at x,y and other such things. Because, Unity does not know anything about spritesheets at runtime, but truthfully nobody wants to manually assign a bunch of sprites every time)
  
• Indexing asset (configures the layout of the spritesheet by assigning meaningful names to each column, to be used for animation at runtime)

If we simply had assets for each of these, we would have too many assets in the project and the result is that various editor functionalities like searching and whatnot would be clogged up. Indeed, we would not use these spritesheet assets directly without the limb itself, nor the indexing asset either. The project view would be hell to navigate as well because the folders would contain a bunch of superfluous assets as well. The sub-asset system would be an ideal solution to this, because we could expand the asset whenever required.

Sadly, the APIs to use sub-assets requires custom editor code each time you would like to use it, so we haven't. Instead, we have several standalone non-scriptableobject classes which each have a wrapper SO. It's convoluted and complexifies code greatly, of course.

 

The problem with quick and easy nesting of subassets is references. The way Unity references a normal ScriptableObject is through GUID of the SO. The way Unity references a nested ScriptableObject (or any nested object) is through the GUID of the parent file and the FileID of the SO inside the file.

This means that if you could drag-and-drop a SO to make it a child asset, you'd get one of two results:
1: You lose all references to the moved SO.
2: Unity would have to find all references to the moved SO, and update those.

2 would be ideal, but Unity doesn't have that kind of capability. That's actually another major workflow pain in itself - that we can find dependencies of an asset, but we can't find which files depends on that same asset.


There's for sure a lot of things that should be made smoother with sub assets that won't cause major issues. A big one would be enabling us to click it and press delete to delete it. There's also a bunch of bugs around sub assets that have been closed with "by design" or "won't fix" that are causing issues.

 

In the curve editor, keyboard workflow is next to none. If I just want to do quick tweaks to the values, it's very irritating having to carefully click on the keyframes. I often accidentally move keyframes as I try to select them, or even the entire curve up and down. Please add TAB/SHIFT-TAB to cycle to the next or previous keyframe in the relevant curve. If no keyframe is selected, TAB should select the first and SHIFT-TAB the last.

 

Need some kind of project view hotclick+key to look at a texture without selecting it. Like a right click + ctrl or double right click or something. One that will not select it, just let me peek at it like ctrl+left click does in a material's inspector tab. Also, just for textures in the inspector tab. That's right, for some reason, I can not get a closer look at a texture in inspector, I have to view it with ctrl+LMBt click through the material inspector. It would be nice to peek at materials as well.

And when looking at these textures, I want info. I want size and maybe even memory size. But definitely dimension. I'd also like to know if it is normal or not, and if it has alpha. Sometimes, when I view them with ctrl+left click, I see this info. Right now, I am not seeing it.

Current texture workflow looks a bit like this:

Spoiler

Modifying a material, want to switch out textures.
Little teeny tiny icons, textures are mass generic named from some asset.
No way to look at it without losing my place.
Now I can look at the texture by ctrl+clicking (extra step)
And now... where was that material again. Lets scroll through and find it.
Now where was that texture? Let's scroll back down and grab it to place it in the..
Oh crud... I hesitated, and instead of click + drag I clicked.
Now, where was that material? There, select.
Now, back to the texture, I remember it was about 32% down my giant asset list in project view... or was it 35% ? There it is, grab it, place in box. good.
Now left + ctrl to look at texture...
Nope, that wasn't the one I was looking for.
Alright... now which teeny tiny icon looks most like the texture I am looking for this time, that last one wasn't it.

Ctrl+left click without selecting it would be somewhat ideal*, since it would match the material inspector texture peek function, but I don't know if left click is deeply ingrained in the project view or even editor as "select".



*(actually, I think ctrl+right click would be more intuitive in both material inspector and project view for textures, since right click is generally the mouse button reserved for looking at things without changing or selecting them. perhaps it could be done as a secondary way to peek at the texture in material inspector, so people could start using it).

 

I believe the snap only works on X or Y, but not both. At least that is the way it is in the animation curve editor. Be nice if snap meant snap on X and Y. very annoying to snap precision to the X, only to have the Y drift .02.

 

Shadergraph workflow:

Perhaps it is personal preference from using Blender's shader nodes for so long, but I find it a tad annoying when I unplug a socket it asks me what kind of node I want to make. That extra half second to second waiting for the dialogue window just makes it not worth it.

I just think it is very, very rare for anybody to want to make a new node when unplugging.
Most of the time, they just want to unplug, and not be asked what New node they want to make.
And maybe people would incorporate the drag string to blank space to make new node... IF... it didn't take a half-second to a second for the dialogue window to appear, but I really think NOBODY wants that dialogue window when they are simply unplugging.

Be nice to cut strings by left click drag and holding down ctrl to just slice across connections.

Also this:
https://forum.unity.com/threads/workflow-case-study-show-us-your-pain.637552/page-5#post-5552911
Would be very nice in shader graph as well. Mutli-field simultaneous editing.


And...
super node minimize. Where the node is made very small, just showing name, with its sockets display but no labels. The current node minimize hardly does anything, making the node trees take up tons of screen real estate very quickly.

 

Another project view annoyance:

Search for a texture, say type in grass.
Ahh, 12 different grass textures pop up.

Some people keep all their textures in one folder. I do not. I don't feel like justifying why I do not, I just don't. Nor do I keep all my materials in one folder, or scripts, just to drive some pros crazy with the need to tell me I am doing it wrong.

Anyways. I don't think it should matter. Because when you click on one of the assets that come up in the search, even if it was not the one you were looking for... just to look at it and see if it was the one you were looking for, it explodes your entire folder hierarchy to get down to that one asset. If you check ten of them, when you finally leave the search, your file tree is exploded all over the place, and you have to go through and close a bunch of file trees.

Ctrl+RMB or ctrl+LMB (Again I think ctrl+ right click would be more intuitive, since standard is right click is information), should only show it in the inspector, but not explode your file tree for it.

I think double-LMB should select the asset you were looking for, and close the search window.
Right now it opens the asset in a third party editor or IDE. I could have sworn most people would right click and select "open with" for that. If not double LMB, just LMB, with ctrl+RMB or ctrl+LMB to "peek in inspector".

It seems so weird to me you click on it, then close the search to get to it. Plus that's and extra 0.3 - 1.2 seconds to aim and hit that tiny x on the right of the search bar, depending on your no-scope skillz. All this stuff adds up.

 

auto-name children after their parents, ie if you have a button to your "units panel", the button should be auto-named "units panel button", (and of course, if you start typing, you can name it whatever you want, see first suggestion).

first suggestion from this post was to have a newly created object be ready to be named like scripts currently do. ie create object, start typing name.

 

3 editor extensions I made and import to every project

• Configurable sound effect that plays in reaction to

  OnScriptReload

  e.g. after compilation, I set a gentle little chime sfx that I found laying around in Windows 10.
  
• Menu item that toggles the play state of the game, so I can toggle between editor/play mode with a single key.
• Menu item that restarts the game and does an asset refresh in-between. So if I'm mid game, I can press F5 to automatically exit out of play mode, recompile changes, and instantly start the game again after. If the game isn't running, then it does an asset refresh and starts after. This has become an integral tool to my workflow, I use it probably a hundred time each day.

 

The Hierarchy
needs a BIG revisit in 2020, where to begin...

First, I saw that hierarchy folders are coming in 2020. This is absolutely great news. I would highly suggest that those do not expand like regular objects and not push the hierarchy forward to the right. The background could simply be a little darker to indicate that they are inside the folder above. This will help create a distinction between organization and the 3D transform hierarchy.

A BIG problem right now for map designers is that the hierarchy requires a LOT of upkeeping. The first issue is that objects end up in pretty much arbitrary positions when they are newly created. (both in the world and the hierarchy) A map designer has to constantly move objects around in the hierarchy, severely hindering their creativity and productivity.

I believe I have the perfect solution. First, we need the ability to set folders or objects as a persistent destination for newly created objects. A right-click option would be too slow and cumbersome. Instead I suggest a new hierarchy mode where it acts as a way to pick 'contexts' to work in. Selecting anything in that hierarchy would simply set the editing 'context' where new objects would be moved to. Objects that are outside of this context (folder or parent object) can optionally be unselectable in the scene and rendered greyed out, with low opacity, or simply hidden. You could call this 'Layer Mode'.

Lastly, it would be great if folders had support for automatic sorting of objects.

Aside from folders, I think we just need a way to better visualize our objects. Some components should be allowed to override the prefab/notprefab icon to the left of the name (white/blue box). For example objects with a Light component should show a lightbulb instead, the name could still be blue if it's a prefab. Postprocessing could have the postprocess rgb wheel icon, etc.

 

How about just a blue lightbulb for a prefab instead of i.e. a white or clear one? -- And a blue cogwheel vs. white or clear one.

One of the biggest issues with fiddling with the hierarchy is the fact that the work you're doing in it is rarely the work that you need to do in the scene view itself.
You're mainly just selecting gameobjects (and their visibility/interactability), shifting around their positions in a hierarchy that acts like a group (since there are no real "collection/grouping" concepts), or adding/removing things in the world (which I would argue that this should be done via drag/drop into the scene itself -- not into the hierarchy -- which would just put the object at 0,0,0 of the active scene's origin if dropped into the hierarchy.)

Aside from collections/grouping concepts, double-click to open up an inspector tab (see multi-inspector workflow) would make the most difference here as far as usability, but beyond that, to be able to hold a key (shift/alt/ctrl) and double-click and/or right-click to execute a different function (or open a different menu/popup) right in the Hierarchy would be amazing too...
Just imagine how useful this would be when we start making procedural art/geometry in Unity...

Overall, my thoughts are this:

The hierarchy's purpose should be as "a hub for navigating and performing actions on one or more gameobjects/entities."

 

One of my biggest gripes is selection in scene view when there's a screen space overlay UI.
The UI is always selected and I end up having to click 5 times in order to drill down to what I actually want to select.
Click too fast and your selection moves through the hierarchy back to the UI. Click to slow and the selection never moves through hierarchy.

It's really frustrating sometimes.

I end up having to always disable the UI gameObject, select the 3d object I want, re-enable UI gameObject. So unbelievably tedious.

I would vote for some selection popup if multiple objects exist at the point I'm clicking
Or.. don't allow selecting UI objects unless the mouse cursor is actually over the UI sprite, not just rectTransform bounds.

 

Two things we do to fix that right now that might be useful to you
- We have a [MenuOption] with a bound shortcut that toggles visibility layers. So if you hit ctrl+U, you can only see the UI layer. Hit it again, you can see all the other layers, but not the UI.
- This tool allows you to right-click and get a list of all the things under the mouse.

 

Totally forgot Unity has a selection mask now in hierarchy, which does actually help a lot.
Although might still be an issue if your UI is instantiated or loaded in additive?



But would still be awesome if UI selection was image based.

 

The very fact that a "Layers" system doesn't (officially) exist in Unity with the sole purpose to separate global things such as UI and in-scene gameobjects definitely irks me as well. The fact that one has to write their own system to show/hide global groups of things (that are usually already tagged / indicated in the Layer bitmask) is incredibly off-putting to most anyone except programmers with an ego problem.

I know a new "Collections" system is coming, but really, when I don't need that kind of granular control (i.e. in the case of UI elements I need to hide while editing my scene), there should also be an (additional!) "global" menu / panel / shortcut / popup someplace that lets you show/hide certain KINDS of (defautl/layer/tagged) things (i.e. UI, water, etc.) -- The tag system will pretty much become redundant one ECS takes over, right? So why not make it useful for sorting/displaying all manners of default / global things in the Editor and let "Collections" take care of the rest of the (granular) sorting, yeah?


Why not assign this task to the Scene Visualization team to sort out -- Seems like it's right up their alley!
Wait -- I'm not sure Unity even has a team like that. Maybe I'm wrong.
Gawd. Please let me be wrong. D:

 

@awesomedata

Is this what you mean?

https://github.com/Unity-Technologies/com.unity.selection-groups

 

Not quite -- That's the Blender-like "Collections" mechanism, which is cool and useful, but it still takes time out of my day to set these groups up when that setup part isn't strictly necessary -- and in most cases, it also duplicates work.

The main idea is that the user should not have to select anything that's already tagged in some way.


All gameobjects already tagged "UI" or "Water" or "Environment" for other purposes, should be automatically taken into account and made into a group automatically (maybe with an option to show/hide these automatic groups) so you don't have to do any clicking/dragging/selecting of individual groups. Since you've already "tagged" your gameobjects in some way or another (i.e. with the standard Layers bitmask or special tags), why manually group them? The grouping should already be done for you automatically.
That being said, this selection tool could be useful for that -- it just needs to take the tagged gameobjects or Layers into account and auto-populate them when the window is opened (depending on your preferences maybe).

Just seems like the "Layers" and "Tags" concepts should have always been a part of this kind of feature.

 

Also -- Objects in scene disappear when I zoom in is a great thread to introduce new users to Unity workflow quirks!


@RANDOM++ has totally made some new(b) friends over the years.

 

There is a pain point for me in regards to the SpriteAtlas asset. It is only possible to include things in it, but no way to then exclude some. Our artist wants to work as it is convenient for him - to keep related things together mainly. But some things just don't belong in the atlas (or belong in a different one), so I have to ask him to move things around. To exclude a folder you either have to keep it separate, or remove the parent folder from Objects for Packing altogether and include its sibling folders manually (always keeping track of new folders appearing). With deeper hierarchy it becomes unmaintainable.

There needs to be a way to exclude things. It could be the same interface as Objects for Packing, though a regexp would be nice as well. I suppose I could write an editor script to include only the needed objects programmatically. If such a solution already exists, please share it.

 

@willgoldstone @Aras

In response to your twitter question about Scene Handles and Gizmos:

• https://twitter.com/willgoldstone/status/1248278216206360577
• https://aras-p.info/blog/2020/04/11/Various-details-about-Handles/

An annoyance for me is that duplicating an object selection randomly changes the position of the Move Tool handle.

I often select several objects, duplicate them and move to a new position. Because the Move Tool position changes randomly after having duplicated the selection, it's always a "where is the move tool now" search going on.

This behavior causes that I can't immediately move the duplicated objects to a new position, because the Move Tool isn't located at the same position where the mouse pointer is currently located, so I need to move the mouse to the new position. It's a "tiny" issue that got annoying really fast.

I recorded a video that shows what I mean. Notice the Move Tool handle jumps to a random position after I duplicated the selection.

It would be much nicer to work with, if the Move Tool position stays the same after having duplicated the object selection.

EDIT: This behavior has been turned into a proper bug-report:
https://issuetracker.unity3d.com/is...cts-when-tool-handle-position-is-set-to-pivot

 

That reminds me, the compass rose control widget is terrible. If you rotate about the x axis in editor view (usually indicates desire to see top down view, going from from "first person" to "top down"), right as you get close to looking straight down, (say you want to do a map view), that is when the little green "y" handle on the compass rose gadget disappears, which is right when you need it, so you can click it to get a perfect top down view.

The little Y gadget disappears to make another function available on the compass rose, which is click in center and it switches from isometric to perspective. Which is nice and all, it is just that exact same function is literally 90 or so pixels below the compass rose as well, so removing one of the x,y,or z control widgets just to switch from isometric to perspective, when clicking on the <per and =iso texts below does the exact same thing... is really asinine.

In Blender they recognize this as essential enough to warrant a hotkey system. Yet in unity, it is ridiculously difficult to get a perfect top down view, unless you click on the y gadget quite early, but that is not how most people look at their maps. They usually slant up and away, then decide they need perfect top down view.

 

I can't believe all this effort was and is put into the UI, yet still no simple way to tell UI to block raycasts.

 

Not that it is perfect, but the Autodesk Cube (which possibly inspired the initial feature) is much better.

 

Can we hope that after so many years we can have a default feature that sets a Normal map as a Normal map during import?

No need to re-invent the wheel. just use a standardized texture file suffix to recognize them... (i.e. _normal ) btw I know you can do it by creating a preset, but it should be the default behavior. Not just for those who happen to figure it out.

Also there are many ways you could help us create a material very fast in the same way. i.e. when I use a certain texture in my material, i.e. "button_base color.png" Unity picks up the accompanying bitmaps for the material in the relevant slots.. .i.e. Unity automatically assigns the "button_mask.png", "button_normal.png" etc. in the relevant slots.

 

What are the most used things in Unity? Thats basically the core thread, atleast on pages 3&4
For me, it goes like this:
Change some code -> switch to unity -> compile -> start the game ->
Shoot at an enemy -> enemy takes no damage ->
check the layermask on the player -> layermask is ok -> check enemy layer -> enemy layer is ok ->
console ok -> open physic settings -> physic collision matrix not ok.
Out of playmode, change collision matrix, start the game ->
shoot at enemy -> NullReferenceException -> some variable is not set, a ScriptableObject ->
Exit Play Mode -> locate the ScriptableObject -> clicked on some Folders, the Enemy is no longer selected but I have found the missing SO -> click on the enemy -> drag the SO into the field -> start the game ...

Breakdown of the operations: switching from and to play mode, opening various menus and inspectors, drag&drop over wide distances, while losing the inspector by just navigating the project window, ... theres lots of room for improvement and that was only one very small straightforward bugfix, not talking about leveldesign, animations or anything more complex here.

 

I realize that my previous post was more of a rant so here is hopefully some actionable feedback.

Multi-Inspector Comparison Workflow
I think the properties panel is a great first step! I would love to have a mechanic that highlighted differences to the designer in regards to what is different between similar data objects. Similar to the way that prefabs mark the fields that are different from the base prefab to highlight differences between scriptable object data.

Better 2D Sprite Mesh Generation
Lately, I'm running into situations where I want to use the 2D tight mesh system, but the sprite mesh that is generated is extremely sub-optimal in terms of vert count. The idea is that we're cutting down on fill rate, but if I need to represent the sprite with hundreds/thousands of verts that's not great either. We need a better tight sprite algorithm and let me manually create the tight mesh in the sprite editor when the algorithm fails.

Asset Usage Search
I feel asset management inside Unity is very poor. The most common question is something like "Where is this texture used" so I can verify an update looks right after changes. I can do a search in code and usually find references to hard-coded assets. However, assets that are linked in the editor is not easily searchable. Find references in scene was a start, but it's not good enough. I'm not going to tell designers/artists to open all 100 scenes in game and do a search. I've used and written tools that will manually search through all of the .prefab XAML and find GUID references. This should be built into Unity. If I am going to replace a texture, data, localization, mesh, whatever asset in the hierarchy. I want to know the ramifications of this action before I replace/delete it. I'm thinking this stuff would be updated/maintained in the asset database. Not manually doing text searches for GUIDs in the text files. However, if a GUID search is the best way, at least give us an option in the editor do so easily without needing to write a tool.

Asset Quality Workflow
Unity is a multi-platform engine that allows you to build a game that targets all sorts of hardware from low-end mobile up to high-end gaming PCs. As such I want a dynamic way to load specific asset quality levels depending on quality setting. I had high hopes for Addressables in regards to this, but it has let me down. Basically, I want a way to reference assets in a way that loads a specified sub-asset depending on the quality level. This is related to the quality levels presets, but with much better fine-grained control. I want to define what a asset means at low quality, medium quality, high quality. This applies to any and all sorts of assets including Materials, Textures, Meshes, etc. Currently, the best way to do this is to build prefabs of different quality objects and load the appropriate quality at runtime. This isn't very designer/artist friendly. They want to visually work in scenes and they don't want to update/maintain 3x the prefabs due to quality level. Unity should make an asset quality reference for all of the major asset types and allow you to setup what the asset means at differing quality levels. Then let you drag and drop these asset quality references into the normal slots on a material/mesh renderer/etc. Then the engine will automatically load the appropriate asset quality depending on specified quality settings. When you make builds you can define which asset levels are supported on the platform. Immediate stripping of the high-end assets on platforms that don't support those assets. Common examples are Texture/Mesh/Shader quality settings on PC or texture compression settings on mobile.

 

When creating a new Script from the "Add Component" Button in the inspector, let me select a folder. I must have spent days already, dragging those scripts from Assets/ to Assets/Classes/Testing/.


Enable the mouseWheel while dragging, moving the mouse to very top while dragging an item and waiting for the slow autoscroll to bring me to the folder or hierarchy object is a huge pain.

Add alternatives to dragging something like hover Copy&Paste, in the new UI, every field thats hovered is highlighted, so it would be cool to copy&paste values, Objects (GameObjects, Textures, Scripts, ...) based on hover.
Hover over the Texture -> CTRL+C -> hover over Material Inspector Base Map Field -> CTRL+V. Same for files inside the Project Window.


Show the full name + path in object picker menu on hover. Selecting each single item just to see if it is the right one in the correct folder (especially for animations, animation controllers and scriptableObjects with the same name) is quite time consuming.

Also for all those views - a combination of thumbnail/preview image + full name&folder (list style) should be added --> MockUp:

 

No.

The best example would be 3ds max Object Placement Tool.

 

I see. I completely misunderstood. Thanks for clarifying!

 

Designer Problems w/ Claustrophobic Editor





First -- some important clarification about the image above:


I don't mean to say I don't work with the inspector (or the other windows/panels) almost constantly. What I mean to say is that everything I do with the inspector/hierarchy/toolpanels/etc. funnels down to something actually happening in that central (orange) area. The overall "design" of the Unity Editor ignores this fact.

In other words...
When you change anything in the Inspector (for example), something in the Scene almost always changes with it.
You change a transform, something in the scene view is visibly transformed.
You select something, something should visibly-indicate that selection in the scene view.
Everything you do in the Unity Editor boils down to a visible change in some central area.
Even if you're just editing a player's stats in the inspector, you likely have other player or character-related information nearby, meaning that inspector is now the "central area" you're working in.
The overall design (including the proposed design) of the Unity Editor does NOT take a "central area" into account.

The problem (in my particular case) is:

I get maybe 1/3 of the screen to actually design my game.
...
The rest of the screen real-estate is wasted.
I spend most of my day toggling windows, project hierarchies, or other addons JUST to get a better look at what is actually going on in that (tiny) little area (highlighted in orange). And then I have to swap back-and-forth with the game view! This annoys me so much that I rewrote the scene camera from the ground up (Snapcam in my signature) so that I can spend more time navigating my Scene View to place assets (and less time fiddling w/abstract gameobjects in a list.)
But this isn't enough.

I still have a very hard time feeling a sense of "flow" in Unity.

This is mostly due to the super-tiny central area.
"Get a bigger monitor" isn't an option for me. First off, not everybody can afford to develop games across 3-4 huge monitors (and Unity isn't very multi-monitor friendly anyway), but beyond that, I'm pretty mobile, and not everybody can lug around an extra monitor (especially people on the go like me), so this is a huge problem.
There was a time I thought the new 2020 mockup "Workspaces" could solve my issue, but the more I thought about the problem, the more I realized this needs to be addressed in the editor's UI design itself.




Designer Workflow Proposal






Above is my proposed solution to fix my workflow and UX issues in an elegant (and highly-ergonomic) way.

The major features of my mockup (above) include a central viewport made possible by a dropdown-button / popover-style workflow (with respective pop-over/dropdown shortcuts for both Project and Hierarchy views to appear instantly).

The Hierarchy dropdown button exists in the SceneView mostly because its "proximity to the action" tells the user "This UI element is an immediate concern." If your mouse is in the SceneView, you likely need the Hierarchy.
The Project/Library buttons (in contrast) are also in a very central and prominent location, but still a little "outside the action". Their placement tells the user that "These options are important, but they are secondary to the action."
This is an important distinction because the project view can quickly appear in a central location to allow you to drop anything from it to anywhere in your scene, hierarchy or inspectors. This view remembers its position/state when hidden/shown, and disappears instantly, when the user is away from it for a certain (configurable) length of time. To call it back, just use a single key to pop open the tab you want (Asset Picker tab, Project View tab, Favorites tab, etc.)
Just an idea, but I would suggest giving the option to swap the "Project View" to a "Picker Panel" mode (with a particular shortcut) to let designers quickly pick from (or group select) a list of prefabs they want to use (i.e. for placing in a level, or for Polybrush sample for scattering, or for general use in other addons, such as level-generation assets). Users shouldn't have to constantly search through every asset they have (for one asset at a time, when sometimes they want an entire group!) They could right-click on a folder in the Project view and do something like "Set as (or "Append to") Asset Picker Palette" to let users visually set up palettes of textures, shaders, materials, gameobjects, or even scripts. Such generally-useful functionality has to be rebuilt for every single tool we build. Like the new spline tool -- Why not make it native? -- Assets will no longer have to work around each other for groups of assets like this. Not to mention these Asset Picker Palettes could also be good for DOTS conversion workflows...

Also...

1. "Tools" should exist in "Toolsets" -- And both need an Inspector.

The workflow for visualization (and use) of tools and assets is the Wild West right now. In terms of assets on the AssetStore, there is no consistency at all. So (like the Asset Picker Palette), I've introduced the concept of a "Toolset" which would also include Toolset-specific "Shortcut Mappings". Since there can only be a single Toolset open at a time, shorcuts would be associated (and activated) with the active Toolset selection. The Toolset's list of Tools, which could include tools that generate Gizmos in the scene that need their own complex (customizable) control maps (think VR or simple joystick input to move and place objects in the world more easily). These tools may need more complex input scenarios than could be easily-integrated into the Shortcut Manager, but I feel like the Shortcut Manager could allow one to write custom OnGUI or OnKeyboardPress, etc lists of events right there in a centralized location. This would be so beautiful -- especially if it were available to pull from at runtime.

More complex (i.e. level-generation tools) would require less of a scene-based workflow, and more of an inspector-like workflow instead. The active scene-based tools (like painting terrain) have a special in-scene "Inspector" area like that mockup, but some tools could opt-in to have their own inspector when the tool is selected (i.e. select the MapMagic Toolset, and the Toolset has its own global controls in an always-available "Toolset Inspector" hidden behind the main inspector. Press something like "X" to swap between these two inspectors like swapping between colors in Photoshop or something. You should be able to add multiple sub-levels of "tabs" to the inspector in case you have many types of global controls. Lastly, you should have the ability to swap between multiple toolsets instantly at the press of a button (i.e. 1,2,3 are your LevelGeneratorAssetToolset, PostProcessingAssetToolset, MassiveCloudsToolset respectively) so that you can swap around your top 10 Toolsets (for the current Workspace) instantly via your number keys.

Native support for this would bring some (much-needed!) cohesion to how tools (large and small) are written & used!​

2. Game/Scene "View-Swap" Mechanism

The ability to instantly show/hide (and swap between) differently-sized GameView and SceneViews.

Rarely does anyone need both Game and Scene windows to stay exactly the same size ALL the time. More often than not, we switch between them because we need one or the other to be set as our main viewport temporarily so that we can glance at a larger version of a tiny window. Then we need it to return the large window to its former (tiny) state.

This drives me nuts!

This is a constant headache for designers. Fiddling with two separate windows can be a special kind of hell on a screen with a low resolution (with no room to dock the tiny game view) and only a touchpad (when you need to quickly see it big again). Sometimes you're just not ready to go into Play mode (and hate fiddling with the Maximize on Play on a tiny touchpad) when you simply want to see what your camera sees.


So in that mockup edit, I've made a little button that sits squarely out the way in the SceneView and instantly pops up into a tiny GameView (that can be resized with a single click if you need it larger or smaller temporarily). While the window is open, you can MIDDLE-mouse click in it (for mouse-only users) or hold SHIFT and click in it (or right-click on the small window or button to get a pop-up menu) letting you swap game/scene views between the large/small views on your screen. This essentially does nothing more than swaps drawing the SceneView in the large (main window) to drawing the SceneView in the (tiny) window/popup, then draws the GameView as the main (SceneView) window temporarily, giving it keyboard/joystick/whateverinput focus so you can quickly test your gameplay while also looking at the tiny SceneView in a larger GameView window. You can swap these back the same way -- middle-click or shift-click on the smaller window/button in the SceneView/GameView to return to normal. This frees you from endless fiddling with window sizes, keeping the pretty layout you worked so hard on both nice (and in-tact) on your tiny screen.​

Final Words on "Flow" in Unity

The most important part of my edits is that, because you are NEVER forced to have to leave the SceneView editing context while building your worlds, you can actually ACHIEVE an ideal state of "flow" in Unity!!

@willgoldstone -- You have no idea how important this is to designers.
All your tools are right at your fingertips, including your shortcuts, and no swapping around fiddly windows while testing your game EVER AGAIN. Those sub-tabs under the Project/Library dropdown could easily be changed for other types of workspaces. For example, for a "Programming" workspace, instead of "Layers", you have the EntityDebugger replacing that Layers icon, which activates its own EntityDebuggin "Toolset", which sets a default Active Tool, Active Tool Inspector, and Active Toolset Inspector (for global EntityDebuggin info), allowing you to continue to work in the SceneView (or some other central view), even as a programmer.

Yes -- This new UI design is very robust.
And yes, I wish you guys would consider making our lives easier with this workflow proposal.

I want true "flow" in Unity....

 

@awesomedata your attachments don't load for me

 

now they do load, The design looks good, Did you ever work in Maya?
there you press space to switch between full scene view to other views very quickly and you have the Hotbox

you can see in this video

The good thing is you can work in a fullscreen view and still have access to all your tools

And Maya also has a kind of workspaces system with workspace for each task.
Maya also has camera view bookmarks
It has gestures and modifiers for many operations
And all the tools have Wacom pressure support

Many things that I miss in unity are already well done in Maya for a long time.

 

This tool also has some of the ideas

https://assetstore.unity.com/packages/tools/utilities/ucontext-141831

 

I did use Maya years ago, and yeah, that was a neat feature.
Sadly, it was just about the only "innovative" feature I can remember from them...

This is definitely a plus. -- And while I'm not a huge fan of most "quick selection" methods (as they all seem to aim to be "everything at once"), when they are combined with a clear purpose, large/clear icons, and a clear, intuitive, and satisfying way to access them, my opinion can be swayed.

That uContext tool does look pretty useful, but it too seems to aim at being "everything at once", which is not always a good thing (especially from a design perspective.) Important things (mostly subtle) get lost in translation.
Nonetheless, thanks for pointing this tool out. Even though it's design is a bit rough, it definitely looks miles better than what we've got in Unity now. At least it's possible to work entirely in the Scene View with something like that.


I do wish Unity would take into account the Toolset/Shortcuts, Game/SceneView switching stuff I mentioned above too. We'd be well on our way to a 90% cleaner interface that affords "flow" to artists -- and in an aesthetically-pleasing way -- all without having to have Unity "be everything at once" -- which it currently seems to be having trouble doing right now.

 

@awesomedata

You made a very nice presentation of your ideas and you put good effort to that direction bringing interesting suggestions. I think it is not as bad as you say it is though, even on 15 inch laptop monitors. I find the screen swap mechanism really great and almost flawless especially with the new, much faster "Play" experience.

There are many ways to increase the Scene view surface area and I usually work with almost double what you show (the default) by shrinking the hierarchy panel to the minimum possible, but in any way, if you feel this way, and you are not happy with reducing the size of the surrounding panels, that is how it is for you.

This is my arrangement, as you see the Scene view is significantly larger.



Having said that, I agree that there are ways that could improve the editor UI (i.e. more floating panels) and that is more than just icons. imo, the solution Ludiq came up with (peek), while it doesn't suit everyone, would be great for most people that feel they need more surface area for the Scene view and a more modular, reactive/dynamic, UI approach.

I work with 3dsmax and such workflow is very familiar.
Working in Expert mode with quad menus, caddies, and the modifier search is very similar to that.

You mentioned Flow,
while you do have a point, flow has to do with many more things than just the UI. Familiarity, mentality, location, lighting, ability to focus despite various workspace disturbances, internet distractions, your own hardware, etc. I work frequently between 3dsmax, Substance and Unity and I find myself in "flow" most of the time and that is not thanks to the "add-on" tools which sadly make things a bit more complicated than simply exporting what needs to be updated.