Official Overlays Public Build Available

@neil_devine -- I've got a couple of questions about window context:

I know this seems to be unrelated to overlays at first, but I've noticed that when moving the SceneView camera, and wanting to slow it down, I cannot speed-up or slow-down the camera movement (in Flythrough mode) with the mousewheel when I'm outside of the scene view (i.e. hovering over the Inspector).

I'm sure this was "not a bug", but a "feature" in the past -- but I think that kind of thinking must change if Unity is going to be successful. It is particularly painful when rotating the camera (while moving with WASD, for example), and wanting to slow the camera down at the same time. The camera itself, for example, cannot be overridden or remade (or repurposed for 2d-like behavior, for example) in editor tools because it is a multi-context utility (i.e. Flythrough mode has special input mechanisms that aren't consistent with the rest of Unity's controls or workspaces -- and acts more as a "Tool" than a UI feature).
I'll call this multi-context 'utility' an "MCU" in the future, as these are very prevalent (and unorganized) in Unity, and there are no standards for handling these as it stands (much less the terminology to even talk about them).


This leads me to my questions:

1. How are you planning on handling multi-context 'utilities' (such as shortcuts) for Overlays in the future?
   
   
2. Are shortcuts (such as the mousewheel in the situation mentioned above) going to stay the same (global) context, or are they going to be window-based?
   
   
3. If the answer to 2 is window-based, can there _please_ PLEASE be an option to tie them to a Toolbox, Toolbar, and also Workspace context instead?
   
   (I ask 3 because trying to execute more "global" events -- such as when making artist tools -- gives me so much trouble when needing to handle keys/mouse/etc. input that only needs to happen when a specific tool or mode is active -- especially when that tool or mode is NOT localized to any particular UI element or window.)

This is also a problem with more global "events" in the Editor when scripting.

For example, I've spent probably 3 years trying to find documentation on how to execute a more global "event" structure in Unity (without using UnityEvents) for editor code that is not tied to an EditorWindow, CustomEditor, or really any local UI "structure" whatsoever. -- I FINALLY figured out how to do this just today in fact, without any reflection or special tools in fact. However, this is kind of fundamental to more "freeform" artist tooling that needs to be untethered from the UI, including the window context.


To further my point above:

Using Snapcam as an example of a tool that has a mostly "context-less" approach, I have stumbled into issue after issue with referencing between systems that do not use the inspector (or scriptable objects) to store their data / operations. I imagine this to be an issue for _many_ different kinds of tools that don't work directly in the scene view, leading to heavy issues with keyboard shortcuts and other "shortcut-driven" workflows that swap context at will -- including interdependent tools / windows (such as the SnapNavigator and the GridNavigator -- which required an architectural change under the hood simply because data didn't exist for the window when the window was closed, as the EditorWindow container was being stored away for reuse later).
As a further example of the "window" situation "getting in the way" of tool development -- I had a user try to use the GridNavigator window (which can act in dual functionality as a temporary popup -- and as a window that can be docked as well so the user can have a "grid" view of his "snaps" -- rather than the standard "slider" approach in the SnapNavigator window) Both windows, respectively, can be hidden at the press of the "S" and "G" keys, but when hiding the Grid Navigator window that is "docked" threw an error at one time (and the bug in Unity was never resolved).

All in all, my current problems are "solved" at the moment, but I heavily urge you to consider my feedback in how you are engineering things. I am one of those users that "push" your technology to their limits, and I do crazy, unexpected things with your UI -- and the solutions I've proposed previously (i.e. the Workspace, Toolbox, Tool contexts rather than _just_ the SceneView and EditorWindow / CustomEditor contexts) should be heavily considered, as then truly Multi-Context Toolsets (i.e. like Snapcam) will become more manageable -- but more importantly, better (easier to use and more flexible) artist / environment / gameplay / bookkeeping and utility tools can be (more easily) created -- and these types of (very badly needed) tools will suddenly become more prevalent than just another broken (too complex to maintain -- and eventually deprecated) Editor Tool or super-tiny custom editor for x, y, or z specific use-cases.

With a more "MCU" approach to standardizing tools and workspaces (alongside the Workspace/Toolbox/Toolbar contexts, which keep shortcuts/gizmos from being used _everywhere_ at any point in time, while also remaining extremely flexible to user-customizations and usage scenarios), tools will last much longer (which is better for both developers and the AS, as well as the users) -- and be 'less-broken' after updating Unity too (which is just better for everyone).

Hopefully this feedback was easy enough to understand -- and productive as well.

 

I expected this to be included now in the 2021.1 beta. how sad it will take so long to arrive

 

I think it looks great. I'm sure there's some people out there that might want to create their own custom overlays or even customize the current overlays (different colors, icons, combine into a single overlay, etc).

For me, this looks great!

PS: looking forward to ProGrids coming back out of Preview.

 

This is going to be a huge problem for me.

There are plenty of times when I don't want my Overlay structure to be attached to a particular window's data structure (i.e. when the Window is closed for example). This is the case with my Snap tools. For example, I have two windows (a Snap and a Grid navigator that both use "Snap" data). I tend to need access to some Snap window data, yet it is unavailable to me in other contexts -- such as in the Grid Navigator window, which provides an alternative workflow for accessing and using Snaps. Without the common "Workspace" or "Toolbox" contexts, this multi-window architecture I'm fighting for is unsustainable, especially when my data is multi-purpose and NOT simplistic and entirely contextual -- which you will find in MOST really badass artist tools.
For a great example of a tool you might find in an Overlay, how about how Blender uses its cloth-sim system in its sculpting brushes in useful and creative ways? This kind of overlay architecture is necessary, (so necessary that they rebuilt Blender 2.8 from the ground up because of this), and not being entirely "window-based" is critical for multi-purpose overlays toolchains and pipelines to have access to (somewhat) non-specific contexts for more globalized tool operations (like Flythrough or Pan modes for the SceneView camera), which is what the "Workspace" concept is intended to solve -- by providing a new 'global' context that's less-specific than "SceneView" or "EditorWindow").

If you are going to deprecate the "old" system, then why not replace them with a more straightforward (and flexible) system -- without having to resort to both scripting _and_ scriptable objects for literally _everything_. As one might recall, file import/export/etc. is still _extremely_ slow in Unity, so scriptable objects, too, are not sustainable and also, by extension, become a terrible "last resort" to handle ALL slightly 'unconventional' editor tooling needs. Not everybody likes them as much as Unity appears to -- and for good reasons, but most are mentioned above).
This is partly why I am pushing the "Workspace (global) -> Toolbox (midway) -> Tool/Utility (local)" tooling approach, as these are more conceptual than strictly practical, and in this, they become practical.

These concepts are not classes or interfaces. They're only intended to reign in the scope on tooling by providing true, sorely needed, context for data while minimizing scripting requirements. This works well, especially when trying to achieve specificity (while also remaining general enough to be useful to anyone without endless spaghetti-code) throughout all levels of the Editor application's hierarchy and design. Without these concepts, you cannot create a proper toolchain / pipeline that spans across the editor (consistently) without proper levels of context.
In other words, you cannot rely on a single "EditorWindow" or even a "CustomInspector" for every single tool -- much less expect intuitive tools to magically "appear" from nowhere to handle these obscure use-cases -- especially when making things like a custom Flythrough Camera in the SceneView (which, I suspect, is a more common use-case than you guys seems to give me credit for).
Just because people aren't complaining about not having enough context (except me) doesn't mean it isn't a actually a huge pain that most users may not even have the knowledge, patience, or even the desire to explain to you.


Although feedback so far is mostly positive -- when you start talking about deprecating the entire Editor Workflow for the new 'Overlays' that are strictly Window-based contexts (and therefore are inherently built around an extremely limited way of thinking about context), you start venturing into the territory of removing whole possibilities of tools (and suites of tools -- like Snapcam -- to which quite a few people have already copied on the AS in one form or another). So, please, hear me out when I say that Window and Tool contexts are not enough for a functional overlay to communicate with its respective systems/behaviors -- even when paired with the Inspector and ScriptableObjects!!! Scope is too difficult to define with "ifs and thens" and the input, if nothing else, gets lost in translation -- just as it does now -- thanks to lack of proper context (properly) defining said scope boundaries.
This gets extremely tricky when one begins to work with Shortcuts that must swap contexts themselves.

There is no mid-range. There is no context. There is no way to specify a (proper) context (or scope) to apply to. This is as true for the Tools, as it is for Overlays and their respective Shortcuts.
I recommend the Workspaces for an (invisible) "global" approach for MCU tools that need shortcuts for things like the SceneView Camera, which has a "Flythrough" mode, a "Pan" mode, and others. A single "Tool" isn't enough, nor is an EditorWindow nor is an Inspector (or even the standard Shortcuts being applied to a particular EditorWindow). You guys chose to go with a dropdown/popup-styled "Window" and even the very same "global" style shortcuts I'm suggesting here -- except you went crazy far out of your way to actually implement these in your Flythrough mode, PLUS your "Workspace" context is simply the "Scene View" -- which is all you needed -- for THAT specific tool.

However, what if a USER wants to implement the same "suite" of tools very similar to what you guys (yourselves) did? -- Are we just left in the cold?
What if we published that on the Asset Store, and our users wanted to change the keys used? -- Would we tell them to go do some crazy reflection-magic to access internal methods and then _possibly_ have a chance at changing those shortcuts? -- This is exactly the issue I faced with NAVIGATION STUDIO and its "View Navigator", for example.

With proper context operations throughout the Editor (based upon the "Workspace" concept), you would be able to do so -- and limit them to specific windows/modes too if you wish, assuming your "Toolbox" settings allowed this (which is why you need a "mid-range" concept for context -- and not just "global/local" contexts.

Thanks for that -- but for now, please hold on to this post. This describes a lot of the rhyme and reasoning to what I am saying and why it is important.


Sorry about that -- I apologize if I sound or come-off as rude, but it's not personal.
I just get irritated that Unity is so difficult and obtuse to work with most days, and it seems like I'm fighting an uphill battle with the designers of these systems to get reasonable features implemented that benefit everyone -- and explaining the complex reasoning behind those features is very hard work (especially when I'm not being paid for it!)
So I hope you understand.

I really do appreciate the hard work you guys put into making this stuff possible.
Thank you.

 

Good job! Now move play/pause/etc buttons and dropdowns somewhere (consider unified menu or even status bar, also make them hideable/toggleable) for pure perfection.

 

What's needed: dependency lines overlay.
What's that? Lines drawn over all the windows of the editor from the selection to every other object referenced to or from it.
Why? Scriptable objects transfer the tangled web of dependencies from the code editor to Unity so a way to visualize interconnections is needed.

 

Firstly, we need the ability to draw and handle VisualElements on top of everything.
Right now we can only use rectangular non-transparent windows, which are awful, laggy, involve tons of hacks and frustrating to work with. (I've spent literally two month making resizable component popup..)

Such feature will also allow overlays to be easily controlled and dragged across any windows.

Edit: Also - responsive and nicely looking Tooltips!

 

Would it be possible to have something like this built-in?
https://assetstore.unity.com/packages/tools/utilities/ucontext-basic-182221

It has some pretty great workflow features that could make working in unity pretty enjoyable

Especially right now the overlay API could be changed a bit to accommodate something like this instead of providing a hacky solution further down the line

 

Very excited for the new overlays system! Is the new scene tooling ecosystem also being released with 2012.2, or is there any info on when it will be available?

 

Marking menu in Maya is the bomb so I'm def looking forward to that.
But you'll need to address the elephant in the room, eventually.

 

Just thought I would share here, was imagining the overlay system with some sort of pie menu, and I went ahead and did a little experiment with pro builder, seems there won't be any conflicts within the overlay build, as the overlay system was designed more towards dockable tool, here I'm injecting the visual element directly into the rootVisualElement, and seems working fine.

incase anyone wanted to try it out, here's a github repo, I find it pretty cool tho.
https://github.com/BennyKok/unity-pie
p.s. this also works with normal unity build since it's not really using the overlay api

 

Overlay system is available in which upcoming alpha/beta release of 2021.2?
Or s it delayed right now?

 

I would be glad if toolbars could be docked anywhere in editor. (At top/bottom/right/left of any window for example). Are toolbars only limited to scene view or can I create toolbars for specific window or generic toolbar that is suitable for any window?

 

This. And also, I think there should be an element called "ToolbarArea" that will allow to have special areas for toolbars anywhere instead of them being restricted to the corners only.
Here's an example of components toolbar under game-object header:

 

Huh, this is kinda nice

 

Yes please

 

This is really cool. I want something like this to be the default feature of inspector. Something similar to modifier stack from 3d max

 

What exactly is already available (other than the overlays public build)?

I've written custom EditorTools in the past so I'm aware of their existence, but the video I saw spoke about solving awkward collisions between tools and shortcuts in different packages. It also mentioned a unified way of doing things like modifying vertex data. Is any of this available in the current API or will it come later?

Apologies if this is the wrong place to ask, I'll make my own thread if needed

 

I wonder if Snap tabs will also be available on the scene as an overlay?

The ProGrids tabs were perfect, but in the integrated version it is horrible to work with the snap... if it were available directly on the scene tab, it would be much more useful.

 

Any updates on availability or new features?

 

that's what I'm talking about.

I can't wait to test this novelty.

 

@gabrielw_unity Can we use the new tooling system in a production project? We are 2021.1 Thanks, Marek.

 

Can we have snapping if grid is not a viable option.
also, right now if we want to group together overlays we need to dock them but could we something where we could group them together when they are in panel mode? (maybe in the collapsed state) this could help with organizing different overlays with different usage together

 

How can i revert back to the old workflow?

 

You can't afaik

 

I think you misunderstood, I meant snapping of overlays, like we have in shader graph maybe

 

I'm certain i will, once its gained updates with stability and UX improvements, and other tools also use the new workflow. But as it is right now i dont.

My experience with Unity is that it takes several releases to get improvements on par with existing systems (e.g. new prefabs, assetstore window, assetdatabase v2 etc etc), so replacing out such a fundamental workflow is making me very anxious about the usability of Unity.

I'm sure many other customers will also have a hard time switching over, and a transition period would definitely help with product stability, a major focus at the moment.

 

Fortunately, you can stay in 202 LTS for 2 more years while the new features stabilize

 

So if im not mistaken, where the buttons used to be there is now empty space, and instead my scene view is cluttered with the same buttons? There is a window to inform me that there are no custom tools, i have no idea what that is nor what i am supposed to do about this. I now have to click twice to change pivot and global, where it used to be once. For some reason that popup looks different from any other in that bar, nor does the tooltip suggest the keyboard shortcut for this action. I dont understand why i cannot click behind the orientation anymore, why there is this background suddenly? I cant even interact with it there, dragging doesnt move the UI element. Collapsing it seems useless, locking it however and not having this weird background is something every unity user that is used to the current workflow will want to do. But i guess this is still alpha.

Things i'd actually be interested in seem to be missing, for example customize which buttons exactly are visible. If i'm not making a 2D project it might be nice to hide the 2D button. I'd remove the collaborate and services buttons in a heartbeat.

I understand that you are excited about these features, but i am not. I am not the target audience, i dont use many other tools besides the scene view and i am very used and attached to how they are at the moment. Change is hard, so why not meet your users somewhere in the middle?

Dock the overlays at the top where they used to be (and where there is empty space right now), and allow us to drag them into the scene view. This seems like a non invasive, and gradual way to introduce changes to the UI, that ultimately improve the experience while minimising user pain while adopting this.

 

There's a 3.5 minute long video in the first post in this thread that answers all the questions you have, did you try to watch that?

This is a huge usability improvement for the scene view, you can hide all the UI buttons you don't need because you have memorized their shortcut keys or never press them. So there's a big, big increase in available screen space.

 

Just one glaring issue with that, the empty space where transform tools used to be really stand out and make it look like a waste of space, I hope something is planned for it or you guys are able to figure it out

 

Can't the presets be upgraded to a more standardized setup? -- (i.e. Workspace -> Toolbox --> Toolsets -> Tool-Layouts)

The idea, in my mind, is that the main view (the one pretty much doing all of the gruntwork) should have quickly swappable toolsets, all originating from a central Workspace (i.e. a specific EditorWindow, for example -- which acts as the Hub for all other EditorWindows and the respective Tools/Layouts/Shortcuts for that "Workspace" followed by its Toolbox).

 

I understand this, i just wish Unity users that arent scene-focussed artists were also considered. It doesnt seem like its mutually exclusive either, e.g. floating windows could be docked in the bar above (like they used to), the global/pivot buttons only dropout when you click on the arrow next to them, and otherwise just go to your last selection.

This way you innovate, but dont regress. Even with improvements, people (me) need time to adjust, and sometimes never will. E.g. i also still use the one-column layout.

Either way, thank you for being so responsive here. I really hope the new tools do turn out to be improvements, for every type of user.

 

You're right Baste, i hadnt. When giving feedback like this i should have, and other alpha users probably also should. Of course, when this is released you cannot rely on people watching a 3.5 minute video to explain why the new way is better.

I understand that this is the case for you, but it quite frankly is not for me. The space where the scene view buttons used to be is empty now, and more space is taken up in the scene view. This means less available space in the scene view for my workflow.

 

This is EXACTLY what I'm referring to above.
I have tools I would like to make on the Asset Store, but my windows have no concept of interdependability, nor do these windows' shortcuts have any sense of contextual consistency (much less contextual sensitivity), meaning that tools (and especially sensible workflows) are going to be harder to create (and slower to use) for particular, creative, workflows I've got in mind.

 

Might be overkill but allowing to customize the toolbars themselves (without custom scripts) might also be a good idea.

My project for instance does not use the "2D" or "Audio" Toggles from the SceneView Toolbar, so that just fills up the toolbar immensely on a 1080p screen.

 

A callback when any Overlay is being created might be good for that. It would be easy to customize in script / USS cause it's all UI Elements.