Thanks Ronan, I’ll read through that first.
1 Like
Hey there,
I would like to share some thoughts about the toolsystem. To me it feels like tools are mainly adding a new way of interacting while being unrelated to the existing operator’s workflow. Having two systems in parallel brings additional hotkeys, panels etc. I think there are some concepts that could be more general and flexible:
Problems:
-
The concept of an active tool enables to do the same kind of action (e.g. extrude, bevel, scale) several times in a row pretty fast but i’m not sure how often this is the case. I imagine that normally a lot of tool switching is included rather than repeating the same action for different selections. I kind of dislike active tools because of this fact.
-
Right now the toolsystem is a completely different concept to the existing operator’s workflow which brings additional complexity. Tool switching will bring additional hotkeys and there will be a big difference between using operators or tools. So beginners will have a hard time if they want to use operators for a faster workflow.
-
Selection modes are treated as normal tools although this is a pretty basic interaction which should be always possible.
-
Only one workflow is supported (selection -> action).
Proposal:
-
Everything should be a tool but the selection which should always be accessible, also while executing a tool, so it’s something like a mode that you can change(border, circle). What was an operator is just a simple form of a tool without a gizmo or a specific keymap. We can still present such simple tools differently from modal tools in the UI. But the the redo options should also be presented in the same way as a tool.
-
The usual hotkeys are used to start a tool. For a faster workflow similar to 2.7x we could use something like sticky keys to directly modify the first parameter of a tool. Or maybe allowing python to start a tool with a different behaviour when triggered by a hotkey.
-
A tool is always immediately applied as soon as it has a valid selection given and there’s actually a modification. Tweaking toolsettings won’t restart the tool. To repeat an action (like doing two extrusions in a row) the user simply restarts a tool with the selection given from the previous action. Maybe we can also use a consistent key to restart a tool.
-
We should better communicate the selection in a consistent way. Something like having a dedicated panel always visible in the topbar which shows the current primary + secondary selection and some related tools to clear, switch or modify the selection or change the selection mode. Maybe we could also put stuff there to save or select a selection (like vertex groups or collections).
-
Allow different workflows (selection -> action, action -> selection, selection -> action -> selection). This would give us a more flexible and intuitive way of interaction. So you would also be able to select an object hit something like the parent to action and then choosing the target.
-
Tool settings should be editable in a consistent way. So whenever a tool has a valid selection the first setting is chosen, if the user enters a number he changes that setting. We should also be able to switch settings (normally tab and shift-tab is used for such things). If you start a tool without a selection it would first ask for that.
Example:
-
Before we start any tool the topbar shows nothing but the current selection and some corresponding tools to work with selections.
-
We either select something and start a tool or start it without a selection. If there’s nothing selected the tool will first ask to select something. Otherwise it will ask for the first setting (which is communicated by adding a highlighting colour or something).
-
The tool draws it’s gizmos and sets the tool keymap as soon as there’s a valid selection. At this stage there’s no modification at all.
-
Now the user can either enter a number, pull a gizmo or pull a slider (maybe also something like ctrl-click-dragging in empty space to interactively change the active setting).
-
Then he can switch to the next setting of the tool or pull another gizmo and do the same. If he wants to edit the selection he clicks the selection button in the topbar and modifies it.
-
The tool ends when he changes the selection while not being in the selection mode or when firing the next tool (Keymap conflict?) or whenever the user presses esc. The topbar then again only shows stuff about the selection.
I hope you will find some of my input actually helpful even though the alpha phase is probably the wrong time to make big design changes. Feel free to share your feedback or concerns about the proposal as it still is pretty rough.
4 Likes
It is true that there are Topbar settings and Redo panel settings. But there is no additional hotkey.
There is only one active tool at a time and this one is using Left click.
Shortcuts that you see when pressing spacebar to call the tool are the same than the ones used to call a tool without making it the current active tool.
It looks like there is a problem of display in alpha. Shortcuts are appearing in default toolbar after pressing Spacebar and choosing an active tool. But if after that, we are pressing directly a shortcut they disappear.
A beginner will use toolbar, learn shortcuts through toolbar and probably switch from active tool to another tool without making it the active one, the day, he will try shortcuts.
Currently, by default, selecting by using right click is always possible. It is more complicated if you switch to left click select because of active tool.
But shortcuts for lasso, box or circle select tools are always working.
OK. The action is a mode. Selection is made and action is previewed. A validation step is done and action is validated at that moment.
The same way that making any tool, a potential active tool useable with left click and a manipulator.
It corresponds to a lot of work. Making all tools modal with a preview that makes distinction between selectable mesh elements and the ones created by action.
2 Likes
Suggestion
It would be nice if when clicking on other objects in the outline, to change active object and keep the same mode.
I would find this especially useful for grease pencil when animating different objects that interact with each other story wise. At the moment, one has to quit draw mode to enter object mode, select desired object and then enter draw mode again.
3 Likes
Multi-object editing idea is supposed to allow us to have several objects using the same mode.
In theory, it will be possible (when this work would be done for grease pencil) to draw several objects in draw mode.
You are bringing an important point, here.
GP strokes are stored into GP layers dependent as object specific data. It means that, anyways, user have to precise which one is the active object.
Drawing a stroke is equal for meshes than adding a new primitive in edit mode. This one is added to active object of selection.
Currently, when multi-object editing is used on two meshes. You can change active one without quitting the mode by clicking in the outliner or by switching object in Object Tab of Properties.
For grease pencil, you can’t change mode at same time for two GP objects.
But you can set an object to draw mode, change active object by using Object Tab of properties (it brings you back to object mode) and set this object to draw mode too.
At that moment, both objects are in draw mode and you can switch active object by using outliner.
If workspace is supposed to be dedicated to a mode, we will need a way to browse or cycle objects of selection to define active object for multi-object editing.
Outliner is efficient. We can restrict it to selection. But user have to know how to use filters with it.
More obvious one would be to add an active object switch in Topbar in case of multiple selection.
But it leave less space in Topbar for tools in those modes using brushes.
We could add the switch in 3DView header. Anyways, we are talking about editing a selection of 3D objects displayed and edited in Viewport.
Or, we could consider that change of active object like a change of active collection and attribute a shortcut to it.
2 Likes
Hey Ronan, thank you for your response,
Not really sure what kind of preview you’re talking about. This point is more about operators which just throw an error if there’s no valid selection. This isn’t really helpful for a beginner as he already needs to know a tool before he can use it. Operators that get called without a valid selection should rather display their settings in the topbar and ask for the selection. So the user sees what he should enter and learns the operator interactively. Data modification should still be instant, no need for a preview system.
I agree with the other points but to me it still seems that experienced users will rather turn away from the new toolsystem as it is a slow workflow. That’s why i propose the toolsystem to be closer to the current operator’s workflow and try to improve what’s existing while keeping the pros of that system.
Having a consistent system of how you make changes in a software is really important as you don’t need to relearn every aspect of the software once you’re used to how it behaves. When there are two systems in parallel it makes the interaction unnecessary complex.
For most of tools, a valid selection corresponds to a huge range of possible selections.
You can make an extrusion of one vertex, a row of edges or a big region of faces.
So, for this tool, selecting one element is a valid selection. Selecting a bunch of elements is another one.
And it does not give same result at all to consider all these elements as a whole or individually.
How a beginner is supposed to learn that he can use the tool with a vast variety of selections if the action is performed and validated at the moment, he selects one element ?
You can use lasso, circle or box select to select lost of elements in one action. But must of times, it does not correspond to desired selection and it is followed by deselecting operations to correspond to what user want to change.
I mean that action will not be satisfying if it does let time to make wanted selection.
With current system, it is possible make an unvalid selection and try to perform an action that will not accept it. In that case, blender displays a warning message explaining what is a valid selection for this tool.
But these are really rare cases.
So, if multiple selection can be valid, user should be able to precise on which one he wants to perform the action.
The order, action -> selection implies that first thing selected can not be considered desired one.
That implies geometry before action should be visible to adapt this selection.
And as the goal is to immediately show geometry resulting from action at same time, it means that can only be done by an overlapping preview.
Same kind of situation than when you are previewing effect of a modifier in edit mode but restricted to selection.
When a beginner creates an ugly mesh, it is not because he made an invalid selection (Blender does not allow him to make one) : it is because he did not keep the use of tool in the limits of what is reasonable for edited mesh.
Blender does not have an AI to tell to user this extrusion will intersect with these faces of edited mesh when this value is reached. A selection can be valid and following action can work on a specific mesh and same selection and action can give a real mess on another one, just for a reason of amplitude of the action.
Beginner or not, there will still be some problems that will continue to be up to the user.
Experienced user will appreciate to be able to sum-up some rarely used tools to a left click and to expel some complicated shortcuts from their keymap configuration. They will use active tools, too.
We made experience of sticky keys for pie-menus. It was not always a success.
So,anyways, a pertinent triage had to be done to use them where they are useful and to avoid to have them conflicting with other things.
IMO for beginners, it adds another level of complexity to assimilate about of the application.
And your proposal to add a third way to perform an action will add more confusion than current situation with just two. Unless you are proposing to remove one or the two present workflows for the action-> selection workflow.
I did not identify other practical points in your proposal. To me, others are erroneous because you are confusing what is a valid selection from user point of view and what is a valid selection not preventing tool to work.
There are more than a dozen of items in Select menu, because a valid selection from user point of view is often a combination of numerous criteria.
I want a selection of continuous faces in that area of mesh having those bounds in the frontside of mesh in this particular view. That’s a lot of criteria to put in a topbar to define that a box select is valid.
It is what I understood when I read your proposal for the first time. It is so ridiculous that I conclude that you were proposing to set an action mode with a preview interactively updated by modifications of selection.
Definitely not my intention to share ridiculous proposals, as I said the proposal is still rough. I could spend some more time to clarify the proposal and to make my point clear. But I’m still curios if there are users that actually agree on the problems I stated, as it wouldn’t make sense to invest more time otherwise.
1 Like
Has anyone noticed that T and N panels now fade in this kind of very slow, ugly, low framerate fade animation? Blender overall is always snappy, but this low framerate fading animation makes it feel quite slow and laggy 
1 Like
Why did they put the specular options in the preferences?
It’s like shadow and cavity, we need to be table to edit it on the fly in the 3Dview.
If it was possible to save presets, ok, that could be nice in the prefs, but it’s not the case.
So, why do we need to open an editor, go to the proper tab to be able to edit a 3Dview property?
Same for the background, why not add the colors in the popover for theme and world?
For the random we could have some palette maybe
for the material, could be nice to edit on selection even if the objects have different shaders.
As I can see, we still have to go in different editor to change a 3Dview property, it’s a waste of time IMO.
Why not put an eye icon instead of a prop?
Could be useful
And add a hotkey on the rotation like in substance painter.
10 Likes
The situation is different. Shadow and cavity popups are only grouping 2 or 3 settings.
Here, it corresponds to 3 lamps with 3 settings per lamp. It does not fit in popup with a discrete area.
I think that they simply should go into View Properties column.
We could keep checkboxes to enable/disable shadow, cavity and specular highlights in shading popover and move options to a corresponding panel present in View properties column only when option is active.
That would correspond to how quick preferences addon is presenting OpenGL lamps in 2.79 (an already tested choice). And as a panel, it would be possible to add a preset star in its header. But we could try the same star in popover dedicated line.
So, user would not have to open view properties if he already made his presets.
Yes. Something is needed. Palette may become inappropriate because of custom color of viewport background. Really often, 2 objects close have a close color which is counter-productive : the goal is to make better distinction between objects. At least, a seed setting is needed.
2 Likes
Still blinking top bar in the edit mode…
1 Like
What do you mean???
i just noticed this yesterday that there is a serious conflict with the cursor tool and the transformation gizmo tool.
when one of them is active the other one is disabled, so if the cursor tool is selected the gizmo disappears and if the transformation tool is active the cursor can not be placed.
this is really cumbersome and definitely less efficient than we had it before.
and in my opinion this should be made to behave the same way as before and activating the tool gives access to the functionality of the tool but not disable the other tool.
has this been discussed before and if so what was the conclusion?
also is that part of the design or just a current state where some things are not working as intended?
1 Like
Turn off:
thanks, that solves one issue, what about the disappearing gizmo when switching to a different tool? any solution/ hidden option for that as well?
1 Like
That seems to be a work in progress issue, since most tools are supposed to have their own custom gizmos/widgets…
So I guess we need to wait for those implementations.
See my post 523 in this topic.
They changed the color of the top bar but it still blinking in edit mode. It’s impossible to do anything.
I’m also not a fan of this status bar on top of the viewport, but the way it is now is slightly better than before, it was far worse.
But yeah, if we could move it elsewhere would be nice.
yes it’s better, at least they made it transparent, but… the fact that whole row of buttons transforms into numbers back and forth is very distracting.
Also that info bar placed in a very bad spot because when you are working with an object it’s located at the center of the screen, but transformations info located at the far left top corner, it’s hard to watch what’s going on in two places simultaneously.
Here is an example with transform info from photoshop, cinema 4d, 3ds max they all showing it near the spot in which you are performing transformations:
bad quality because i grabbed those from youtube.
5 Likes