2.8 UI Tools: Tools Design #54582
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#54582
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This document serves as an overview of the Active Tools system for Blender 2.8.
We will have two types of operations: Active Tools and Commands.
Active Tools
When activating an active tool, Blender does these things:
These controls are persistent, until you pick a different tool, just like paint mode tools, hair mode tools and so on.
The tool always defaults to zero - ie, it doesn’t perform any changes to your object or mesh, until you either:
To perform the tool again (say to perform two extrusions in a row), there are two ways:
Only one active tool can be active at a time.
Shared Tool Options, such as Proportional Editing, Snapping and Pivot are a per-editor type setting. The Orientation setting appears in the top bar when the user has a transform active tool enabled.
When the user executes a command, the tool is not overridden, and therefore stays active.
IF that command has options, we display them in a way that’s clearly different from the ones pertaining to the active tool.
Here are some examples of how exactly the active tools will work:
Move
The user hits the Move tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with the tool settings next to it (XYZ) and the Orientation control. In the 3D View, we see a 3D manipulator. The orientation of the manipulator, as well as the XYZ controls, depend on the orientation control. The cursor shows a Move icon.
The user now starts to drag and move the cursor freely in the 3D View, which moves the selected items perpendicular to the view. As the user does this, the XYZ controls in the top bar update to reflect the distance moved since the tool was invoked. The user may choose to adjust those values in the top bar, for example to make a rough placement more exact.
While the user is dragging, tapping X, Y or Z will snap it to a single axis, the orientation of which depends on the orientation setting. This also highlights the corresponding field in the Top Bar, so that users can type in values quickly.
When the user is happy with the move operation, there’s nothing left to do. They simply switch to a different tool and continue working. No need for any OK operation or to ESCAPE or anything like that. The flow stays unbroken.
If the user wishes to start a new move operation, resetting the delta values, they can do so by hitting the Move tool icon again, which is the same thing as going to a different tool and back again.
Extrude
Works just the same as the move tool, except:
We might want to add the ability to set the # of cuts on the extrusion. This would appear in the top bar.
Extrude Region and Extrude Individual should be presented as two separate tools, using the tool docking system in 2.8.
Knife
The user clicks the Knife tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Snap, Midpoint Snap, Cut Through. The cursor shows a Knife icon.
As soon as the user clicks in the viewport, a line appears. When the user clicks a second time, a point is created and a new line appears, and so on.
The user can tap X or Y to constrain to each viewport orientation, or hold shift to constrain to 45* angles.
The Snap, Midpoint Snap and Cut Through top bar settings are available at any time.
When the user is done knifing, the user double-clicks to stop drawing lines. The user can then click and start creating new lines.
Spin
The user hits the Spin tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Angle, Steps, Center and Axis (Axis being a vector may need a different representation than an XYZ) and Dupli (Or, should we make Spin Duplicate a separate tool in the UI?). A widget appears in the viewport with the ability to set the Centre point, angle and Axis, with some sort of pie chart style control.
When the user drags LMB anywhere in the 3D Viewport, they move the centre point (or not? Is it more useful to set the angle actually? You’ve may already have set the centre point location using the 3D Cursor anyway…)
Holding Ctrl snaps the angle to increments, and holding Shift makes in more sensitive, just like other transform operations.
Select Border
The user hits the Select Border tool icon. All other tools and widgets disappear. In the top bar, we display the name of the tool and the following: Replace, Add or Remove radio buttons. The default is set to Replace.
The user can now click and drag in the 3D View to create box selections. LMB-clicking selects a single item.
Holding Shift sets the tool option to Add. Holding Alt sets it Remove.
Inset Faces
The user hits the Inset Faces tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Thickness, Depth, with check marks for Relative, Even etc.
In the viewport we see a manipulator which works just like a slider.
The user can now click and drag in the viewport to drag in the inset.
While the user is dragging, they can hold Ctrl to snap to increments, or Shift to increase sensitivity.
Bevel
The user hits the Bevel tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Amount (%), Segments, Profile, Vertex Only etc..
In the 3D View, we see a manipulator that lets users increase the Amount %.
When the user drags in the 3D Viewport, the Amount % is increased from zero.
Bisect
The user hits the Bisect tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Fill, Clear Inner, Clear Outer. We also see Plane Point and Plane Normal (Struggling with a good way to make vectors and normal numerical values make sense though? There must be a better way to do it)
In the Viewport, we see a manipulator that looks like a transparent plane, with points on it so that users can move it and rotate it to define the bisect plane.
When the user drags freely in the 3D Viewport, the entire bisect plane is offset.
Primitives
The user hits the Add Cube tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Radius, Location, Rotation.
When the user clicks and drags in the Viewport, a Cube appears and scales up or down depending on how much the user drags. Here we also see scale cage-style manipulators to set the size.
Randomize Vertices
The user hits the Randomize tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Amount, Uniform, Normal, Seed.
A slider-type manipulator appears in the viewport.
The user can drag in the viewport to randomise verts more or less
Loop Cut
The user hits the Loop Cut tool icon. It becomes highlighted, and we see the name of the tool in the Top Bar, with these tool settings next to it: Cuts, Smoothness, Falloff, Factor.
As the user uses the viewport, loops are highlighted as they mouse over them. When the user clicks, a loop cut is added. If the user clicks and drags, they go directly to dragging the cut factor.
Other Edit Mode operators which make sense as Active Tools:
—————
Commands
These are separate from Active Tools. Commands are not tools that stay active. Instead, they are an atomic operation. After they are performed, the user can continue with whatever active tool they were using. Commands also have the ability to immediately affect the mesh without requiring additional user input.
Here’s a list of typical commands:
Some commands may have some options users need to be able to set. These we separate from the settings that pertain to the active tool.
In the top bar, we put a popover menu with the last operator accessible. When expanded, you see the options pertaining to that command.
We are considering adding the ability to access the entire history stack from the top bar, with in the same popup, or next to it.
We also would like to add a way to keep these operator options persistent, so users don't have to constantly open and close the operator section.
Status Bar
Some of the tools described above have the ability to use certain modifier keys to tweak their behaviour. Transform tools let you constrain to axes while you are dragging, or snapping by holding Ctrl; the Knife tool allows users to snap to X and Y while drawing, and so on.
The way in which we communicate this, is by adding a status bar to Blender. This will make it completely clear, at any time, what mouse buttons do, and what modifier keys adjust. This way, there's no loss from removing the old 'header modal tips' feature.
Hotkeys:
This new active tools system creates a dilemma: Even though it makes sense for using the toolbar, how do we handle handle hotkeys? Do they work just like in earlier versions of Blender, or do they switch active tools?
Initially we could avoid this conflict by defaulting to either: 'Immediate Blender' and 'Active Blender' (names?)
It may be we have a single keymap which allows both, this requires careful design.
Immediate Blender Keymap
If the user is using this keymap, Blender's hotkeys are essentially the same as in earlier versions. Pressing G works just like it did before. However, the user might still want to be able to access active tools via a shortcut. We will support this using a consistent modifier.
Possible methods include:
*Holding G could activate the Move tool
*Holding a modifier (such as Space, Ctrl ...)
Active Blender Keymap
If the user is using this keymap, Blender's hotkeys are set to switch active tools. That means tapping G is exactly the same as pressing the Move tool icon in the toolbar: It switches to that active tool, and the user can then use manipulators, drag freely or enter numerical field values, and so on.
If users would like a more immediate way of interacting with tools, they can then use sticky keys: Holding G will allow you to immediately start moving. Users can release G to confirm.
Added subscribers: @WilliamReynish, @ideasman42
Added subscriber: @AlbertoVelazquez
This means that current operators can be accessed without going through active tools? That is to say, it will not be possible to use extrusion, move, cut,... directly, like right now, pressing a hotkey without going through this system? Or it is a complement like in actual blender2.8 versions?
I mean, a tool that's in active tools can't be a command at same time? and use the tool in both modes.
Yes to both. Using hotkeys can work just like it does today. I've now clarified that point above.
Essentially, Active Tools set a recipe for an operator. So even though it may sound strange, active tools can actually co-exist with the same corresponding operator. Even when using the active Move tool, you are still performing an operation, just like if you enable Manipulators in the 3D header in Blender 2.79 and you drag, you are still setting a move operator.
Aside from that, what happens when you use hotkeys is a separate issue. Our approach is that we will provide two separate keymaps (or keymap settings), both of which enable both types of uses. The difference is merely which take precedence.
Added subscriber: @Januz
Added subscriber: @leandro_cavalheiro
Added subscriber: @ChristianMoravec
Added subscriber: @Rawalanche
Hi,
I have one idea which could make keymap management for object transformation a bit more straightforward.
When use 3D manipulators mode is enabled. G, R and S keys would switch the Move, Rotate and Resize manipulators. When use 3D manipulators mode is disabled (Manipulators are hidden), then G, R and S keys would activate freeform Move, Rotate and Resize actions. So basically we would not need to have different key mappings for manipulator transform modes and freeform transform modes. It would be the same set of 3 keys, just context sensitive depending of if showing manipulators is active or not. :)
Added subscriber: @LucianoMunoz
Ludvik: Yes, we already thought of this, and we are planning to do more or less what you are suggesting.
We plan to have a switch, so that you can make the active tools in dominant workflow. If enabled, G, R, S etc simply switch on the relevant active tool.
Tying it to the Show Manipulators toggle is an interesting idea, but we will probably do it as a preference. The Show Manipulators toggle is more a display option.
Blender 2.8 Tools Designto 2.8 UI Tools: Tools DesignAdded subscriber: @YAFU
Hi.
I mentioned this in blenderartists forum, but I think I should comment my concern in some official website, like this.
About Active Tools and Circle Select, it would be nice to somehow be able to see the brush outline before clicking to select. You imagine a dense mesh in Edit Mode, and you want to start selecting vertices through the middle of the mesh. You will not be sure in advance what you will select when you click because you can not see in real time what the radius of the brush covers.
I'm not sure how this could be solved with the Active Tools concept, but I think the tool would be more powerful if you could somehow see the brush outline before starting to select
Yafu: Yup, absolutely.
Added subscriber: @JulienKaspar
I finally want to share my concerns and suggestions for the current design of the toolbar itself.
First of: The more I saw the development and the more I read about it , talked with developers about it and tried the new tools out the more I opened up o the idea to the point that I am completely embracing them now.
They are a good addition and a great improvement on the old toolbar full of overcrowded or borderline unusable operator buttons and can work completely side by side with the old operators & shortcuts way of working.
And if the user doesn't need them or rarely uses them, the toolbar can just be hidden and work continues as usual.
But there are aspects of the old toolbar that got removed that would be great to include again: The customizablility and inclusion of simple operators and tools that need more space than just a button and a slim top bar.
These mostly come from the internal and community addons, which would need to be completely reworked or in a lot of other cases only be available in the Tool Settings Tab in the Properties window.
This is a shame since the Properties window cannot be easily hidden and is not included when full-screening a window like the T and N panel.
The Toolbar serves only one purpose right now: A small selection of what is now deemed to fit into a narrow definition of a tool and nothing else. If you don't want to use these new tools or they pose no purpose for your workflow, then the toolbar is officially dead for those users.
So my proposal is to bring this optional customizability back without removing the improvements that have been made by introducing the new toolbar and tools.
This is just a quick mockup but the idea is to include all new tools in an "Active Tools" tab, or alternatively maybe a "Brushes" tab for painting/sculpting modes.
The rest of the toolbar would remain empty and any additional tools settings and addons would still be available in the Tool Settings tap in the Properties window, BUT with the new possibility to pin and unpin any of these tabs to the toolbar.
The width of the toolbar also wouldn't be the deciding factor on if the tools are displayed as a grid or in a list but toggle buttons in the Active Tools tab.
If the grid arrangement is chosen the grid would reorganise itself based on the width of the toolbar even when using a single column arrangement but when it becomes too thin the pinned tabs could just become vertical tabs that can be clicked and become a popups like in the top bar.
If the active tools are not useful to the user they can just collapse the tab and use the rest of the space for other custom pinned tabs and the toolbar remains useful and accessible at any point for any tool settings or addons but without already overcrowding it on the first launch of Blender.
What do you think of this idea? I don't expect this to be implemented any time soon since there are other things to be worked on for the beta and eventual finla release of Blender 2.8.
And there are also other things to be worked out for this to work for example how to pin the tabs and how to define in which window these can be pinned to (so that 3d view tool settings don't overcrowd the uv/image editor toolbar for example) and in which mode these pinned tabs are supposed to appear.
But I think this can bring back some functionality that was lost to the toolbar and is still very useful to have.
The only thing that get's lost is a clean and clear toolbar at all times.
(Also in the mockup i just used addons that are currently available to me in the Blender 2.8 Alpha so this is not the best example of which tabs to pin to the toolbar)
An alternative would be the concept of the 3D View Sidebar in the task #55407, described under "2: Panel Addons" but I wonder how customisation this space will be, how it interacts with the N panel and if this concept is still planned to be implemented.
Added subscriber: @brecht
Adding the tabs to the 3D view sidebar is still planned yes. #56350 (UI Tasks (parent task)) lists all the UI tasks that we consider required to finish before releasing a 2.8 beta.
This would basically just mean putting existing panels in a "Viewport" tab, and then addons could register their own tabs and panels just like before, just on the other side of the 3D view.
The idea is that we will have a panel in the Sidebar for commands. We really don't want to throw loads of commands in the toolbar, because users can also find those commands in the menus, which have become more accessible, so it's no longer necessary to have them always visible. Users can also add commonly used commands to their own custom Q menu, or use the W-menu (which will be right-clicking when using LMB select) with the most common commands.
In 2.7x, many users had the Toolbar and Sidebar always open, which took up an enormous amount of space. In 2.8, we want to emphasise content, and so we have attempted to lessen the reliance on the Sidebar. Users can use transform in the Properties and many settings can be set through popovers instead. The Toolbar is also very compact now, rather than the huge, overloaded thing we had in the past. This is all intentional. Of course users can still open the Sidebar, but we expect that it won't be necessary for most things anymore.
As for Addon panels, they will be able to register themselves in the Sidebar. Some Addons will also be able to work as Active Tools, and they can then register themselves inside the toolbar, right next to the other active tools. This requires Addon developers to make some changes. When 2.8 is released, we will provide documentation on how to do this.
I support the idea of left toolbar being exclusively dedicated to tools. The mockup by @JulienKaspar looks like a step back in a scope of cleanup that has been done since 2.8 development started. It would allow the left toolbar to again become "everything bar" of random buttons, which was a big pain in 2.79.
Since it's planned for Addon UI to be able to occupy properties panel, it would make a lot more sense to simply split your property panel vertically in two, and have your desired addon UI always present under your main property panel. Like this:
@JulienKaspar
Don't waste your time. UI team have ignored all feedback in blender 2.8.
I think it could very well work in an overhauled sidebar but the pinning will still be useful to implement in that one then. Sometimes you would want to have the interface of an addon that is more complex than a tool like Blenrig visible on the side even when going fullscreen but while also having the transform properties visible at the same time. So pinning them makes them both visible without switching tabs constantly in the future sidebar.
it's just a shame of not being able to use the space in the toolbar if available space on the sidebar would run out. The current way is more clean but the things that were removed were able to be more useful where they were.
You got a point but i still somehow feel like it's really more about a placement rather than specific toolbar. I mean yes, if you run out space in the sidebar, then given how minimalistic the new toolbar is, you are still saving so much space there that you can afford to open a whole new UI region and put properties panel in there with addon of your choice. So in this practical example, you'd split your viewport off from the left side and put your addon there, then drag and resize the toolbar so it's one thin vertical row to still have plenty of space for the viewport :)
I mean, if you compare both yours and my mockup. Both display exactly the same amount of UI elements on the screen, yet one of them leaves more space for the viewport at the expense of empty UI panel space. Even if that empty UI panel space wouldn't be there, you'd still be able to customize the UI space finely enough to get the most out of it :)
To be clear, the plan is to move 3D viewport addons from the toolbar to the sidebar. There are no current plans to move such addons outside of the 3D viewport to the properties editor.
Added subscriber: @JeffMetz
Removed subscriber: @JeffMetz
Ah, nevermind then. I assumed that Shot Management addon wouldn't exactly be a 3D view specific one.
I went through some original design mockups of the toolbar again and saw that one draft depicted different views of the toolbar and customisability:
You would be able to switch from active tools to quick commands, and I know that these are now neatly tucked in the Q key popup, but this concept can still apply for addons, interconnected command interfaces and settings that are at times too hidden in the top bar.
The concept of making the toolbar a slim space exclusively for a specific type of tools looks like a progression but if you are not primarily working withing the painting modes or sculptmode and find the new tools just a slower way of working, then you would never use it again. The Toolbar might as well be completely removed. It lost all purpose for those users and that seems much more like a step backwards because it used to be much more in 2.7x. That doesn't mean that the Tools themselves are not useful and they are a progression themselves but the Toolbar is still flawed in my opinion.
If the general position of the Addons will or could be the side bar then I still believe that giving the option to position them in the Toolbar should be valid in a similar way as the original design of the quick commands.
And I don't mean in the way of pinning single commands & buttons but instead more complex arrangements of connected buttons and bigger interfaces. Even in the paint modes & sculpt mode there are still some settings that are too hidden in the top bar and could find a spot in the Toolbar instead of having a separate window to the 3D view with the tool settings shown.
In a lot of cases this would mean that you would have two properties windows open. Here's an example: The officially integrated sculpting workspace.
Giving available customisable space in the toolbar eliminates the need for the tool settings on the left side and rounds everything off to work together in the 3D view just like it did before in 2.7x.
This could be done in a similar way like moving tabs in the current N panel up & down. Instead you can drag them from the sidebar to the toolbar. Any of the popups in the top bar could then also be opened and the opened popup grabbed (essentially duplicated) and positioned in either the toolbar or the sidebar. This could make it more intuitive but also confusing so an alternative way could be to right click on any tab on the sidebar or topbar and get the option to switch them or add them to any of the other bars, similarly to how you can switch the position from the header in the 3D view to the top or bottom.
Maybe it seems like I'm beating a dead horse at this point but I strongly believe that the current system needs improvement in one form or another. I at least want to share my suggestions for that and keep the discussion going.
I also know that some things are still WIP but the beta is coming closer and so is the impression of: This is the way it's meant to be like.
We are looking to implement brushes in a different way, so that we won't need loads of categories in the toolbar, but can make it easy to browse lots of brushes.
@WilliamReynish I already know that these are old mockups but they demonstrate an idea that was discarded but that I think is valuable and still relevant.
I'm guessing you mean that the left properties editor is going to be removed? I hope there's more to the "change" because this editor is there for a reason. It brings back some functionality to the UI that got lost.
That's a good point and I agree. While using the brushes for weeks now with most shortcuts broken I realised how inconvenient the categorisation is, or at least, that the switching without shortcuts is not convenient enough.
Is there a task for this yet and is the toolbar going to look or function differently with brushes that are "implemented in a different way"?
But also ... that was not at all what I talked about.
I hope you get what my core issues are:
I might be missing some information though.
If there are more plans underway to improve this I would be happy to know if there's a task with more details or if you can share your thoughts & ideas here.
Changed status from 'Open' to: 'Archived'
Archiving since the original design task has become too out of sync with what we're currently developing for 2.8x, and not something to use for setting targets.
Anything remaining should be extracted into more spesific tasks, see open sub-tasks of #54844.