Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice
Dismiss Notice
Join us on Dec 8, 2022, between 7 am & 7 pm EST, in the DOTS Dev Blitz Day 2022 - Q&A forum, Discord, and Unity3D Subreddit to learn more about DOTS directly from the Unity Developers.

Official Draggable overlays, custom toolbars, new Tool systems

Discussion in 'Editor Workflows' started by gabrielw_unity, Oct 28, 2020.

  1. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    Update:
    Public build is now available:
    https://forum.unity.com/threads/overlays-public-build-available.1018858/

    Also, for devs, a quick-start guide and discussion post:
    https://forum.unity.com/threads/overlays-developer-guide.1018855/
    ---

    Hey folks! We're making major changes to overlays, toolbars, and tool systems in general for (EDIT) 2021.2 - should hit the alpha soon, now's your chance to get feedback in early. We'd really appreciate it, and your input absolutely will help us to do this right. Thanks!

    I originally posted in the World Building section, links to those posts below, but feel free to discuss here as well, both locations are fine.

    New Tooling Ecosystem (forum thread)


    New Overlays and Toolbars (forum thread)
     
    Last edited: Dec 8, 2020
  2. Scorr

    Scorr

    Joined:
    Jul 2, 2013
    Posts:
    72
    Looks great, is there any plans to support these in builds as well? Using the same debug tools/overlays at runtime would be a huge benefit.
    Considering UIToolkit is going to support runtime, and this seems to be making use of UIToolkit, maybe we could access the container so that we can display it at runtime ourselves? Would be neat if possible.
     
    SisusCo, Bastienre4, Jes28 and 5 others like this.
  3. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    Thanks Scorr, glad you like it. About runtime - agreed, that would be great for in-game debugging/etc. I'll check with the team!
     
    Orimay, SisusCo, Bastienre4 and 2 others like this.
  4. tonycoculuzzi

    tonycoculuzzi

    Joined:
    Jun 2, 2011
    Posts:
    299
    this looks VERY promising, I'm excited! :eek:
     
    futurlab_xbox and gabrielw_unity like this.
  5. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,313
    Please turn this thread into a sticky, so it won't get lost. Everything in those videos look great, all thumbs up. Out of curiosity, how long did it take how many people to get this far?
     
    Orimay, Neonage, NotaNaN and 2 others like this.
  6. Crayz

    Crayz

    Joined:
    Mar 17, 2014
    Posts:
    187
    Looking forward to these changes!
     
    gabrielw_unity likes this.
  7. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    789
    Things are starting to get closer to the UI Mockups for a few years back. My body is ready.
     
    Orimay and JoNax97 like this.
  8. pvloon

    pvloon

    Joined:
    Oct 5, 2011
    Posts:
    591
    That looks super promising! I think that'll be a big boon for lots of editor tooling & third party packages. One question though, if you at this image: The pink space is unused. The pink underline is for buttons I never use. Layouts could be a dropdown along the other menu items. The play buttons could go... somewhere. To me that's awfully close to freeing up that entire bar of space! Now just combine that with incorporating the menu items with the title bar, and we're really in business.
     

    Attached Files:

  9. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    646
    Both layouts and layers would be 10x more useful if they were small dockable windows, layers could even be an overlay of the scene view (as there is no utility outside there).

    Play, pause and step button could be on both Scene View and Game View top bars

    Collab and services have their own windows already, no need there.

    Account could be on Help menu together with Manage License.

    Yeah, let's get rid of that top bar!!
     
    Orimay, stuksgens, Ruchir and 4 others like this.
  10. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    @brunocoimbra and @pvloon - yes! We're looking toward very much that. There are some ideas like Workspaces that could make that top bar genuinely useful, or simply clearing the whole bar out. Agreed on the pink squiggles.

    Of note, we have already made that toolbar customizable via code, and the next step is to make it something like the chrome/firefox/etc toolbar, where you can right-click and place quick shortcuts etc. That'll make it very useful :)
     
    Orimay, Nexer8, majorgrubert and 10 others like this.
  11. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    Sticky: I don't have that kind of power here ... only in the World Building forum ... but I'll find someone who can do this, yes!

    Time: Tough to say exactly, we're a small team (3 devs at the moment, but have had help from others), and as a core team we also shift into helping other areas frequently. Overlays actually had a start-then-crash, about a year ago ... other parts have been slowly building up as we go, over a few years. Putting the pieces into position now, with help from things like Overlays to ensure it's not just an API update, but instead a fully realized "ecosystem" :)

    We also have some really exciting ProBuilder updates dropping soon, so it's not all foundation work to show ;)
     
    Orimay, Bastienre4, Neonage and 6 others like this.
  12. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    187
    Looks nice AND sensible (heck, I wish I could say the same about other parts of unity...).

    Any plans for the "status bar"? I'm not really fond of it tbh, vertical space is a premium.
     
    DoctorShinobi likes this.
  13. pvloon

    pvloon

    Joined:
    Oct 5, 2011
    Posts:
    591
    Nice! Personally probably would be happiest to just have the space back, but quick shortcuts in that bar sounds like a great use. If shortcuts become a thing it'd be great to bind MenuItems there, as I think lacking those currently lots of assets put shortcut like things there.
     
    Ruchir and NotaNaN like this.
  14. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    313
    This is incredible!
    I feel like Unity is finally becoming modern!
    @gabrielw_unity, where were you all my life? We needed this years ago! :D

    Really though, there are reasons I stick with Unity through all the countless errors, half-baked features, and questionable management — and this is one of those reasons. :p

    Now not to get off-topic or anything — but since you seem like you'd possibly be the guy to know, are there any plans to rethink the Inspector? I really need tabs to sort my Components by specifiable and customizable groups or I'm going to die. o_O

    Also, @awesomedata, I think you're going to like this thread. :D
     
  15. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    799
    Thanks for sharing those videos.
    I think mostly this feels fine (and getting tools to be consistent is important), but I have some questions / notes:

    Conversion path for existing tools. I tried to get a few people onboarded to the EditorTools API, and many mentioned that they do not want to (right now) support something that they cannot easily integrate, as turned out for the EditorTools API.
    I tried porting some of our own tools over to this, and the issue here is that often "tools" are implemented on top of Components / MonoBehaviours, and are thus very context-specific to the selected components. At least from my tests so far it didn't feel "easy" to make these use the new API, mostly because an "EditorTool" has no understanding of selection per se and it seems quite a bit of boilerplate needs to be implemented just to "forward" a tool command to a specific, currently selected component or set of components.
    So the question here would be: are there samples for component-specific tools and how to implement them properly? Or, to put it differently, can I tap into the EditorTools API from a custom inspector directly, instead of having to make an EditorTool that then somehow figures out what is selected and provides the right details?

    Shortcuts. It seems this is a missing key piece from the videos: shortcuts are important for specific tools and scenarios, and current solutions like the Shortcut Manager only deal with global shortcuts, not context-specific ones, those are "on the roadmap" for a long time now and nobody seems to be working on it. It seems from the 2nd video that you're in fact planning for Shortcut Manager integration, but this would be a big issue I see with that.
    I do not want to remap a million keyboard keys and make sure that they don't overlap as is the current situation with tools; I just want shortcuts to be forwarded to whatever tool is active and handle them there, and then they can "bubble through" to the rest of the editor if they aren't handled (just one way to deal with this, there are surely more).

    Multiple Scene Windows. One big advantage of the tools section being at the top was that screenspace was saved, all scene views stayed clean. With the tools section moving into the scene view, what happens when I have multiple scene views open? Do the tools jump around with me? What happens to that "floating thing layout" I manually did by positioning them with scene views of different sizes? Or, in the case that each scene view comes with its own configuration, can I copy / paste configs to other scene views?

    Contextual Tools. As mentioned in the "Conversion" question already I believe most tools are very context-specific. How will the screen space be leveraged for those? If I have 10 different MonoBehaviours that come with different sets of tools that are just relevant to them, it seems like I would be wasting a ton of screenspace by always having to have all their tool containers open, or I would need to constantly reconfigure my scene view to show just the tools that are relevant for that selected object. As mentioned before, it would be great to have the option to use the EditorTools API directly from a custom inspector and configure what is shown there - as done today through hooking into OnSceneGUI, but my understanding is that you want to clean this all up and have everything go through the new API.

    Additional Customization and Tools that affect the project, not scene. There's more to the UI by now than just the scene view and tools section. I understand that these might be treated by different teams inside Unity, but as a user, I'd like to also configure/dock to e.g. the right side of the toolbar (the area where Collab etc are). This is especially true for those tools that are project related and not scene related.

    Looking forward to more details on those!
     
    Last edited: Oct 29, 2020
    Orimay, Tortuap, Ruchir and 2 others like this.
  16. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    149
    Wait, this is f*ing great. Wth. It is so much better than what I expected. You can even get rid of the annoying default toolbar I've wanted to destroy for years.

    I love this. Can't wait to see it alongside the better window management when that comes. Will be testing it out and reading some comments here, just wanted to say all of that asap, it took me by surprise and I really feel like saying something is good when I think it is.
     
  17. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,085
    Could we please dock tool bars in the top alongside the play buttons, unity cloud buttons, Collab buttons, and regular control buttons up at the top? It would be great to be able to dock custom stuff there.
     
  18. MrPaparoz

    MrPaparoz

    Joined:
    Apr 14, 2018
    Posts:
    156
    I'd very much like to have Workspaces and more functional toolbar. Changing Editor layouts with a click or kind of browser tabs would be perfect for any workflow I can imagine.
     
    babaukos, Orimay and AndrewKaninchen like this.
  19. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    732
    I'm using `EditorTool` at the moment, and i'm sorely missing callbacks to know when its been activated and de-activated. Is that something that will be added?
     
    Orimay likes this.
  20. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    799
    @TJHeuvel-net I believe you can use the EditorTools.activeToolChanged callback to do that. Example
     
    TJHeuvel-net likes this.
  21. usernameHed

    usernameHed

    Joined:
    Apr 5, 2016
    Posts:
    90

    Looking at my toolbar, you will see how much I am waiting for this !

    Also I use and abuse a lot of components tools (even on the native Unity components), combined with scene view Tiny Window, see the foldable "Extensions" on the Transform component:
    http://www.belfiore.ovh/devlogs/lock-children/lock-children.php

    I have multiple question:
    • We desesperatly need some API for some of the most common callback with global tools:
    - Callback when unity loaded (et all assembly / asset are loaded)
    - Callback when a scene open / close (editor + play)
    - CallBack when the project just recompile (it often break non serialized & non static tools)
    - When Entering / leaving play mode
    I know every of this callBack are currently there in unity (not for the "unity just loaded though...), but when I create a global tool, every time I have to create this different callBack (and with that, make the tool static... because these callback work for static tools)

    • Also, I would like a way to easly SAVE settings for my interlal tool settings. The only clean & stable way is to use EditorPrefs. (dynamic scriptable Object only for tools is hard to manage, we have to save an asset. This asset can move, be lost...)

    I have so much to ask, but I will control myself x) Keep working!!!
     
  22. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    732
    Thanks, looks useful! Also looks like a lot of code, a `SendMessage("OnToolBecameActive")` would still be preferrable.
     
    hippocoder likes this.
  23. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,357
    @LeonhardP pretty please? :) (sticky for the thread)
     
  24. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,962
    ScriptableSingleton looks like a good solution for this. You get to say where the file goes, if it's shared between team members or per-person, and then you just have a place to stuff arbitrary data.
     
  25. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,021
    Of course!
     
  26. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,313
    Isn't the new way to use the UserSettings<> class and UserSettings directory?
     
  27. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    799
    @Peter77 UserSettings is for user-specific settings (e.g. log in data, local disk paths, your personal preferences, ...). ScriptableSingleton together with the FilePath attribute provide a way to specify where that particular data goes (ProjectSettings, Preferences, and I believe also UserSettings) – but let's keep this thread about Toolbars and Tools :)
     
  28. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    146
    Will this type of functionality be coming to windows like Shader Graph, VFX Graph, etc? Or is this just for the scene view atm?

    I personally don’t like the always-floating panels in Shader Graph, and being able to dock panels would be so nice
     
  29. antoinebr_unity

    antoinebr_unity

    Unity Technologies

    Joined:
    Nov 16, 2018
    Posts:
    22
    @fherbst It's currently possible to define a target type in the EditorToolAttribute. Doing so makes the EditorTool targets point to the components of that type in the selection (same targets as an Editor of that type). If your use case still makes it hard to convert to the new system, we can discuss this further in a separate thread on the World Building forum. We really want to make the conversion as easy as possible, all feedback on it is really appreciated. We had to convert a lot of internal tools to EditorTools so we tried to simplify everything that was slowing us down so it, hopefully, wouldn't slow users down :).
     
    JoNax97 likes this.
  30. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    Thanks! We have plans to make the status bar genuinely useful - sort of a "helper bar" that informs you of what actions/etc are available to your current context, tool, hovered, item, etc. Would work across all windows, because they all have hidden functionality (ie, did you know that holding ALT while clicking a hierarchy fold-out will also toggle all it's children?)

    Thanks!

    We've been in close contact with them (and other "canvas style views") since starting this, making sure this will be possible. The Overlay system is generic, so in theory yes, probably with some tweaks per-view - ie, Graph needs the ability to resize an Overlay by pulling on a corner, etc. Anyway, for now it's just Scene View (call use the early test subject :D ), and then yes we expect to have this or variants of this rolling into other views! It's really important that you can learn Overlays in one view, then apply that knowledge to all other views using Overlays.
     
    Orimay, Neonage, Ofx360 and 2 others like this.
  31. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    Yes! @willgoldstone has lots in mind for exactly this.

    Thanks, for the happy thoughts (cut from quote), and regarding Inspector ... sort of. There are thoughts, especially with the new Search system, to make the Inspector better. Nothing specific I am aware of though.
     
    Orimay, willgoldstone and NotaNaN like this.
  32. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    Yes! We are working with the editor core folks to work out exactly this issue. I don't have details, but it's moving forward!

    A large part of this I expect to be solved by something that @willgoldstone has been looking into, essentially grouping views together, so you could get both clear context (these tools apply to these views), and avoid repetition (just one toolbar, for multiple views).

    For now, we're going the route of "you decide" - every view can have it's own set of Overlays, so you can certainly show the Manipulation tools in just one view. Also, we're making the Overlays very easy to enable/disable, so you can work mostly with the bare minimum visible, then quickly (single key shortcut if you assign it, or via Overlays pop-up menu) get the tools/info you need, on demand.

    This isn't something I'm expecting to get right on the first go, to be honest ... it'll be an emergent thing, so we'll be watching and listening very closely! :)

    If I understand your question correctly - that should be handled by the Component Tools overlay. It is designed to always show any tools that are applicable only to your current selection (generally, "component" tools, but they can come from other sources, too). Is that what you are looking for?

    Absolutely! As part of moving the Manipulation tools out of that top toolbar, we also took the time to carefully re-write it with our new customizable toolbar solution. So that, and other toolbars, should eventually become similarly customizable. Not right away, but it's 100% where we are aiming.

    Thanks for all the detailed thoughts, hope I answered helpfully!
     
    Orimay, Neonage, fherbst and 3 others like this.
  33. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    1,528
    Thanks for sharing this. One concern I have is will all these improvement further slow down Unity editor more and more during opening the project and working on project as it seems like every new Unity version will further slow down performance? Does it implemented internally based on UI Toolkit? Another I hear is GTF will be used to implement visual scripting. Will GTF be used to rewrite Shader Graph as current performance of Shader Graph is still too slow.
     
    NotaNaN likes this.
  34. kaarrrllll

    kaarrrllll

    Unity Technologies

    Joined:
    Aug 24, 2017
    Posts:
    500
    I'm here to answer some of the EditorTool specific questions, thanks to everyone above for the thoughtful feedback.

    The examples provided are authored in Unity 2020.2. Scroll to the bottom of this post for a full code example demonstrating most of the points I touch on.

    Tools need access to the context / selection

    EditorTool has the same level of access to the selection that [code single]Editor[/code] does. If your tool logic was previously implemented using a custom editor, you can use exactly the same logic to access the selected Objects. See EditorTool.target and EditorTool.targets.

    To write a component tool you just need to provide a targetType to the EditorToolAttribute when defining your tool.

    Ex:
    Code (csharp):
    1. // The second argument in the EditorToolAttribute flags this as a Component tool. That means that it will be instantiated
    2. // and destroyed along with the selection. EditorTool.targets will contain the selected objects matching the type.
    3. [EditorTool("Platform Tool", typeof(Platform))]
    Shortcuts

    I agree that this could be better, but shortcuts do have some idea of contexts. The constructor has a context argument that can be used to specify specific EditorWindows in which the shortcut is considered valid.

    Code (csharp):
    1. // The second "context" argument accepts an EditorWindow type.
    2. [Shortcut("Activate Platform Tool", typeof(SceneView), KeyCode.P)]
    3. static void PlatformToolShortcut()
    4. {
    5.     if (Selection.GetFiltered<Platform>(SelectionMode.TopLevel).Length > 0)
    6.         ToolManager.SetActiveTool<PlatformTool>();
    7.     else
    8.         Debug.Log("No platforms selected!");
    9. }
    Contextual Tools

    Good question.

    There's an Active Tool Options overlay that is contextual to the active tool. When a tool is selected, it populates this overlay. Of course tools can still choose to author additional overlays, but the default is one overlay that updates based on your active tool and selection.

    Other windows and Editor workflows

    Definitely. Tools and overlays are currently focused on Scene View workflows, but they are designed with the intention to expand to all windows in the future.

    Additional Callbacks

    Yes, coming in 2020.2: EditorTool.OnActivated and EditorTool.OnWillBeDeactivated.

    To clarify, the request is that we provide virtual functions for these events in EditorTool? Ex,

    Code (csharp):
    1. protected virtual void OnSceneOpened() {}
    2. protected virtual void OnDomainWillReload() {}
    3. // etc
    Yeah, this one I don't have a neat answer for. Internally we have a package for this, but there aren't any plans to make it public.

    As you note, the easiest way to do project specific settings at the moment is via ScriptableSingleton with FilePathAttribute.

    Or if you just need data to persist domain reloads there is an EditorPrefs-like API called SessionState.

    Or just write and read JSON to ProjectSettings/YourNamespace/settings.json directly.

    Example Component Tool

    Code (CSharp):
    1. using UnityEditor;
    2. using UnityEditor.EditorTools;
    3. using UnityEditor.ShortcutManagement;
    4. using UnityEngine;
    5.  
    6. // Example MonoBehaviour that oscillates a transform position between two points.
    7. public class Platform : MonoBehaviour
    8. {
    9.     [SerializeField]
    10.     Vector3 m_Start = new Vector3(-10, 0f, 0f);
    11.  
    12.     [SerializeField]
    13.     Vector3 m_End = new Vector3(10f, 0f, 0f);
    14.  
    15.     [SerializeField]
    16.     float m_Speed = .2f;
    17.  
    18.     public Vector3 start
    19.     {
    20.         get => m_Start;
    21.         set => m_Start = value;
    22.     }
    23.  
    24.     public Vector3 end
    25.     {
    26.         get => m_End;
    27.         set => m_End = value;
    28.     }
    29.  
    30.     public float speed
    31.     {
    32.         get => m_Speed;
    33.         set => m_Speed = value;
    34.     }
    35.  
    36.     void Update()
    37.     {
    38.         SnapToPath(Time.time);
    39.     }
    40.  
    41.     public void SnapToPath(float time)
    42.     {
    43.         transform.position = Vector3.Lerp(m_Start, m_End, (Mathf.Sin(time * m_Speed) + 1) * .5f);
    44.     }
    45. }
    46.  
    47. // The second argument in the EditorToolAttribute flags this as a Component tool. That means that it will be instantiated
    48. // and destroyed along with the selection. EditorTool.targets will contain the selected objects matching the type.
    49. [EditorTool("Platform Tool", typeof(Platform))]
    50. class PlatformTool : EditorTool, IDrawSelectedHandles
    51. {
    52.     // Enable or disable preview animation
    53.     bool m_AnimatePlatforms;
    54.  
    55.     // Global tools (tools that do not specify a target type in the attribute) are lazy initialized and persisted by
    56.     // a ToolManage. Component tools (like this example) are instantiated and destroyed with the current selection.
    57.     void OnEnable()
    58.     {
    59.         // Allocate unmanaged resources or perform one-time set up functions here
    60.     }
    61.  
    62.     void OnDisable()
    63.     {
    64.         // Free unmanaged resources, state teardown.
    65.     }
    66.  
    67.     // The second "context" argument accepts an EditorWindow type.
    68.     [Shortcut("Activate Platform Tool", typeof(SceneView), KeyCode.P)]
    69.     static void PlatformToolShortcut()
    70.     {
    71.         if (Selection.GetFiltered<Platform>(SelectionMode.TopLevel).Length > 0)
    72.             ToolManager.SetActiveTool<PlatformTool>();
    73.         else
    74.             Debug.Log("No platforms selected!");
    75.     }
    76.  
    77.     // Called when the active tool is set to this tool instance. Global tools are persisted by the ToolManager,
    78.     // so usually you would use OnEnable and OnDisable to manage native resources, and OnActivated/OnWillBeDeactivated
    79.     // to set up state. See also `EditorTools.{ activeToolChanged, activeToolChanged }` events.
    80.     public override void OnActivated()
    81.     {
    82.         SceneView.lastActiveSceneView.ShowNotification(new GUIContent("Entering Platform Tool"), .1f);
    83.     }
    84.  
    85.     // Called before the active tool is changed, or destroyed. The exception to this rule is if you have manually
    86.     // destroyed this tool (ex, calling `Destroy(this)` will skip the OnWillBeDeactivated invocation).
    87.     public override void OnWillBeDeactivated()
    88.     {
    89.         SceneView.lastActiveSceneView.ShowNotification(new GUIContent("Exiting Platform Tool"), .1f);
    90.     }
    91.  
    92.     // Equivalent to Editor.OnSceneGUI.
    93.     public override void OnToolGUI(EditorWindow window)
    94.     {
    95.         if (!(window is SceneView sceneView))
    96.             return;
    97.  
    98.         // Note that when Overlays land this code could be implemented through a [CustomEditor(typeof(PlatformTool)]
    99.         // in order to show up in the Active Tool Options overlay.
    100.         Handles.BeginGUI();
    101.         using (new GUILayout.HorizontalScope())
    102.         {
    103.             using (new GUILayout.VerticalScope(EditorStyles.helpBox))
    104.             {
    105.                 m_AnimatePlatforms = EditorGUILayout.Toggle("Animate Platforms", m_AnimatePlatforms);
    106.                 // To animate platforms we need the Scene View to repaint at fixed intervals, so enable `alwaysRefresh`
    107.                 // and scene FX (need both for this to work). In older versions of Unity this is called `materialUpdateEnabled`
    108.                 sceneView.sceneViewState.alwaysRefresh = m_AnimatePlatforms;
    109.                 if (m_AnimatePlatforms && !sceneView.sceneViewState.fxEnabled)
    110.                     sceneView.sceneViewState.fxEnabled = true;
    111.  
    112.                 if(GUILayout.Button("Snap to Path"))
    113.                     foreach(var obj in targets)
    114.                         if(obj is Platform platform)
    115.                             platform.SnapToPath((float)EditorApplication.timeSinceStartup);
    116.             }
    117.  
    118.             GUILayout.FlexibleSpace();
    119.         }
    120.         Handles.EndGUI();
    121.  
    122.         foreach (var obj in targets)
    123.         {
    124.             if(!(obj is Platform platform))
    125.                 continue;
    126.  
    127.             if (m_AnimatePlatforms && Event.current.type == EventType.Repaint)
    128.                 platform.SnapToPath((float)EditorApplication.timeSinceStartup);
    129.  
    130.             EditorGUI.BeginChangeCheck();
    131.             var start = Handles.PositionHandle(platform.start, Quaternion.identity);
    132.             var end = Handles.PositionHandle(platform.end, Quaternion.identity);
    133.             if (EditorGUI.EndChangeCheck())
    134.             {
    135.                 Undo.RecordObject(platform, "Set Platform Destinations");
    136.                 platform.start = start;
    137.                 platform.end = end;
    138.             }
    139.         }
    140.     }
    141.  
    142.     // IDrawSelectedHandles interface allows tools to draw gizmos when the target objects are selected, but the tool
    143.     // has not yet been activated. This allows you to keep MonoBehaviour free of debug and gizmo code.
    144.     public void OnDrawHandles()
    145.     {
    146.         foreach (var obj in targets)
    147.         {
    148.             if(obj is Platform platform)
    149.                 Handles.DrawLine(platform.start, platform.end, 6f);
    150.         }
    151.     }
    152. }

     
    Last edited: Oct 30, 2020
    assertor, Orimay, Bastienre4 and 8 others like this.
  35. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    799
    @gabrielw_unity the Component Tools overlay might solve part of that, thanks for sharing this. However that feels pretty limited then, as I could only have that single overlay and lose the actual overlay customization options, is that right?

    @kaarrrllll thanks for the detailled write up, and especially for the example code. It would be very helpful if that ended up in the docs!
    A note, the link to EditorTool.OnActivated leads to an internal-only view of the docs I think.

    Regarding shortcuts, that "context" would in the case of scene view tools obviously always be the scene view, so unfortunately this isn't a very helpful feature here. I had some discussions in the Shortcut Manager forum thread about this, and the consensus was "sorry, right now it's impossible to build this kind of selection-specific shortcuts with this", so I certainly hope that will change to make overlays and editor tools more useful.
    Virtually any other professional software has a way to "overload" shortcuts depending on selection and/or context, so I really hope this will be added :)
     
  36. CDF

    CDF

    Joined:
    Sep 14, 2013
    Posts:
    1,205
    This is all awesome stuff. Can't wait to use it and make some nice tools
     
    gabrielw_unity likes this.
  37. usernameHed

    usernameHed

    Joined:
    Apr 5, 2016
    Posts:
    90
    Yes, that should be amazing!
     
  38. Shaderic

    Shaderic

    Joined:
    Dec 8, 2017
    Posts:
    5
    This looks really good! The current state of Unity feels like everything does not belong together or that unity is filled with 3rd party plugins but this looks promising!
     
  39. kaarrrllll

    kaarrrllll

    Unity Technologies

    Joined:
    Aug 24, 2017
    Posts:
    500
    My mistake, fixed the link :)

    Yes this is something that has seen a lot of discussion, especially lately. There is a bit of a hack that you can do here, which is to declare your shortcut as a MenuItem with an invalid path plus a shortcut key. MenuItem can define an optional static method that acts as context. An example of this is in ProBuilder: https://github.com/Unity-Technologi...r/Editor/EditorCore/EditorToolbarMenuItems.cs
     
    fherbst and NotaNaN like this.
  40. usernameHed

    usernameHed

    Joined:
    Apr 5, 2016
    Posts:
    90
    I have also a 2 special request: (may be not related to EditorTool, but intimately linked...)

    1) Component Build:

    I would like an event triggered ONCE when a component is just added (from runtime / editor script, OR from editor)

    Example: When a new component is added, I want to assign to it some special default variables, like gameObject reference, or structures initialization... Only the first time.
    • I don't want to use Awake() & [ExecuteInEditMode], because, Awake is also called on play at runtime
    • I don't want neither use the Constructor (because it's called at compilation, when leave/back play mode...)
    • What I can do, is create an editor for the special component, then create a Serialized hidden bool "IsBuilt" on the component, and then on the OnEnable() of the Editor script, Do my stuff to initialize my component is this IsBuilt is false (and use Serialized property of course. By the way: Serialized property is REALLY HARD to master for beginner, et realy really anoting, we need some wrapper and EASY TO USE API for that...).
    2) New init method for editor scripts:

    Sometimes, we want stuff to be initialized inside an editor script. Then we commonly use OnEnable().
    But sometimes, we can't. Sometimes with special GUI stuff, of texture initialisation, I have to init my stuff at the first OnGUI(), or at the first OnInspectorGUI(), or at the first OnSceneViewGUI().
    It would be nice if we had virtuals method for these...

    My solution is to use a Decorator for every problem I mention, but it should be native I think.
     
  41. NotaNaN

    NotaNaN

    Joined:
    Dec 14, 2018
    Posts:
    313
    While I think what you mentioned may be a useful feature to people, and I am in no way dismissing it — have you tried taking a look at Reset() and determining whether or not it would be sufficient for your needs?

    Reset is Editor-only, but in most cases you really shouldn't be adding Components to GameObjects at runtime due to the insane performance hit that occurs, so perhaps Reset is enough for your usecase?
     
  42. pachermann

    pachermann

    Joined:
    Dec 18, 2013
    Posts:
    101
    Looks great! I would love to see is that these tools work on runtime in the editor for prototyping.
    I really miss probuilder on Runtime.
    Will that be possible anytime soon?
     
  43. gabrielw_unity

    gabrielw_unity

    Unity Technologies

    Joined:
    Feb 19, 2018
    Posts:
    917
    Hi @pachermann ! Thanks! Unfortunately, nothing in the works for runtime ... nothing at the moment, anyway. Working on getting the editor workflows solid for now. I'd love to get back to that project one day though, yes!
     
  44. stuksgens

    stuksgens

    Joined:
    Feb 21, 2017
    Posts:
    172
    Simply amazing, the overlay mode will be very useful ... I will be waiting for the next Alpha releases to test this wonder:D

    I don't know if you can fix this, but in the dark theme of unity, the bars at the top of the screen are white, you can make it black. please:)
     
    Orimay and gabrielw_unity like this.
  45. IndieGameHustle

    IndieGameHustle

    Joined:
    Jul 25, 2012
    Posts:
    65
    Just came across this on twitter. This looks amazing. Thank you for this update and roadmap. Looking forward to it.
     
    gabrielw_unity likes this.
  46. pachermann

    pachermann

    Joined:
    Dec 18, 2013
    Posts:
    101
    Alright! Thank you for the Feedback, i look forward to it :)
     
    gabrielw_unity likes this.
  47. usernameHed

    usernameHed

    Joined:
    Apr 5, 2016
    Posts:
    90
    Unfortunatly, this Reset() is called from the Monobehaviour script (and as tool programmer, we want a way to clearly separate gameplay code from editor code). So I would like this Reset() function to be called on the Editor Script.
    (is it possible ?)

    I think we derived a bit from the subject, sorry for that ;) but it's some nice talk thought.
     
    Ramobo, Ruchir and NotaNaN like this.
  48. sand_lantern

    sand_lantern

    Joined:
    Sep 15, 2017
    Posts:
    199
    This is looking really pretty. I like what's going on here! As someone who just pushed his first tool to the asset store, a lot of these features are solve many of the little gotcha's that I had to hack my way around to get a tool that behaves consistently in the Unity ecosystem. Neat! I look forwards to being able to update my tool in a year.
     
    Orimay, gabrielw_unity and adamgolden like this.
  49. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    885
    Any updates on availability?
     
  50. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,415
    This is amazing work, guys! -- I have a few requests though:


    @gabrielw_unity

    Shortcut Manager -- Is it going to be able to apply "Per-Workspace" and/or "Per-Toolbox" shortcuts alongside this new system so I can toggle all visual overlay components from a different workspace (and Toolbox) on/off?
    I hate modifier keys too -- so I'd prefer to activate most tools via single-button presses (i.e. "G" key for toggling a grid).



    I need a "Per-Toolbox" option where an entire "Workspace" can actually have up to 8 different "Toolboxes" active (one at a time though) with a small selection of Toolboxes (i.e. 1-8 Toolboxes activated/toggled by the 1-8 numeric hotkeys) -- each "Toolbox" has its own (assignable) shortcut keys.
    Setting a Toolbox as "Toggleable" would keep its shortcuts (though not its overlays) active even when another Toolbox is active, but by default only one can be active at a time. However, a "Main" Toolbox for the Workspace would be necessary (whether it's active or not), so only one Toolbox (out of all 8 Toolboxes) can be set as "Main" Toolbox (which essentially just handles default shortcuts when no other Toolbox/Tools are active in the Workspace).


    The idea is that my global shortcut keys can be single-key (and changeable on-the-fly depending on the "Toolset" out of the active Toolbox I choose for the active Workspace).
    Toolset mechanism would essentially show/hide overlays / component toolbars / etc and activate their various shortcuts when a Toolset becomes active in the active Toolbox + Workspace. Shortcuts and Toolsets are swapped automatically based on the Toolbox chosen and activated in each Workspace. Not only that -- but it would keep my ever-increasing toolsets more organized with the concept of an actual Toolbox/Toolset hierarchy. This is a concept no other application I've ever seen before has -- but Unity is unlike any other application in the sheer variety of tasks, tools, and operations it can become, right?

    Ideally, all my keys in a Workspace / Toolbox should be able to be set to single-key operations for swift/instant activation of tools/windows/etc. (i.e. "G" key to toggle grid when placing tiles with a 2d Tileset Toolbox -- regardless of the placement/rotation/etc tools itself -- but "G" opens up my graph when working on Visual Scripting with the "Programming" Toolbox active -- with all these Toolboxes available on particular numeric keys at the top of my keyboard, all instantly available within my "GameDev" Workspace.) Other workspaces + toolboxes would then have their own shortcuts (and management) for each of the 8 possible Toolboxes (and however many Workspaces one needs).

    How does this sound?
     
    Last edited: Nov 18, 2020
    sand_lantern and NotaNaN like this.