Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Official Overlays Public Build Available

Discussion in 'Editor Workflows' started by gabrielw_unity, Dec 8, 2020.

  1. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    963
    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!

    Awesome, where do I start?

    First, watch the latest tutorial video:


    Second, download the public build:
    https://beta.unity3d.com/download/6b194544ede6/public_download.html

    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:
    https://forum.unity.com/threads/overlays-developer-guide.1018855/

    That’s all for now - looking forward to hearing from everyone soon!
     
    Last edited: Jan 21, 2021
    keni4, cxode, Alex-Vertax and 14 others like this.
  2. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    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.
     
    mariandev, frarf, Orimay and 2 others like this.
  3. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    -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 o_O
     
    Last edited: Dec 9, 2020
    gabrielw_unity likes this.
  4. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    -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
     
    gabrielw_unity likes this.
  5. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    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.
     
  6. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    This is something we are considering. Please share your intended use.

    We have also identified this need.

    This is a known issue, we will add known issues to the original post.

    This is not new behavior, tools were always global, we will consider this in the future though.

    We are looking in to this, it has been an issue for layouts, window presets have just made this more apparent.
     
  7. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    We are considering solutions to this right now.

    Thanks for reporting this, we didn't catch this one.

    @Ruchir thank you for all this great feedback !
     
    Ruchir likes this.
  8. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    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.
     
    Orimay likes this.
  9. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    It is planned for that overlay specifically, for any user created overlay you have full control over styling to do as you see fit.
     
    mariandev, frarf, Orimay and 3 others like this.
  10. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    @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. :)
     
    Last edited: Dec 10, 2020
    frarf and gabrielw_unity like this.
  11. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    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.

    6- Not planned as of yet.
     
    awesomedata and gabrielw_unity like this.
  12. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    963
    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.

    6. 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.
     
    mariandev, Orimay and awesomedata like this.
  13. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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.
     
    Last edited: Dec 12, 2020
    frarf likes this.
  14. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    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
     
    frarf and JesOb like this.
  15. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    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
     
  16. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    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
     
  17. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    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.
     
    frarf and awesomedata like this.
  18. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    Totally agree.
     
    frarf and Ruchir like this.
  19. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    Thank you for reporting this
     
    frarf and Ruchir like this.
  20. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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.
     
  21. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    963
    Hey @awesomedata ! That's a lot to digest ... let's see -

    Regarding multiple scene views: generally, I would argue that multiple scene views is required, for example when modeling/assembling a world, and you need a mix of perspective and ortho views to line things up without switching views. I'm a huge fan of hot-swapping views, but sometimes you absolutely need to see both at once.

    However ... in theory, this could be solved by allowing you to open "picture-in-picture" additional Scene Views, as overlays themselves. So that's interesting for sure, as one possible workflow.

    Regarding the Grid - yes, that's something the UI Toolkit team is aware of, I've personally brought it up as well ... as a standard CSS thing (apparently), it seems logical and clearly useful. Can't promise anything of course, different team :)

    Regarding resizing Overlays - yup, another item that we know would be useful, but adds another (messy) dimension of complexity. Definitely on our radar, especially as Shader Graph, etc already do have "resizable overlays", so that's a feature need if they pick up our system.
     
  22. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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:

    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! :)
     
    Last edited: Dec 11, 2020
  23. mgear

    mgear

    Joined:
    Aug 3, 2010
    Posts:
    9,350
    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)

    upload_2020-12-11_11-28-44.png
     
  24. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    963
    Hi @mgear !

    Orientation - everything is changing to a Floating Window, nothing will be spared ... because otherwise it would conflict with the overall system. However, yes we are ensuring that it will look the same as before (no title, no background).

    Spacebar Window - noted, thanks

    Overlay position reset when key is pressed - yes, the idea is sort of a "cancel movement". Perhaps it should be limited to certain keys.

    Toggle all on/off - yes, this is planned, however ... could you describe how you would expect it to behave, with some scenarios? I'd be interested to know if our expectation match. Thanks!

    Multi-border - are you able to get repro steps? I'll check too, thanks.

    Arrow keys - I'm not sure we can control this, but it's important for accessibility, will look into it and get a solution.

    Moving Play/Pause/Etc into Scene View - we want a very clear separation of "Global" items, so moving those into the Scene View is not something we would do. However, we are hoping to make that possible via customization of the main toolbar, certainly :)

    Grouping Overlays or Toolbar contents - yup, it's on our minds, but hasn't been planned out or designed. Can't make promises, but I do think we'll get there, in a version or two.

    Thanks for the feedback!
     
  25. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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! :)
     
    JesOb and Ruchir like this.
  26. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    963
    @awesomedata - regarding cameras, I think I get where you are going, and I like it ... to my personal preference, anything that helps me keep focused on what matters (generally, the scene view), is a good thing :) I really dig your ideas of quickly popping up new camera views, swapping the "focused" one, etc. Good stuff!

    for the tool inspector - have you seen the new Tool Ecosystem post + video? Sounds like you'll like this update very much: https://forum.unity.com/threads/draggable-overlays-custom-toolbars-new-tool-systems.995989/

    Messy overlays with resizing - yes, it's mostly the issue of resizing docked stuff and that shoving around the other docked items ... actually, this isn't really an issue with the version we landed on, because we just let stuff get pushed around and potentially truncated, there's no attempt at "safe guarding", so there's nothing to "get messy". In the original design, we had some fairly elaborate systems to ensure overlays were never just truncated ... so, yes, I'm talking myself back into resizing being much simpler to do ... assuming we don't hear from lots of folks that the truncation is an issue :)
     
    awesomedata and JesOb like this.
  27. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    963
    @awesomedata - oops, I didn't see that new post :)

    Toggling the View Gizmo - hmm, maybe, if there were a good reason. Just can't think of one :p I mean, heck it could just be a style (available just like "vertical, horizontal, panel" are now). But ... is there a case where you would definitely want to have that messy background + title? Does it provide any special value?

    Dragging overlays out - yes, this has bounced around quite a bit and we hear it a lot! So the first thing we're really aiming for is to solve the "consistency, context" issue that Unity has. Which means pulling Overlays out (breaking context) is a no-no. But, like your second monitor example, there are 100% great functional reasons to do this. So I do think we'll dedicate time to making it possible, without totally breaking that clarity of context. Won't be easy though.
     
    awesomedata and JesOb like this.
  28. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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!! :)
     
  29. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    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
     
  30. frarf

    frarf

    Joined:
    Nov 23, 2017
    Posts:
    27
    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.
     
    Last edited: Dec 12, 2020
    awesomedata and Ruchir like this.
  31. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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! :)
     
    Last edited: Dec 16, 2020
    frarf likes this.
  32. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    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).
     
    frarf and Ruchir like this.
  33. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    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
     
    Last edited: Dec 13, 2020
  34. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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.
     
    Last edited: Dec 14, 2020
    Ruchir likes this.
  35. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    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:
    thRGrDSSRt.gif

    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:

    sAjHWT25J8.gif
    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.
     
    Last edited: Dec 20, 2020
    awesomedata, Ruchir and JesOb like this.
  36. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    awesomedata likes this.
  37. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    Thanks for the feedback, these are all things on our radar, great to get some confirmation.

    - Tools are global currently, should you create a window that requires the tools they should be available to you. That said they should not appear in your window by default, that is something we should address.
    - Also a bug, good suggestion.
    - The current behavior of unity with respect to windows is the same for all windows, if you close it you lose all customizations of it. To mitigate this we introduced Window Presets that behave identically to layouts but just for a window. You can access them through the triple dot menu, or the overlay menu. Saving to the Default preset will guarantee your overlay layout will be restored on reopening the tab.
    - Overlays incur an overhead that we did not want to force on anyone unnecessarily, and the whole system does not necessarily make sense to have in all types of windows (floating overlays in the inspector for example ). Could you provide us with some examples of uses you would have if overlays were accessible everywhere ?
    - noted
     
  38. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    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".
     
    JesOb likes this.
  39. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,106
    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
     
  40. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    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.
     
  41. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,106
    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
     
    Last edited: Dec 22, 2020
  42. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    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)
     
    JesOb likes this.
  43. jwcaounity

    jwcaounity

    Unity Technologies

    Joined:
    May 6, 2020
    Posts:
    7
    Hello!

    I'm Rachel, and I'm a UX Researcher at Unity. Thanks for voicing your concerns.

    There are indeed specific tasks that come later, but the activity requires participants to do a little bit of exploration by themselves first. Unfortunately, the program we've designed the activity in (UserTesting) does not make it very obvious how to move on to the next task.
    When you begin the test, a small floating toolbar will appear that will give you a few options, as well as the task at hand.
    upload_2021-1-4_10-39-55.png
    Once you've finished the task, you can click the button on the left to expand the toolbar, which will allow you to progress to the next task, as well give you an opportunity to leave your feedback along the way.

    If anyone has any further questions, feel free to send me an email at rachel.cao@unity3d.com! I'd be happy to walk you through the process.
     
  44. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    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?
     
    awesomedata and JoNax97 like this.
  45. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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.
     
    Ruchir and JesOb like this.
  46. jwcaounity

    jwcaounity

    Unity Technologies

    Joined:
    May 6, 2020
    Posts:
    7
    Hi again,

    Thanks for your feedback; we will happily adjust the wording of some of the tasks (particularly 1 and 3).

    For reference, Task 1 is indeed to do what you'd normally do, only with overlays, which you were spot on for. Task 3 is to configure the overlays in a way for you to display all pertinent tools and options.

    Unfortunately, we did have to rely on an unmoderated testing format, which makes it extremely difficult for us to troubleshoot participants if they run into issues. This is definitely less than ideal, but even if not all tasks were understood, it's still valuable for us to review the participants' behaviour (captured through the screen recording), to see how they interact with the tool.

    Hope this helps! Once again, if you have any further questions, feel free to send me an email at rachel.cao@unity3d.com
     
  47. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    Any updates regarding this topic?:)
     
  48. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    Hi ! Were you looking for any specific information ? We are taking note of all the issues and great suggestions from here and other places. Current target is 21.2 release.
     
  49. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    934
    Will there be any preview builds be available in the meantime?
     
  50. neil_devine

    neil_devine

    Unity Technologies

    Joined:
    Apr 8, 2018
    Posts:
    42
    We will post here once the feature lands in the 2021.2 alpha stream, there will be no other preview builds between now and then.
     
    mariandev likes this.