Hello everyone! We are very excited to announce, we now have a public build available to try out the new Overlays system!
Important Disclaimer: This is an early test build. The development and release of this functionality and its features are not targeted for the 2021.1 release and are subject to change. Please do not make any purchase or upgrade decisions based on this test build. It has several known issues that the team is currently working on. That said, your early feedback is important to us, so weâre sharing it with you now and look forward to your input!
Third ⌠explore, experiment, and return here with your thoughts, questions, etc
Wait! Iâd like to give even more feedback!
Thatâs great, thanks very much! We are also running a user experience study, which basically means a screen-recorded session where youâll walk through a series of tasks, and provide specific feedback. It takes about an hour, and is a great help for us to have solid data points regarding how you are using the tool, what issues you encounter, etc. As a bonus, participation in this study will make you eligible to receive some Unity swag.
(Please note that participation in this study is not paid. These tasks are meant to be a prompt to help you explore the tool better, and participation in the study helps us collect data that could help improve the experience for all users. We are sorry for any inconvenience this may cause.)
Sound good? Send me a direct message via the forum here, thanks!
Iâm a developer ⌠can I start making Overlays now?
So glad you asked. Yes you can, and weâd really, really dig seeing what you create, how the process works for you ⌠and maybe youâll even post your creations here, for others to download and try out as well.
You can find a quick-start developer guide in this post:
Thatâs all for now - looking forward to hearing from everyone soon!
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
Thanks for the encouragement. If I understand the question correctly, yes you can already hide any panel you wish. We do plan to have this particular panel have a custom transparent background so it looks like it used to.
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.
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?)
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?)
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).
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.
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?
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.
1- This is entirely built with UI Toolkit, therefore through styling you can control anything you wish for the overlays you create yourself. There are 3 forms, we call them horizontal toolbar, vertical toolbar and panel (dropdown uses panel ), you can provide their content individually and apply whichever styling you choose.
2- The system overlays a Visual Element on top of the Scene View, they donât currently know of each other. So right now they work independently.
3- That would require a concept of configurations, if you mean to tie it to the Window Preset, that is something we need to consider with respect to Shortcut Contexts.
4- Could expand on what you mean by âgrid styleâ I am not sure I understand ?
5- Scrollwheel should behave as it currently does for text input fields anywhere else in the editor.
Hello! Thanks for all that feedback! Neil answered it all way better than I could have
Specifically for @awesomedata :
4. Grid - this has bounced around in the design, yes. Assuming you mean something like moving your overlays around as if they are UI elements on a canvas, snapping to each other/grid? The main reason we moved away from it, and over to docking/toolbars, was that the grid wasnât able to handle adding/removing elements and the resulting shuffle of overlays, at least not as well as a minimal docking/toolbar system.
Runtime - has also been my mind personally Iâd love to see this somehow available at runtime, yes, for debugging etc ⌠wouldnât be on Scene Toolingâs plate, but Iâve definitely been shopping this around.
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:
public override VisualElement CreatePanelContent()
{
var myContent = new VisualElement { name = "my-content" };
var button = new Button(() =>
{
Debug.Log("Panel!");
});
button.text = "Press me!";
myContent.Add(button);
return myContent;
}
public VisualElement CreateHorizontalToolbarContent()
{
var myContent = new VisualElement { name = "my-horizontal-content" };
var button = new Button(() =>
{
Debug.Log("Horizontal!");
});
button.text = "Press me!";
myContent.Add(button);
return myContent;
}
public VisualElement CreateVerticalToolbarContent()
{
var myContent = new VisualElement { name = "my-vertical-content" };
var button = new Button(() =>
{
Debug.Log("Vertical!");
});
button.text = "Press me!";
myContent.Add(button);
return myContent;
}
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
Ok I see, currently we donât support panel resizing, if we do then again the content you put in the container is entirely up to you and it should be relatively simple for you to make a container that does all the nice things you mention.
Drag and drop between the Scene View and the Overlays was not something we thought about, taking note.
Shortcuts is something I would like to address. Taking note of your workflows.
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:
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).
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)
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).
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).
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).
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.
Keeping track of individual âToolâ states would also be much simpler â both for the @ devs as well as the tool developers actually using/designing the overlays / EditorTool approach.
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.
