Official Overlays Public Build Available

First of all, love it. All of it. Want more of it.
Second of all, the 3D orientation/perspective gizmo makes it a very obvious thing to think about, but, in the Panel View option (and others, for that matter, who knows when it would be a good idea), is it possible to customize/hide the panel itself? Not that I think there will be many examples of when to do this, but, well, who knows. Even if only for this one instance of it.

 

-Could it be possible to add resizable overlays support? (Maybe at least to panel mode)
-And some kind of grouping system for overlay menu because I can see it getting pretty messy in many projects
-Also when toggling the overlays back on with ctrl + spacebar all the overlays get turned on, i.e, the ones which were hidden also get turned on
-The tool overlay also doesn't support multiple different scene views yet, when I select move tool in one view, it also gets selected in all the other views
-One strange bug I discovered was when I use a saved layout from the overlay menu, my scene camera gets aligned to the view I last selected that layout in

 

-One more Error I found was when the overlay is docked or undocked there is no way to scroll through the overlays when the total size is greater than the size of the screen
-Along with some bugs when live reload is enabled in the scene view, all the overlays get reset for a moment and then get back to the same state, and also the overlays whose properties are being modified goes up the docked corner they are in, i.e, if they are at the second position then they go up to the first position

 

It was just about the transparent background, good to know it was planned. Is this going to be an exception or do you plan to expose it somehow?

Because as much as I can't think of something else that would need this right now, these kinds of things tend to be needed when you least expect them to, and then you are caught by surprise and can't do anything about them.

 

@AndrewKaninchen got to almost all of my questions before I had a chance to ask them lol -- but this was definitely one of them.

1. So as I understand it, opacity of the toolbars, etc. can be controlled individually -- but is this per-panel, or is it per panel form? (i.e. generic panel form has different opacity settings than toolbar form, and button/dropdown form has different settings than panel form and toolbar form?)
   
   
2. How do in-scene "gizmos" work alongside panels? (i.e. can panels automatically disappear/fade away when, for example, when moving a transform widget toward them in screen-space?)
   
   
3. One thing I was also wondering -- can Shortcut Manager shortcuts be allocated to panel sets / overlay configurations? (in other words, certain shortcuts are activated/deactivated depending on which overlays / configurations / workspaces are active).
   
   
4. Also, is there a "Grid" style in the works? -- I can see a "grid" of toolbar icons being extremely useful for my "Grid Navigator" tool.
   
   
5. How does the scrollwheel respond to text input fields? -- i.e. if I scroll my mousewheel, will it allow me to increment/decrement my sliders/values in these panels?
   
   
6. Finally, will there be a realtime equivalent (i.e. usable in-game) version of this toolset? -- I can see this being extremely useful for creating in-game content while also in-game.

 

This is great to hear! -- Let me know if you need any support on this one, and I'll gladly do what I can to help! This would be such an incredibly useful feature -- and for so many reasons. D:

Not quite. While that ability would be cool in some cases, the setup you guys have right now is much better and way more practical than that, actually.
I mainly meant that, sort of like a typical panel, all elements follow a grid-like structure (i.e. fit all elements into as few rows/columns as possible -- possibly with a pagination widget / mechanism of some kind.

Ideally, for large collections of visual things (like prefabs) that need a tool to quickly operate on them or quickly perform an action via a single click (rather than navigating through menus/dropdowns to select an item, and then subsequently pressing a button to perform an operation -- then proceed to do this on 10 other prefabs). Ideally, this would work without the need for an explicit selection (and therefore a "tool" that is activated based on a single click on any of the visible items in a grid layout). The design I have in mind is based around the ability to quickly use (single-key) shortcuts, like I have in NAVIGATION STUDIO.

For simple cases like my Grid Navigator, I call forth my menu with the "G" key, then I simply click the visual "button" associated with the particular "snap" location in the scene I want to go to, and then I move the user to that particular location in the scene instantly. However, at some point, too many items appear, and either the overlay panel needs resizing, or I need a pagination mechanism. This is a common issue when you need a large number of operations (or items to operate on) especially when those operations and/or items increase in number. Seems like this functionality should be built-in in some form, since it is a common use-case (and fits in with the "panel" motif well enough already).

See my Grid Navigator here.
Essentially, I am talking about buttons/elements being automatically arranged like a grid, but shift around automatically as the panel is resized -- and perhaps with a pagination mechanism built-in (for use-cases like I described above)

.Yeah, I can see this being a problem for drag-and-drop situations (like the "grid" situation I was discussing above), where I would want to "drop" a prefab directly from the scene into a grid-based "collection" of items -- and then press a button to perform an operation on them all at once (i.e. selectively setting the material on these specific objects).
Doing it this way could be A LOT easier than simply digging around your scene each time you want to select a particular group of objects to act upon. I can imagine a really awesome tool built with this workflow in mind.



And lastly:

I was thinking separate shortcuts for "Window Presets" _and_ separate shortcuts for "Workspace Presets", as well as "Individual Panel" overlay shortcuts that get overridden by Window Preset shortcuts, followed by the Window Presets and shortcuts getting overridden only by Workspace Presets. The "Individual Panel" presets get overridden by both the Workspace and Window shortcut presets simultaneously.

The major problem this solves is that if, for example, you would want Probuilder _and_ the Terrain editor toolbars/overlays active at the same time, you could. (Due to their purposes -- and possibly shortcuts -- bleeding into one another, with the current system, this is pretty much an unhandled situation that greatly dictates what kinds of tools we can use at any given time).
However, if you setup a workspace for this (with its own shortcuts, specifically altered for the fact that you desire to use both tools simultaneously (with no longer conflicting shortcuts), you could. You would also have a quick way (say a tab, like in Blender) to swap between different modes of working (Workspace Presets) and have the tools and the shortcuts you need at your fingertips (i.e. SceneView Presets) that override the default shortcuts established for the individual toolbars/panels and their individual tools (Individual Panel presets and shortcuts) -- This will now be dictated according to your _own_ work style, rather than the tool designer's (usually poor) whims about aesthetics and functionality..

The more subtle problem that this style of the tools/overlays solve is that, currently, the tools themselves (i.e. Probuilder and/or the Terrain Builder) dictate how you must work and what tools/shortcuts you HAVE to have active (as well as which tools you _can't_ have active) at any given moment -- which dictates A LOT about a user's workflow (rather than the user himself doing it.) This makes it ultimately a lot _less_ enjoyable and a lot _more_ painful to use the tools than it could be otherwise. For example, I could see building a quick mountain with Terrain tools, then using Probuilder to "sketch" a house on top of that hill (in order to visualize how it looks with the rest of the terrain as it is currently). This allows fast, non-destructive, iterative workflow -- which I feel Unity should embrace A LOT more than it already does. You guys are making a really good start to that (probably unintentionally) with the new panel/overlay workflow -- I just want to see it past the tipping point of being good, heading into the realm of being awesome.

Hopefully this makes sense -- and helps explain why I'm pushing so hard for Shortcuts to fit into the Overlays workflow.
My Grid Navigator is a prime example of how fast a workflow can be with the proper shortcuts available at the right moment in time -- and in the right places.

 

This feature should be there as this would be used to create multiple scene views to do different things, like use pro-builder/ UModelere in one window and use the other for placing the objects or maybe use for UV mapping or some other workflow but this can't be done if the tools aren't unique to each window

 

One more feature you could look into is multiple rows/ columns of the toolbar, this could be especially helpful in case of modeling workflows, look at Sketchup for reference

This could work perfectly with camera preview as well, or some other tool showing some kind of preview, Can be used for overlays that have a lot of option like UModeler which honestly is hard to fit in a single horizontal panel or create a panel for every category

 

One more bug I found was related to collapsing and hiding overlays:

Code (CSharp):

1. public override VisualElement CreatePanelContent()
2.         {
3.  
4.             var myContent = new VisualElement { name = "my-content" };
5.            
6.             var button = new Button(() =>
7.             {
8.                 Debug.Log("Panel!");
9.             });
10.             button.text = "Press me!";
11.             myContent.Add(button);
12.  
13.             return myContent;
14.  
15.         }
16.  
17.         public VisualElement CreateHorizontalToolbarContent()
18.  
19.         {
20.  
21.             var myContent = new VisualElement { name = "my-horizontal-content" };
22.  
23.             var button = new Button(() =>
24.             {
25.                 Debug.Log("Horizontal!");
26.             });
27.             button.text = "Press me!";
28.             myContent.Add(button);
29.  
30.             return myContent;
31.  
32.         }
33.  
34.         public VisualElement CreateVerticalToolbarContent()
35.  
36.         {
37.  
38.             var myContent = new VisualElement { name = "my-vertical-content" };
39.  
40.            
41.             var button = new Button(() =>
42.             {
43.                 Debug.Log("Vertical!");
44.             });
45.             button.text = "Press me!";
46.             myContent.Add(button);
47.  
48.             return myContent;
49.  
50.         }

I used this test script to find which layout was being drawn,
What I found was that if I collapse an overlay in any state and then convert it to the toolbar and expand it, doesn't matter which one, it remains the same one as when I collapsed it

for example, if I collapsed it in horizontal toolbar and then I dock it in the vertical toolbar and expand it, it still draws the horizontal layout

 

Doh! -- I see what you mean.
I assumed panel resizing was in the cards for sure and being able to have buttons automatically resize and propagate to fit inside a "grid" area of a particular physical size, no matter the number of elements (as well as a fast/default way to do tabs and/or pagination workflows) was a common use-case that I assumed would be supported, since so many tools at some point _have_ to support these features on some level. These are not just "nice features to have" but critical UX and user-facing problems that should be addressed in a general-purpose UI solution.
However, that makes sense that you guys wouldn't be worried about the content itself -- so your response is duly noted.

That said -- I still stand by the fact that this needs to be made faster/easier (at least by the UI Toolkit team) for the purposes I mentioned above -- and eventually made compatible with scene tooling overlays/workflows like these.

I get what you're saying, and I agree with your reasoning behind it, but I strongly disagree with the "multiple scene view" approach. Having multiple SceneViews open simultaneously (and selecting objects between them) is not only heavy on performance, but complicates many, _many_ things.
For example, wouldn't it be nice to define your own scene camera control? Well, it's incredibly painful to do. I've done my due diligence and wrote a tool like this. User-defined SceneView camera control is not particularly viable as it is right now (especially with WASD-like movement behavior) due to how shortcuts/context works under the hood (which I imagine on some level is because there can be multiple scene views and therefore repeated shortcuts simply cannot operate at the rate they are received from the keyboard directly).
Because I disagree with the multi-scene approach so heavily already, my asset (Snapcam) does not support working with multiple SceneView windows. On top of performance, multiple scene views heavily complicates things like contexts for shortcuts or gameobjects (including repeat-rate of the keys used on the shortcuts -- which is still a thorn in plenty of people's side -- including mine), all the way down to which "scene" is currently being operated on. Just a headache, in practice, all the way to the core of the concept.

Instead -- See how Blender does this.
A different (and arguably 'better' way to do this than what Blender does) would be to use a simple dropdown in Unity that could replace Blender's "Tabs" approach and save a lot of real-estate in the UI workspace (for the price of costing an extra click to select the workspace/context you desire, rather than a single-click on a Tab -- but this 'cost' could be offset by using workspace shortcuts for common workspaces (i.e. numpad keys or numerical slots) to instantly select that workspace via a single shortcut press. That, or use Tabs -- and then shortcuts for any "extra" tabs that aren't visible to click on. A final option for workspaces is to allow the user to select which version to use. In my opinion, I am more inclined to do workspaces something more akin to selecting the active "Layers" in Unity -- i.e. two-clicks gives a user time to reconsider his actions (in case it turns out that he doesn't want to reset the state of a tool by swapping its workspace).

Keeping a single SceneView brings the following benefits:

1. It keeps things MUCH simpler for everyone. The only thing that should change from the current approach to how we handle SceneViews is the ability to specify what overlays are present at what point in time (i.e. Workspaces).
   
   
2. Tools and Overlay contexts become much easier to manage -- and much more performant -- because they sidestep the need to have an entirely separate SCENE CAMERA rendering your huge, epic, open-world, and the selections you may or may not have affecting who knows what else (including other tools / scripts that you may not even be aware of which are running at the moment -- especially if you have many complex assets imported)
   
   
3. Swapping between Workspaces becomes a simple matter of only knowing which overlays (and shortcuts) are needed for the particular task being performed. UV layout needs different tools/overlays/windows than simply placing game objects or designing levels -- or even modeling / sculpting the world (for example, there's no need for a SceneView camera controller or the WASD input -- and having only _one_ SceneView to deal with simply lets you disable that _one_ SceneView when activating the new Workspace -- not to mention doesn't require you to have to "restore" those multiple SceneViews later -- in their exact states).
   
   
   
4. As long as the EditorWindows themselves are considered some form of an Overlay / Panel (or at least the size and positioning is considered in its data), these could be (easily) wrapped up into the Workspace "save/load" mechanism -- and later restored (easily) with no need to record anything special about the SceneView's state (because the _ONE_ SceneView could be in the exact same state you left it in before swapping to your new task and/or Workspace -- which is great if you're swapping between modeling tasks and placing gameobjects).
   
   
5. Keeping the same scene "camera" position across multiple tasks can be much less "jarring" when swapping quickly between tasks/workspaces. For example, in Blender, it is VERY disorienting when you switch from Modeling workspace to a UV or Animation tab/workspace (which you were working in an hour ago), and suddenly your camera looks "alien" to you (because it stayed in the _exact_ position it was in when you left that Task/Workspace -- yet when swapping back to it, you "expected" it to preserve your _current_ camera and workspace positioning and therefore expected to see it appear in the same position for what you were doing while you were in your Modeling tab. As a user, you just wanted to quickly manipulate bones at the moment (with the same camera angle as when you were modeling -- and then quickly swap back to modeling again when you got done "adjusting" things to better fit the "new" mesh shape).
   
   
   
6. In the few cases that you actually _want_ to preserve an exact camera angle -- using something like Snapcam would allow for this. You can have an "arm" or "torso" or "head-front" or "head-3/4" camera "snap" that you can instantly jump to with something like my Grid Navigator. This would (ideally) be nothing more than an overlay dropdown or quick pop-up -- but the _benefit_ is that you can direct it to the _current_ and _ONLY_ SceneView, meaning a tool like this wouldn't be complicated to write at all -- yet would help some workflows tremendously. The tool could even be designed to save different "snaps" for different "workspaces" -- which would be rly cool.
   
   
7. Keeping track of individual "Tool" states would also be much simpler -- both for the @Unity devs as well as the tool developers actually using/designing the overlays / EditorTool approach.
   
   
8. Performance, of course. -- I mean, why have 20 SceneViews open for 20 tasks? Common-sense dictates that nobody in their right mind would do that. So maybe one or two at a time. However, if you can customize your workspace to include more than one Toolset and Operation at a time (i.e. modeling an UV operations in a single workspace), what need is there for a second camera while in the same workspace as modeling operations? The costs-vs-benefits for that "feature" is astronomical -- and that cost comes mostly from programming and logic complexities due to having to keep in mind that there can always be more than one scene-view for any given set of overlays/workspaces. -- Sorry, but I DONT want to have to worry about that kind of complexity when writing my tools. It is unnecessary -- and generally pointless -- when you have a workspace and a concept like Snapcam to work with. A single (general-purpose) SceneView would do for any possible task/workflow. D:
   
   

Thank you so much for considering this. You have no idea how much this saves my sanity! D:

Snapcam is supposed to be a "Studio" of interdependent navigation tools. An interdependent Workspace, Overlay, and Shortcut concept would have made it so much better and more usable (and maintainable), had it been available when I wrote the tool.

 

Lol, sorry -- just needed to be sure I explained my points well.

This is actually a really good point -- but the same can be said for the Scene and Game views.

However, these are essentially just "cameras" and should really be treated that way so that redundancy across the whole Unity editor is minimized. A "camera" is not a "SCENE camera" -- it is simply a "camera" -- and they both do exactly the same thing -- whether they are used in an "Overlay" as a UI element (along with other cameras/renders) or used as an entire "EditorWindow".

A camera is a camera.

Speaking of which, that "hot-swappable" thing (with a preview) is essentially what I've done here (with the Game view):



The Game View and the Scene View actually "toggle" amongst themselves (via middle-click in the tiny orange rectangle there OR middle-click on the "Game" overlay panel / camera preview in the bottom right of the "Scene" window). A single left-click in this area grows/shrinks the view (so the second camera is not always rendering -- and therefore saves performance, as if it were located in a separate window).

The same kind of tool could be done -- but with multiple "cameras" in a single Overlay popup (similar to how I'm expanding the "Game" view here -- except with three, potentially differently-sized, cameras rendering, so that you can see one view more closely than another -- such as the face of a character you're modeling -- and simply clicking on it with middle-mouse, for example, would instantly activate it in your Scene view). This behavior could be tweaked via script or whatever, but the basic idea is the same.

This is what I think programs like Maya should have gone to YEARS ago.


Besides...

A lot of what we're discussing with tooling has to do with this (old) mockup of mine. This mockup is a bit more rough than what I think we could achieve now, especially since I'm seeing the current design of the Overlay system.
One thing to note about this mockup (in regards to actual TOOL workflow) is that the "Active tool INSPECTOR" is located in the scene view as an "overlay", rather than in the standard "Inspector" window (because THAT is where it acts with modeling/terrain tools). What actually sits in the INSPECTOR area is the ToolBOX properties and settings (that act on all the individual tools in an overlay as a whole -- such as particular settings/preferences -- like a global brush texture, for example, or whether to use "snapping" while painting in the scene view for precise placement of strokes or curve verts). And whether you grab a tool from this toolbar or that toolbar, the inspector changes to that of the currently active tool and toolbox (and the respective inspectors {active tool inspector and active toolbox inspector} reflect all the operations that come with it).

If you're interested in the details I missed above:

Spoiler

In my design mockup, "toolset" = "toolbar" (and "overlay" too) and multiple toolbars can be part of only one toolbox (many-to-one), but ONE overlay layout config / workspace can contain many toolboxes (and therefore visible [or not] toolbars, each coming from different toolboxes). The active shortcuts are tied to active toolboxes (and override workspace shortcuts -- unless explicitly told not to). There can be only _one_ "active" tool at a time in the whole workspace. Selecting this tool also selects its respective toolbar/toolbox. There is also a "passive" tool concept (however, instead of being tied to a particular toolbar, "passive" tools are probably tied to the toolboxes themselves -- i.e. certain ways to "snap" to the grid [such as the center of the bbox, left-side, etc.] -- can be considered "passive" tools and activated/disabled individually in the toolbox inspector if desired -- or upon switching "active" tools, if the author needs more control over the tools.) My design also includes the concept of "exclusive" tools to toolboxes and toolbars. Whether "passive" or "active" tools, these function similar to how radio buttons work -- so that only one tool in a toolbar or toolbox (out of a specific group of tools -- i.e. active or passive or both) can be used at a time (all others in the specified "group" will be disabled).

These concepts and approaches will allow for a robust, fully-functional, suite of tools that work together across a variety of tasks that are mechanically different, but functionally equivalent.
--- For environment design scenarios (for example), you'd be able to have a unified series of tools (developed by different authors) that work for generating "buildings" or foliage, alongside mesh sculpting / boolean tools, etc. -- and have them all sitting and functioning (nicely) together in the same workspace (with their respective shortcuts).

Thanks for the explanation.
One thing I'd like to understand is, rather than the (basic) layout complexities (i.e. do we shift things around like a grid -- or do we base it on pixel-perfect "borders" when we have to go "multi-column" at some point?), what exactly gets "messy" with the resizable panels, if you don't mind me asking?

Unless that's actually exactly what you meant?

And thanks! -- I was sure it was supposed to have already been a thing. Yet I've seen nothing about it! -- So I'm glad you are pushing this to them as well!

 

from very brief test,
- i hope orientation gizmo tool has option to stay as is (not as a floating window)
- that main window (space toggle) could be taller, or resizable
- double clicking overlay toolbar could do something, maybe dock or hide/toggle? (or middle click to close/hide)
- while dragging overlay, pressing any key resets the drag (probably not issue really)
- toggle all overlays on/off somewhere?
- sometimes blue border appeared to multiple overlay windows? *screenshot below
- cannot use arrow keys in the main toggle window (and of course couldn't really use space to toggle rows..)
- could Play and rest of the main toolbar buttons (layers etc) also be floating? so can remove that main toolbar (to save space, or drag these overlays to that main toolbar?)
- cannot drag whole toolbar (with multiple overlays on it, ^someone already mentioned grouping, would be nice)

 

Could we maybe right-click the gizmo and make it draggable / show overlay window if we desired? -- I can see a few cases where I wouldn't want this to be transparent.


Also -- I might even want to drag an overlay or two into an entirely separate EditorWindow (while still linked to the SceneView) to put it up on a second monitor...

This is great to know. See my above post for some design ideas to potentially speed up that particular part (I go into some pretty juicy details).



Still gotta say -- I'm extremely glad to see you guys working on this!

 

The title? -- not really. The background, yes -- believe it or not -- it does.


The biggest issue would be that I cannot (at a glance) distinguish between the visible area and the clickable area (i.e. the clickable width / height of the widget/gizmo versus where it actually appears clickable) without being able to see them -- which leads to (very irritating) unintentional selections/deselections.

For example, while trying to select an object beneath my mouse, I might click too near the widget (when it's at a weird orientation -- i.e. too near the corners of the + because they're transparent at that particular orientation). I think I'm clicking on an object in my scene (which is near the widget/gizmo with a transparent background), but I click the widget/gizmo instead (because it seems like an in-scene gizmo and yet it isn't) and accidentally click again (because I assume Unity didn't register my click) and I lose my complex selection -- and now I'm irritated because what I want to click happened to be "too near" this widget/gizmo for some reason. Had the widget had a background behind it, I could easily have known my selection would fail me.

Many people will blame the designers for making it this way -- rather than _themselves_ for clicking too close to the widget/gizmo despite its transparency (and I couldn't blame them). New users who have no idea of the 'transparency' concept and the fact that you're _really_ clicking on an invisible rectangle area that is actually larger than what's visible (in certain areas) and _not_ on the visible portion of the widget (i.e. in order to reorient the camera) would be baffled.


In general, stuff like this should _never_ be fully hard-coded. Because I can promise you -- as long as I've been using Unity with this widget, I still _always_ click the visible area of the widget to rotate things -- even though (mentally) I know I could reasonably click "near" it and it would still work. Beyond that -- when I click "near" the widget (say I move it to the bottom of my workspace where the "ground" is in most games), I'm clearly going to accidentally do this more often. To tell the user "NO -- You cannot put it there!" (to avoid them clicking on the gizmo/widget/overlay's transparent area when they're actually trying to click an object) is the wrong answer in UX design. The user very likely to have a good reason why they're placing it there -- and you, as the designer, are going against them. -- If this is their perception of you, I can't blame them for getting mad at you. After all, you're telling them they cannot work how they expect to be able to work.

Thanks -- I seriously appreciate the consideration on that!

Honestly, I really think EditorWindows should at least have some semblance of knowledge of one another (and Overlay contexts too -- even if it's ONLY to introduce the "Workspace" concept -- which should include EditorWindows too) because, whether anyone likes it or not -- a proper tool unification workflow is not possible without the different tools being able to know about (and talk to -- and about) each other across the whole workspace.

This is what really kicks me in the teeth with my current attempt at doing this with NAVIGATION STUDIO. I have to rely on singletons and static variables -- all just so my tools can feel comfortable to the user (and be contained in their proper scope -- while also knowing about one another).

That's really cool to hear! -- Thank you!

This post is what got me here!
It's really great to see that you guys are thinking about this stuff as much as I am! ^___^

I get that. However, simply truncating is a bad idea without at least a _little_ input from the user.

So I have a (less-messy and less-bossy) idea:


Have you thought about, instead of always "truncating" things, you simply shift them to the next available "anchor" point or opposite justification side in the workspace rectangle by default -- and let the user choose in the workspace settings as to whether -- or where -- he wants resizing / truncation instead?

For example -- If the list on the left-justified side gets too many overlay widgets (and the toolbars can't be resized horizontally anymore to keep from getting pushed offscreen), you simply relocate the bottom-most overlays/widgets to the _opposite_ side of the screen (i.e. make them right-justified instead) and stack them just below the existing (right-justified) widgets. Since there is always an "opposite" side to a four-sided rectangle, this would help deal with overflow in a nice ("not-breaky") way.
However, when this is no longer possible (and things can't be resized any further), only at this point do you actually "truncate" your widgets/overlays if they go offscreen.

Each toolbar/style should be able to say whether it could be resized or not to fit the current window in the workspace (for example, my SnapNavigator overlay needs to be a certain size, so it can't be resized to fit, but my GridNavigator overlay is perfectly fine to resize or place elsewhere in order to fit in the layout).

What could be an alternative (and handy for users who would prefer to shift or anchor the overflow to certain portions of the workspace instead) is in your workspace settings, you can provide a simple rule as to which side of the screen any "overflow" should attempt to appear on (and otherwise be truncated on if it cannot be resized to fit on either place.)
You would use the default blue "anchor" points to determine which side/justification or anchor point the overflow would try to go to when there is no more space on a particular side (i.e. if the left-justified overlays can't be resized anymore to fit on the left side, they can be told to go to the top-right corner and anchor themselves there to fill out the rest of the top of the window on the top-right side, while allowing the [probably special] right-justified toolbars to stay where they are.)


Hopefully this helps!!

 

The camera preview isn't working the way it's supposed to in this build

Code (CSharp):

1. Use the new Overlay class and OverlayAttribute instead.
2. UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
3.  

I get this warning every time I select the camera although the preview is visible in the overaly

Also when I'm moving the camera the overlay is just white, it doesn't show the preview

 

For most cases I agree, but the 4-split workflow (as seen in tools like Hammer) relies on the ability to have multiple scene views being open, which is an incredible boon for level design, particularly the greyboxing kind. 4-split is already kind of a mess in Unity as is, so it's not like forcing a single scene view would mean losing something of value (also the fight for better level design tools in Unity probably isn't worth fighitng), but it doesn't set a good precedent and I personally want to keep it so it can be improved in the future.

+1
I think shortcut levels are a really really good idea. My concern is how these shortcuts would be authored - you'd have to pull off some UX magic to communicate what you're editing and what's being overridden. Considering we already have a shortcut manager, this would mean bringing the amount of shortcut levels from 1 to 4, and I'm not sure how I expect the order in which each level to be overridden.

Most important though in my opinion is for there to be panel shortcuts that can be overridden by the user. As Unity grows and I acquire more tools, the amount of shortcuts grow and the amount of available keys I have shrink. I don't have an infinite amount of keys and human muscle memory can only remember so many niche shortcuts per tool before it forgets or slows down response time. If I can reason a specific set of shortcuts per "mode" or panel, that's much easier on the brain and quicker to learn.

Also I have to thank the developers of this project. I've been pushing for years for Unity to not just have good workflows, but workflows that the user can suit for themselves. This is an incredible push in that direction - you guys should pat yourselves on the back for this.

 

I get where you're coming from.
What you're referring to though is the same problem as what I was discussing above about being able to reference the Game view and Scene views simultaneously, for example -- and later, different views of those as well.

With the "hammer" workflow, the question then becomes:
"How does Unity let you reference a topdown/left-side/right-side/bottom-view/perspective of both the 'Game' and the 'Scene' camera -- all at once? -- With the hammer approach, that would be 10 different camera views. D:

The obvious answer:

You don't. You find a new way.

I think the biggest reason Unity has probably stuck with this setup for so long is due to this (your) particular viewpoint. However, Hammer was developed back in the 90's -- and UI / UX has come a long way since then. Most 3d modeling programs (even the often laughable Maya) no longer even come with the 'traditional' 4-window modeling setup as default anymore. The reason for this is due to the fact that one can work in as many different viewpoints as they want with a simple shortcut press that swaps out the entire window layout / workspace.

This is still a bit heavy-handed though -- So I propose a new approach:
Keeping in mind that you can only ever "edit" in one window at a time (in any 3D modeling application -- even in hammer), in the case where you need to reference multiple views (e.g. while laying out or grayboxing your levels), what stops you from having an overlay panel at the bottom or side of the screen (i.e. in toolbar form) that can be popped up with a quick press of, say, the "R" key (for 'reference') that displays two other (independently-scalable) camera views of your scene (scaled up individually to your comfort level) with a transparent background (or not, if you prefer) on the overlay, so you can still see the scene you're working on, and then toggle them out of the way (again) if you no longer need them for a few minutes. To add a bit of 'oomph' to this powerful setup, having a separate EditorWindow so that you can dock this "reference" widget/overlay (like in the second monitor post I wrote above) would allow you to have that nice overlay available at all times (instead of just temporarily) -- and it would work exactly like having a second / third scene view (especially if you have a shortcut, say 1 or 2 on the numpad) that swaps the current scene view camera location/angle with the topdown (1) or side-views (2), respectively, so that you can quickly continue (interactively) editing your scene from those viewpoints and perspectives just the same as if you had a second (and third) scene view window open.

The added benefit is that those previously "tiny" windows -- are now huge (and you can more precisely edit them), while still being able to reference your previous viewpoints (e.g. on your second monitor, for example).

I completely agree on this one actually.

I really do think users should be able to "override" toolbar and overlay shortcuts on a Workspace level -- in context -- rather than via in a huge global Shortcut Manger window. Many popular 3d modeling programs (as well as others) are going toward this, and Unity should too.

I might choose different shortcuts for different Workspaces -- even for the same tools (i.e. the example about Probuilder and Terrain Tools needing to be used simultaneously in the same Workspace, for example, yet possibly having conflicting shortcuts). Letting the user override whatever "global" shortcuts the toolbar/overlay author defined as the global default, but on the (user-defined) Workspace level is much better, imo, than trying to do this all in one huge, epic, Shortcut Manager window, that contains every possible Unity shortcut known to the application, (all while trying to decipher vague descriptions of what the shortcut is actually referencing). After all -- going through something like this is a chore in and of itself -- so being able to set these in-context would be a MUCH more user-friendly (and much appreciated!) option.
This is actually where my ToolBOX concept really shines -- You can edit "passive" shortcuts (like enabling a grid-snap function) from an actual UI location (the Toolbox), if you have the Toolbox Inspector portion (with the same being true for the various options and settings for the Active Tool -- set in its own Tool Inspector area, separate from the (more global) ToolBOX Inspector area, which manages the more global options/settings for tools in the individual Toolbars/Overlays contained within it). For more info on how to visualize these two inspectors, see the old mockup in my previous post. Using this ToolBOX "Inspector" area for the Tools in the individual Toolbars to setup their more "global" or "passive" shortcuts should give a better idea ("in-context") of where (and at what level) the shortcut is acting upon -- and also tell the user that they can "override" any pre-made shortcuts set by the Tool / Toolbar (Overlay) authors all right there in the active Tool or Toolbox's respective Inspector (on a per-option level).

In my example, the "on/off" toggle of the grid-snapping would be a right-click (on the checkbox or label showing whether "grid-snapping" is on or off) -> Set Shortcut -> press shortcut (while a "Waiting for Shortcut" window pops-up to wait for the new input). This new shortcut would override any predefined shortcut set by the tool author (unless _explicitly_ made by the author to be unmodifiable, since some tools need to work in conjunction with specific keys being pressed -- Though a "meta" keypress (sort of like how the new Input System's "Action Maps" work) -- could easily solve this issue for so many tools on the Asset Store, for example).

Those are just my thoughts on how this could be done.

Seconded! -- You guys totally rock!

 

Have not read all of the topic yet since my last post, but this point in specific seems kinda dumb to me (also, @awesomedata, you really should try to write less, your walls of text discourage everyone else from reading your stuff even if there are some good points mixed in there).

Back to the point; Hammer uses 4 views: a 3D view and one orthogonal to each axis. You also don't need those for the game view unless your tool developer did something dumb in your tooling which requires you to use game view instead of scene for anything that's not previewing the game running. So, at most, in a level design workflow, you'd have 5 views, with 4 simultaneous ones and ideally one which is hidden in another window or tab (kinda like the default layout does, with the scene and game views being in the same place so you can switch between those).

Using 4 views is incredibly valuable in grey/whiteboxing, as someone else mentioned above. I used to play around a lot with Hammer many years ago, before I ever even knew how to do anything else gamedev related, and coming to Unity and not having a good way of doing that by default (not to mention not even having whiteboxing tools until the relatively recent ProBuilder acquisition) made me feel like I was going back in time to even before I was a kid. Orthographic axis views make everything so much faster.

All of that is to say, it's incredibly easy to conceptualize a way to make it work, even without multiple scene tabs per se. You'd really just need the option to split a same Scene tab into multiple views, all inside the same tab/window. You could even have shortcuts to switch between these layouts (single big shaded view and the traditional Hammer-like 4 views being the most immediately useful).

 

On the topic where he said that adding each scene view is basically adding a camera and it's very costly, I think by adding multiple scene view support it's up to the user to choose between multiple windows or single
And I'm pretty sure that this workflow is still useful to a lot of people
And as far as tool developers go, this is no excuse that it's bad because we will have to do extra work, of course, it will be hard at first but it's more than worth it to develop this ecosystem of tools, even in the blender and all other tools we have multiple scene views, although I do guess there will need to be proper API support for this to be implemented, it's pretty hard as it is right now but it's the same when anything is changed for new I guess

 

I can see where you're coming from, however, this point was _only_ meant to show that _any_ crazy camera setup the user wants to make should be inclusive enough take into account the "Game" view as well.

There are multiple places in the world that a user might like to keep an eye on simultaneously (while using multiple versions of the fully-rendered "Game" view).
In a more practical example, I have used this technique before to help setup shots and "wow" moments for a particular level/environment. It's very hard to see if you've affected, say, the visibility of important set-pieces by placing unintendedly-contrasting elements for particularly important camera shots in a level without referencing multiple secondary (in-game) camera views like this.

Again, like I clarified at the start of this post, this is not always the case.
The number of useful camera views is fluid.
I have proven the necessity for this 'fluid' approach to cameras with Snapcam.
There is plenty of value in being able to show/hide and quickly manipulate whatever (type of) camera view you want -- when you want to -- and reference those particular viewpoints (immediately) for however long you like -- And, as I've shown above -- while the 'Hammer' style workflows are incredibly important to some people still -- my suggested approach has nothing to do strictly with grayboxing workflows.

Besides, four (simultaneous) visible cameras is not comfortable (or performant enough) for everyone.

In fact -- I nearly abandoned 3D modeling entirely because of this terrible workflow being forced upon me in the 90's.
The moment I found a tool that allowed me to change my viewpoint quickly (even if it was just changing my entire workspace layout) at the press of a shortcut so I did not _have_ to use all four views, I was good to go.

I could easily graybox with this single-camera approach (even way back then).
So suggesting or implying that the "Hammer-esque" four-camera layout view is the ONLY way to do grayboxing is both limiting and _very_ misleading.
Not all modelers use the same workspaces / methods / approaches -- and as such -- rather than excluding someone who prefers the (imo, very outdated) Hammer layout/workflow (and forcing its cons on others), I have suggested a way to improve the overall workflow and UX while not excluding _any_ possible workflows in my suggestions above. I have only offered options to improve them (in their entirety) for everyone involved.


And just because I think you meant this in a constructive / positive way:

I see where you're coming from -- but this is difficult to do when sometimes (for the sake of brevity) I've missed an explanation for my thinking or reasoning, and then someone (like you have demonstrated above) calls me out on something (usually unconventional) because my explanation doesn't exist (or make sense to them) -- instantly judging it as "bad" (or "dumb" -- as you put it) without any further questioning. :/
As I've stated before -- if someone doesn't want to read my posts, I'm not forcing them to.
(In fact -- if one doesn't have time to read and properly ingest them, I would prefer one please don't read or "respond" to my posts.)
In general, I've got no obligation to cater to anyone who can't be bothered to carefully listen to the thoughts and feelings of others. There are plenty of people (I thoroughly respect more) who take time to carefully seek the value in what insight others can offer -- and it is for those kind people that I bother sharing my thoughts at all.
In other words -- "Nothing ventured -- Nothing gained." as some might say.




-----

You might have missed some important information.
I am in no way suggesting to take this possibility from you -- I am only suggesting to evolve it.

See my quote from above:

Which, by "overlay" -- I mean an overlay containing a "camera view" -- which can be scene _or_ game camera.

This "overlay" is likely a "topdown" and/or "side-view" (_in_ a separate EditorWindow) -- exactly like you suggest.


If you don't believe me -- the following bit explains the concept further:

Maybe that clears up this (weirdly viral) misunderstanding.

 

This is pretty neat.

I've been using reflection in our current project (2020.2) to use the internal SceneViewOverlay/OverlayWindow stuff to add stuff to the scene view. Getting it to work was a bunch of annoying reflection work and refactoring to get a comfortable API to work with, but I think we got there.

A very simple one we have is one that just draws a bunch of commonly used shortcuts:

Spoiler: Code

Code (csharp):

1.  
2. using UnityEditor;
3. using UnityEngine;
4.  
5. public class ShortcutDrawer : OverlayWindow {
6.  
7.     private static ShortcutDrawer instance;
8.  
9.     [MenuItem("Window/Teslagrad 2/Toggle Shortcut Panel #s", false, 7)]
10.     public static void ToggleShortcuts() {
11.         if (instance == null)
12.             instance = new ShortcutDrawer();
13.         instance.ToggleVisible();
14.     }
15.  
16.     private ShortcutDrawer() {}
17.  
18.     protected override GUIContent Header { get; } = new GUIContent("Shortcuts");
19.     protected override bool CanCollapse { get; } = false;
20.     protected override void DrawWindow() {
21.         DrawShortcut("This Panel",         "Shift+S");
22.         DrawShortcut("Quick Search",       "Alt+Æ");
23.         DrawShortcut("HyperScene",         "Ctrl+H");
24.         DrawShortcut("Visibility Panel",   "Alt+V");
25.         DrawShortcut("SpriteShape Editor", "Alt+S");
26.         DrawShortcut("Selected->Mouse",    "AltGr+M");
27.         DrawShortcut("Clear Console",      "Ctrl+Shift+K");
28.     }
29.  
30.     private void DrawShortcut(string label, string shortcut) {
31.         const float labelWidth = 120f;
32.         const float shortcutWidth = 80f;
33.         using (new EditorGUILayout.HorizontalScope()) {
34.             EditorGUILayout.LabelField(label, GUILayout.Width(labelWidth));
35.             GUILayout.FlexibleSpace();
36.             EditorGUILayout.LabelField(shortcut, GUILayout.Width(shortcutWidth));
37.         }
38.     }
39. }

Recreating the same thing as an overlay was very easy:

Spoiler: Overlay Code

Code (csharp):

1.  
2. using UnityEditor;
3. using UnityEditor.Overlays;
4. using UnityEngine.UIElements;
5.  
6. [Overlay(typeof(SceneView), "rain_shortcutOverlay", "Shortcuts")]
7. public class ShorcutOverlay : Overlay {
8.     public override VisualElement CreatePanelContent() {
9.         var root = new VisualElement();
10.         root.style.flexDirection = FlexDirection.Row;
11.  
12.         var labels = new VisualElement();
13.         var shortcuts = new VisualElement();
14.  
15.         root.Add(labels);
16.         root.Add(shortcuts);
17.  
18.         labels.style.width = 120f;
19.         shortcuts.style.width = 80f;
20.  
21.         AddShortcut("This Panel",         "Shift+S");
22.         AddShortcut("Quick Search",       "Alt+Æ");
23.         AddShortcut("HyperScene",         "Ctrl+H");
24.         AddShortcut("Visibility Panel",   "Alt+V");
25.         AddShortcut("SpriteShape Editor", "Alt+S");
26.         AddShortcut("Selected->Mouse",    "AltGr+M");
27.         AddShortcut("Clear Console",      "Ctrl+Shift+K");
28.  
29.         return root;
30.  
31.         void AddShortcut(string label, string shortcut) {
32.             labels.Add(new Label(label));
33.             shortcuts.Add(new Label(shortcut));
34.         }
35.     }
36. }

This is for sure an improvement. We don't have to remember a shortcut, and we can place it wherever. The only thing I like less is that the header is left-aligned instead of centered, but I can live with that.

The API

Thoughts:
- Maybe always show the areas you can dock an overlay when you move it, instead of just when you're over the area? That'd make the different docking positions much more discoverable.
- The overlay menu that pops up when you hit space should be movable. I instinctively tried to move it out of the way of some overlay in order to see which ones were open, couldn't do it.
- I think it should be easier to expand/collapse/hide overlays. The right click is fine, but a bit clunky. The best way would be to simply hit "space" when you mouse over a specific overlay to expand/collapse it. Alternatively, double-clicking the header could do the same.
- It's very easy to find overlays, since the list of overlays you get when pressing space is very small. Conversely, the Window menu is a labyrinthian nightmare that you never find anything in. I assume there will be more overlays after a while and we'll run into the same problem. The overlay menu should have a search field to alleviate that problem. Ideally opening the menu and writing text would immediately enter into the search field, so you don't have to click in it.
So toggling the "Orientation" Overlay would be achieved by hitting space-o-r-i, which would filter the list and make it easier to click.


Overall a great feature, looking forwards to having it in a mainline version.

EDIT: More feedback:

I tried to make an EditorWindow that : ISupportsOverlays, and there's a few issues. Overall it's great, but;
- Why is the "Tools" Overlay marked as "available for all windows"? I don't need the move tool in my editor window!
- The search tool is also available, but doesn't draw anything. It'd be really great if editor windows that ISupportsOverlays could somehow use the search Overlay by handing it stuff to search through
- When I close and open a specific editor window type, I expect Unity to remember how I've set up the tool windows inside that window.
- The built-in EditorWindows (Inspector, Project, Console, Hierarchy, Animation, Animator, etc.) should all have the interface implemented, so we can put our own Overlays in them.
- When we have an Overlay inside one EditorWindow, we should be able to drag it into a different EditorWindow, if that other EditorWindow is also supported by the Overlay.

 

I did not get what I was supposed to be doing. Just faff around with the overlay build? Either I missed something, or I need more specific tasks.

 

Mostly in order to be free to do it if we found a use-case. I was assuming that if there wasn't any registered, there would only be a tiny little cost when I hit space with the mouse over the inspector, and the inspector has to check if there's any registered.

That being said, space does have a meaning for the inspector (open a menu for the currently selected object field), so now there's a conflict that has to be resolved... So idk about that one.

For the project view and the hierarchy, custom, easily available search and creation tools, history, etc.

For the game-view, toggles for visualization and debug tools. A "go to level" or "reset level" button could go in here, together with things like velocity or fps readouts. I can currently put those in in-game UI Documents (or uGUI canvases), but those things interact with gameplay stuff in unpredictable ways, and are not as easy to find as "press space".

For other windows, it's an easier way to add functionality, as right now new functionality needs to live in [MenuItem]s that people just never find because the toplevel menu is global. One thing I often want in the animation window is to make some curves I have selected match each other, or insert keys for properties that are animated in the other animations that are selected. It'd be easier to find such tools if I could just dump them in as an overlay with buttons.

etc. etc.

- That's not something people will remember to do. You'll close the window, open it, and go "damn, I should have set the preset".
- It's also not discoverable at all. I have never in my life seen a non-programmer used that dropdown unless a programmer asks them to.
- It's also likely not what we want, usually when we open a window that we've closed recently, it's because we want to go back to what we were doing. That doesn't mean that that's a preset we want forever.

I know that Unity is utterly and completely allergic to user options, but this is for sure somewhere it'd be great to be able to go "I want you to remember my window state when I reopen the window".

 

Additionally Suggest add support for windows in overlays not by pointing WinfowTypw but by pointing some interface type (Like IManipulationTools), and windows will set for itself what classes of overlays they support

 

That's probably not going to work very well?

When you write an overlay and say "this overlay is supported in these exact windows", then you can make sure that those windows are indeed supported.

If you write an overlay and instead have to say "this overlay belongs to this set of overlays, and is supported in all the windows that wants that set of overlays", then it's a lot harder to know that things are supported well.

So you get in situations where you make an IManipulationTool overlay because you're making a tool for manipulating stuff in the scene view, and some tile system with a custom window has that window support IManipulationTools because it uses the normal manipulation tools, and if some user gets both, they get a window and overlay that claim that they work together, but totally does not.

 

Agree with you but

How can we create say SelectedAnimationDetailsOverlay that will support not only few hardcoded windows but all windows that implement

ISelectedAnimation {AnimationClip Selected {get;}}

So our overlay can just ask for selected clip through interface and show details.

Same with many overlays that just show info only if wondow provide that info.

Asset authors can create some fancy overlay that developer can add to window just by implementing interface.
Sounds logical too

 

I assume you can target interfaces with [Overlay]:

Code (csharp):

1. [Overlay(typeof(ISelectedAnimation ), "id", "Header")]
2. public class MyOverlay : Overlay {
3.  
4. }

If that's not currently possible, then @neil_devine, that's another piece of feedback.

I also assume that [Overlay] allows you to register an overlay for several things:

Code (csharp):

1. [Overlay(typeof(SceneView), "id", "Header")]
2. [Overlay(typeof(ISceneViewLike), "id", "Header")]
3. public class MyOverlay : Overlay {
4.  
5. }

If not, you could have two different empty overlays that inherited from MyOverlay and target each, but that seems like a silly requirement (ie. it would be silly if [Overlay] had AllowMultiple set to false)

 

Oh, it was completely obvious how I moved on to the next task. Managed to do that on the first try. That was not a problem at all, and UserTesting seems great. The problem was that I had no idea what the task was. Like not even slightly.

The first task is "try to complete a few workflows for as long as you'd like". I know what a workflow is, and it's not something you "complete". So task 1 seems nonsensical? I mean if I stretch my imagination, it might be that you were asking me to do things I'd normally do, but interacting with the overlays instead of how I'd usually do it? But, like, no, no clue.

Task 2 is answering "How did this overlay feature behave relative to your expectations?", which was hard to answer since I had no idea what I was supposed to be doing during task 1, so I skipped it.

Task 3 is "Please try to set up one (or a few) overlay configurations within the scene for your necessary tools and options." And I'm still not quite sure what that is. Should I just make some random overlays? Or do you want me to like move them around in the scene view (as a configuration)?

Then Tasks 4-6 asks about task 3, which again becomes hard because I couldn't do it because I didn't understand it.

Task 7 is "Try to hide all of your overlays". That's the first one where I'm confident that I understand what's being asked of me. When I got there and had answered "what am I supposed to be doing? help?" on all the other questions I just gave up.


So... yeah. Maybe somebody else gets it, but I can't help you at all using the current setup. I've got a feeling that the questions are just not very well thought through, but it might just be me being dumb, idk. Did you try having somebody internal do the activity?

 

Honestly, I'm not sure what Unity's "user feedback" is really for.

Everything Unity asks for feedback on is either extremely haphazardly thrown together, not very well thought through -- or missing information and foresight (as it appears in this case), including it usually being next to impossible for feedback (especially the more technical kind) to reach the proper audience who can actually understand enough about it to ask the right questions -- and know how to use said feedback.


As far as this current bit on Overlays -- the best feedback I could give Unity is mostly what I've already given (that is -- a simple design that covers 90% of use-cases of the Overlay system -- IF it is used as part of a more holistic environment for tools).
Perhaps I could draw out a diagram or something to better show how I want my tools to relate to the Overlay System, however, the inherent problem with _that_ approach is that my tools (and the way I use them in Unity) must be approached in a holistic way (which is dependent upon Unity's current goal -- to which I am not privy to). Simply asking my opinion on whether this UI control is better than THAT method of UI manipulation seems pretty naive to me at best -- and flat-out stupid at worst. How the hell would I know which control method would be better for me when I have no idea how the system itself is intended to work? -- My design cannot account for that hidden information, which could change my whole design for the tool, depending on how the other parts of the tool / workflow are designed!!
As someone who has spent the last 25 years + researching user-experience across thousands of tooling designs, I can confidently say that this approach to understanding and gauging user experience and expectations by use of specific user interfaces and user opinion sucks. And the reason why is that this method ignores the underlying problem of collaborative design -- the problem being how the hell Unity themselves plans to actually _use_ overlays -- and whether or not that is anywhere close to consistent with what the users themselves actually want in the design? Which requires detailed, back-and-forth, communication -- and a proper (and varied!) set of design possibilities.

A better approach to user-feedback is to simply ask users what they're looking for in the design of an Overlay system -- and even ask if the users themselves have designs they'd like to offer to be considered.
At this point, Unity should have a MUCH MUCH better idea of what users would be looking for, after pouring through many different designs and flowcharts.

This is what's called asking for understanding -- since you're not going to get understanding asking for data alone.


At this point, Unity is no longer going to "copy" other tools (which was a huge problem with Visual Scripting's design, I might add) -- Instead, it can create its own (unique) design that encompasses everything necessary to create a coherent tool that correlates with the overall (relevant) goals of each user's proposed design as much as possible.
Ideally -- in order for users' voices (and suggestions) to be heard -- they should be willing to offer a clear enough vision and help Unity muddle through some of the design questions and feature / structural conflicts your engineers might have. The above, in my experience, is the best use of your community's feedback.

 

Any updates regarding this topic?

 

Will there be any preview builds be available in the meantime?