Manipulator Widgets Design
Closed, ResolvedPublic

Description

Requirements.

  • Visualise Snapping Better (Tick marks when holding down Ctrl, for example)
  • A way to make it clear when widgets are creating new extrusions vs tweaking the existing one

Widgets Needed:

Move

Drag anywhere to move perpendicular to the view. Use the handles for axis specific movement.

Rotate

Drag anywhere to rotate perpendicular to the view. Use the handles for axis specific rotation.

Scale

Drag anywhere to scale uniformly. Use the handles for axis specific scaling.

Extrude

Drag on the plus icon always extrudes out, or drag anywhere to extrude freely. After the user has done this, an 'arrow' widget appears which lets the user adjust the current extrusion. The orientation depends on the scene Orientation setting in the top bar. A Normal arrow is always displayed since this is the most common operation, but you can also extrude along any of the axes in Global, Local... etc space. The top bar also has a setting called Steps to set extrusion steps.

Top Bar: XYZ, Steps, Orientation

Extrude (Normal orientation):

Extrude (Global orientation):

Extrude (Global orientation, after extrusion):

Curve Extrude

Curve Extrude is a separate tool, which is a good demonstration of the kinds of tools we can build with Blender 2.8. It presents the user with a manipulator for moving the extrusion. When the user does this, handles appear on either side of the extruded 'bridge'. These can be extended to change the curve of the extrusion. Cuts can be added in between to make the curve finer or more coarse.

Spin

The middle circle plane controls set the spin center point. The rotation controls adjust the plane of the spin operation. The Jupiter-style ring adjusts the angle of the spin from 0% to 360%.

Top Bar: Steps, Angle, Axis, Center

Inset Faces


Drag anywhere to inset. Release to confirm.
This widget appears in the top left of the viewport. It lets you visualize the inset from 0% to 100%. Click the plus icon to create a new inset

Top Bar: %, Outset, Relative, Individual etc..

Bevel

Pull the lever to inscrease bevel distance.

Top bar: Amount, Segments, Profile, Vertex Only, etc.

Bisect

Click the blue, green or red plane to set the bisect plane to the X, Y or Z plane defined by the current Orientation setting. The bisect plane itself can be dragged to move it back and forth. The round handles can be used to rotate it freely.

Randomize

The user clicks and drags anywhere to increase randomness, or uses the control to set a value.

Loop Cut


The user clicks and drags on an edge loop to create a loop cut and slide it along the edge. The manipulator can be used to set the % from A to B.

Bend Tool

The user enables the Bend tool, which places a manipulator (Point 1) on the 3D Cursor, aligned according to the scene orientation control. The user can then click and drag on any of the axes to set a bend direction and distance. This creates a new point (point 2), which then represents the bend amount and direction.

Primitives

Plane

The user can drag out to create the plane. From here, the user can drag the blue ring to increase the scale. The red and green handles can be used to scale the primitive in X and Y.

Cube

The user can drag out the cube to create it. From here, the user can scale it along X and Y.

UV Sphere & ICO Sphere

The user can drag out to create the sphere. From here, the user can drag the blue ring to increase the scale. The red and green handles can be used to scale the primitive in X and Y.

Cylinder

The user can drag out to create the cylinder. From here, the user can drag the blue ring to increase the base size. The blue handle can be used to set the height. The red and green handles can be used to scale the primitive in X and Y.

Cone

The user can drag out to create the cone. From here, the user can drag the blue ring to increase the base size. The blue handle can be used to set the height. The red and green handles can be used to scale the primitive in X and Y.

Torus

The user can drag out to create the torus. From here, the user can drag the blue ring to increase the major radius size. The white handle can be used to set the minor radius size.

Widget Info:

When using manipulators, we can improve the visual feedback when they are engaged. Currently, we don't communicate things like distance and deltas very clearly. This would be good to improve, like so:

Degrees displayed in the pie-chart rotation widget:

Rotation degrees are very disconnected from the rotation widget. We should connect it more visually to the rotation delta, like so:

Distance clearly communicated differently from the axis of movement:

As demonstrated here, it has been very difficult to visually judge the delta of movement before. We should fix that:

Scale difference clearly shown while dragging:

Tick marks appear while holding down Ctrl for snapping:

Camera manipulators

When inside the camera view, users have no easy way of controlling the camera position, rotation and zoom. Camera operators need to distinctly control panning on each axis, as well as dollying in/out, left/right, and craning up/down. Users also need to be able to easily zoom their camera. We could place camera widget controls inside the camera view, like so:


//These are the current designs for the manipulator widgets

Details

Type
Design
There are a very large number of changes, so older changes are hidden. Show Older Changes

not sure this is the right place, but reg. uniform scaling using the Scale manipulator we had this report ( T54482 ), maybe someone has an idea?

Philipp: As it stands now in 2.8, this issue is already fixed. Drag from anywhere to scale uniform, so you don\t have to use the circle.

@William Reynish (billreynish) : doh! (should have known better). Sorry for the noise

Philipp: As it stands now in 2.8, this issue is already fixed. Drag from anywhere to scale uniform, so you don\t have to use the circle.

How will this work for people who have dragging primary mouse button in the viewport already assigned to something else, such as box selection? Won't that interfere? Furthermore, if Blender 2.8 comes with revised input mapping, which would be more consistent with mainstream conventions, won't it be preferable to have dragging with primary mouse button perform box selection?

Yes, we probably should fix this issue regardless, yes.. The little ring it also very hard to select. You have to hit the ring exactly, it doesn't register if you drag from anywhere inside it.

Yes, we probably should fix this issue regardless, yes.. The little ring it also very hard to select. You have to hit the ring exactly, it doesn't register if you drag from anywhere inside it.

I still don't believe it should be solved by dragging primary mouse button from anywhere in the viewport. Let's say Blender 2.8 input map would get reworked to have marquee selection similar to most of other software and operating systems, where you drag LMB to marquee select multiple entities, so that the new users can adapt it faster. Or let's say some user has his keymap already customized so that it behaves this way. Dragging LMB anywhere in the viewport is way too lucrative action to be reserved for uniform action of transform gizmo. I know that this will only happen when the gizmo is active, but let's say I'd like to transform a few objects in the viewport around, either doing uniform scale or screen space translate:

Current 2.79 state:
1, Select objects
2, Transform
3, Select another set of objects
4, Transform

Proposed 2.8 state:
1, Select objects
2, Enable transform gizmo
3, Transform
4, Disable transform gizmo
5, Select another set of objects
6, Enable transform gizmo
7, Transform

Having to constantly keep making a choice between being able to select objects and being able to transform them is a scary proposition, considering how frequent both of these actions are in both scene level manipulation and modeling.

How about having an overlay circle over move and resize gizmo, similar to one on rotate gizmo. When you would get your mouse cursor anywhere near the manipulator (specified radius from the center of the manipulator), but not near the actual transform axis manipulator, the overlay circle would occur, indicating you can drag to perform screen space translation or uniform resize. This would still allow you to have primary mouse button click and drag reserved for actual selection or other things, as long as the cursor is not in the proximity of the manipulator. At the same time, it would solve the problem of central ring being hard to select. On top of that, it would make all 3 manipulators appear to have similar design:

@William Reynish (billreynish) William, i am not sure this qualifies under this task, but i guess it is a UI/UX issue.

PLEASE, if it is possible, do something about having to type ''-'' when your numerical input ends up in the different direction from the one you initiated with the rotation manipulator. If i grab the rotation wheel and rotate it to one side THAT is the side i want to rotate it to, whether it is positive or negative, why do we have to care about 'minus' or 'plus' and type them along with the numerical input? Let the program read the direction from the manipulator gesture.

The same goes to the 'move' manipulator - if i specify the axes with the mouse, why can't i specify the direction with the mouse?! I lost so much time and momentum with this issue in past years...

And a couple suggestions on the design of the manipulators. Although not a lot of people appreciate those little squares for restricted plane transformation i am sure architecture users do - moving things across the floor or along the wall. Nice addition!

I have tried them though, perhaps they could be just a little bit bigger related to the arrows, or tweakable in the user preferences. Also, a little bit stronger preselection flash, right now it is somewhat hard to spot.

Also, please don't forget those who use multiple transform manipulators at once - the scale and move constraint squares would merge and the operator wouldn't be able to tell what user wants to do - scale or move. Perhaps some reconsideration on the design of scale constraints?

For the rotation manipulator, it would be nice if the numerical angle value would appear while doing the transformation, much like with the spin manipulator. The 'plus' and 'minus' mark could appear here, but please, not required by user (suggestion above).

Another thought on the constraint squares - They are probably useful for beginners and probably should be kept. But! - aside from being tweakable in size, why not totally toggleable? If they make too much clutter, you turn them off in preferences, and the constraint feature goes automatically back to SHIFT+arrow handle, just like the power users are used to? Just a thought...

Okavango: We are thinking of making manipulators an Overlay option, so yes, you'd be able to disable them this way.

Ludvik Koutny: The plan is to make it so you don't have to disable a tool, even if you make a new selection. That way, you can keep the Move tool active, and just switch selections and move. There would be no extra steps as you suggest.

And yes, the circle around scale is one we've actually considered for precisely the reason you outline.

Ludvik Koutny: The plan is to make it so you don't have to disable a tool, even if you make a new selection. That way, you can keep the Move tool active, and just switch selections and move. There would be no extra steps as you suggest.

And yes, the circle around scale is one we've actually considered for precisely the reason you outline.

Hi,

so does this mean that I could perform border select using LMB without actually having to switch to border select tool and then back to move tool? Border select makes up the majority of my selection operations. Right now, it looks like LMB drag to perform border select would not work as long as active tool is move.

I am worrying about a precedent of border select being a tool. I don't think that border select can be considered tool of the same calibre as move, rotate, resize or modeling tools. Selection of multiple objects and mesh elements is something that should always work alongside all the other tools, as selections are performed pretty much all the time. Current design portrays border selection as a specific tool that needs to be switched to, and then switched back from.

Ludvik Koutny:

Your question has several answers. First, all of those things ultimately depend on the keymap. If you are building your own, it's hard to answer your question, because it then depends on how you set it up.

By default, the left mouse button executes the active tool. If you have the Move tool enabled, dragging with LMB moves the selected item. If you were to switch to LMB select, you'd need some way to switch. One way to solve it, is to simply switch to the select tool. This could be executed using a hotkey to make it faster than always clicking the tool in the toolbar. Another way would be by holding some kind of modifier key, so that if the user is not using the select tool, he/she can still select things by holding, say, the Ctrl key.

Ludvik Koutny:

Your question has several answers. First, all of those things ultimately depend on the keymap. If you are building your own, it's hard to answer your question, because it then depends on how you set it up.

By default, the left mouse button executes the active tool. If you have the Move tool enabled, dragging with LMB moves the selected item. If you were to switch to LMB select, you'd need some way to switch. One way to solve it, is to simply switch to the select tool. This could be executed using a hotkey to make it faster than always clicking the tool in the toolbar. Another way would be by holding some kind of modifier key, so that if the user is not using the select tool, he/she can still select things by holding, say, the Ctrl key.

Yes, that's exactly what I was afraid of.

I do have my own keymap indeed. And I am very well aware I will be able to customize it, but as I stated many times, deep customization should never be an excuse for poor default behaviors. I don't care about myself and my workflow that much here. I care for Blender to be usable for everyone. If I recommend Blender 2.8 to my friends or colleagues, I don't want them to be instantly discouraged and their first impression of Blender heavily damaged for years to come, like it is a case with 2.79 and prior versions.

I really hope that there will be efforts to minimize amount of those dumbfounding moments that Blender currently confronts first time users with. Having activating a basic transform tool effectively disabling users input is one of such moments. There is not any other 3D package out there where activating a transform tool would effectively disable border selection input.

Blender's design guidelines clearly state that UI should be non blocking and non modal. Yet, following the proposed philosophy, pretty much every active tool becomes modal, because it blocks user's mouse input over the entire area of a viewport.

I am very well aware I will be able to switch the tools using hotkeys. I assume that to be the default because it's impossible to be anywhere near proficiency with button click workflow. But even then, what I wrote a few posts above applies:
Current 2.79 state:
1, Select objects
2, Transform
3, Select another set of objects
4, Transform

Proposed 2.8 state:
1, Select objects
2, Enable transform gizmo
3, Transform
4, Disable transform gizmo
5, Select another set of objects
6, Enable transform gizmo
7, Transform

Having border select being a regular modal tool like any other forces users to choose between selecting objects and performing tool operations at any given point in time. If you watch any Blender modeling video on for example YouTube, you will notice how incredibly frequent operation selection is. People select things all the time. And in half of the cases, they don't select just one object or element, but multiple at once, so border selection is equally as frequent operation as regular click selection. In object mode, in edit mode, in node editor, in graph editor, everywhere.

Given how frequent task it is, requiring an UI interaction or a hotkey press prior to executing it effectively almost doubles the amount of required keys pressed or GUI interactions throughout the workflow.

My point is that for Blender to be truly efficient and user friendly, border selection should not be considered a tool that needs to be switched to and switched from by pressing a hotkey, but rather as something omnipresent that is always ready to receive your input at any time, because of how frequent task it is.

It works that way in Windows and Linux file explorer, even in all the web browsers and text editors. Imagine having to press a key to switch to a text highlight selection mode every time you want to highlight and copy a text in your web browser of choice, and then having to press a key again to switch back to the scrolling mode so you can scroll.

My suggestion is having border selection always on primary mouse button drag (with modifier key variations for adding to and subtracting from the selection), and then having actual uniform/screen space transform to be for example on the secondary mouse button. I know secondary mouse button will have a context menu, but Blender is really great at distinguishing a static click from click and drag, so you could still have secondary mouse button click to be a context menu, while secondary mouse button click and drag to be use of an active tool.

Given that RMB selects, i wouldnt mind having RMB drag select in box mode, and with Ctrl Modifier be turned to lasso.
I think that would be totally great TBH.

It also seems to me that "lasso, circle, and box" select shouldnt be considered tools but secondary ways to the RMB selection.
Also I would encourage the change from circle selec to paint select because circle feels like you'll get a circle selection like in photoshop, because box select does that, draws a box.

Love you guys, keep it up!.

Given that RMB selects, i wouldnt mind having RMB drag select in box mode, and with Ctrl Modifier be turned to lasso.
I think that would be totally great TBH.

It also seems to me that "lasso, circle, and box" select shouldnt be considered tools but secondary ways to the RMB selection.
Also I would encourage the change from circle selec to paint select because circle feels like you'll get a circle selection like in photoshop, because box select does that, draws a box.

Love you guys, keep it up!.

Well, hopefully RMB won't select by default in 2.8 anymore. It's one of those things that ruin the first impression :)

Luciano: Yes, I thought of that too. The right-click-drag to move feature is now pretty redundant. We might as well just allow users to right-click and drag to do box select.

Ludvik: We have not yet decided to set Blender to use LMB by default. Personally, I'm sympathetic to that idea, and it could have some other advantages, like opening up RMB for other, more useful things. The downside is that users then have to switch between action and selection.

Luciano: Yes, I thought of that too. The right-click-drag to move feature is now pretty redundant. We might as well just allow users to right-click and drag to do box select.

Ludvik: We have not yet decided to set Blender to use LMB by default. Personally, I'm sympathetic to that idea, and it could have some other advantages, like opening up RMB for other, more useful things. The downside is that users then have to switch between action and selection.

Well, isn't that actually easily solved by having RMB as action button for the active tool? I mean RMB click would be context menu, but RMB click and drag could do exactly what LMB click and drag does now. In my customized keymap for 2.79, I have RMB assigned as tweak mode and it works well while not interfering with LMB selection in any way.

I wanted to make a practical example, unfortunately keymap is broken in 2.8 currently as some input things are hardcoded.

With this solution, you could for example activate bevel tool, use LMB drag to border select a few faces you want to bevel, then do RMB drag to bevel them, then to LMB drag to select another few faces, and then RMB drag to bevel those as well. All these actions could be performed at once, without any interruption, without a single UI button click or a single keyboard button press.

At the same time RMB click and release could be still assigned to context menu.

Luciano: Yes, I thought of that too. The right-click-drag to move feature is now pretty redundant. We might as well just allow users to right-click and drag to do box select.

Ludvik: We have not yet decided to set Blender to use LMB by default. Personally, I'm sympathetic to that idea, and it could have some other advantages, like opening up RMB for other, more useful things. The downside is that users then have to switch between action and selection.

Hey :)

So actually nevermind my previous post. I was able to configure it just barely enough to showcase what I mean. I have made you a video here: https://youtu.be/_0x0Icp-Rx8

Hopefully this will make it clear.

Ludvik: It could work that way, yes. But then that means that interacting with manipulator widgets etc is also done with RMB to avoid clashing with selection. If the main rationale for making LMB select the default is to make Blender more 'standard', then that solution would be equally as non-standard, just in a different way, and I can't really see the advantage.

Some of the solutions that involve LMB to select could simply follow more standard 3D app conventions. It's not like people aren't able to get work done in other 3D software, even if they have to switch between selection and action. People make entire feature films working this way, and it's fine.

The other thing is, for paint/sculpt etc, your solution would mean that you paint with RMB, which I don't think is a great idea, esp for tablets, which would become very awkward, and probably not a good default setup.

In general terms, I think we should do two things:

1: Have a way to preserve RMB select, but make it more consistent, so that RMB-drag is box select. LMB is used to perform the action and use manipulators. Otherwise it works more or less like today.

This would be useful for people used to Blender's current interaction model.

2: Have a different way to use Blender in a way that follows more standard conventions. That could mean many things, such as:

  • LMB to Select
  • RMB for context menus
  • A quick way to switch between select and action tools
  • W E & R for Move, Rotate and Scale
  • Q key for selection
  • etc.

This would be very useful for people who switch between many apps, and maybe don't already use Blender, but would like to integrate it into their workflow.

Ludvik: It could work that way, yes. But then that means that interacting with manipulator widgets etc is also done with RMB to avoid clashing with selection. If the main rationale for making LMB select the default is to make Blender more 'standard', then that solution would be equally as non-standard, just in a different way, and I can't really see the advantage.

Some of the solutions that involve LMB to select could simply follow more standard 3D app conventions. It's not like people aren't able to get work done in other 3D software, even if they have to switch between selection and action. People make entire feature films working this way, and it's fine.

Yes, that is the thing.

I have used quite a few pieces of 3D software that have conventional selection input mapping, but they still use gizmos. It turns out, the overlap of selection and actions is not that much of an issue really. The gizmos are not that huge that they can occlude large part of the geometry, and if they do, then you can always hide them temporarily using a button or a hotkey. But the fact is that a transform gizmo overlapping elements that need to be selected is such a minor issues that other softwares don't even address it, since user's don't care.

Blender on the other hand took this small issue so seriously it has built the overkilled right mouse button-centric workflow around it, which harmed the first impression it made on users and steepened the learning curve a lot.

About that RMB action non standard, I just can't agree here. I mean you will still be able to interact with all the graphical 3D manipulators with your LMB, and AFAIK you plan to have graphical manipulators even for the mesh tools.

The concept of executing a tool action by clicking anywhere in the viewport itself is a very non-standard thing, so having it mapped to a non standard mouse input is not that big of an issue. So I don't think it's good to take an absolutist stance in this case, saying that either nothing is standard, or everything is. Look at it this way: The concept of having RMB drag anywhere in the viewport performing action of an active tool is still a way easier concept for new users to grasp than having to select objects with RMB and having to press B key prior to every border selection. Let alone the confusion added by the selection being additive by default.

So yes, RMB drag is uncommon concept, but so is having a mouse input mapping to activate tool from anywhere in the viewport.

The other thing is, for paint/sculpt etc, your solution would mean that you paint with RMB, which I don't think is a great idea, esp for tablets, which would become very awkward, and probably not a good default setup.

In general terms, I think we should do two things:

1: Have a way to preserve RMB select, but make it more consistent, so that RMB-drag is box select. LMB is used to perform the action and use manipulators. Otherwise it works more or less like today.

This would be useful for people used to Blender's current interaction model.

2: Have a different way to use Blender in a way that follows more standard conventions. That could mean many things, such as:

  • LMB to Select
  • RMB for context menus
  • A quick way to switch between select and action tools
  • W E & R for Move, Rotate and Scale
  • Q key for selection
  • etc.

    This would be very useful for people who switch between many apps, and maybe don't already use Blender, but would like to integrate it into their workflow.

Sorry, I was too fast and did not expect you to follow up.

Sculpting and painting is not an issue. You would still paint with LMB. It would work as expected. The reason you don't need LMB selection in paint and sculpt modes is that you generally don't select things in paint or sculpt modes :)

Check this out:
https://blenderartists.org/forum/showthread.php?447451-Standardized-Keymap-for-Blender

It is a complete keymap overhaul I have done for 2.79. I have spend around 80 hours on it. It is extremely thorough. It shows how all these things can work well in practice in Blender, without any conflicts.
I have made a complete sheet of all the keys:
https://docs.google.com/spreadsheets/d/1PlPCwj9t5m21ef5k9dhlHc3nQ-d69XS5vzTmm3TpMks/edit#gid=0

I even made a video series going over the overhaul:
https://www.youtube.com/playlist?list=PLajSMib9Z7qwadE1_vkgCUuxzg3j1hCSs

This keymap implements almost everything you mentioned in your bullet point list, except the context menus. That's just because Blender 2.79 doesn't have a concept of context menus yet.

The keymap itself can be found here:
https://drive.google.com/file/d/1qozxfQW_TKQvQGWmWaR2NhngEKybVKAV/view

If you have 2.79 installed and a little bit of time, give it a try. I think you will be surprised how well it works :)

That's cool. A few more thoughts, after discussing with Campbell Barton:

  • Blender 2.8 actually allows us to follow industry standard conventions even more, if we chose to, because of Active Tools, which can be activated via hotkeys. This was not possible in Blender 2.79 and earlier.
  • This means we can truly make QWER keys work properly in a way that's compatible with the industry standard, which we couldn't do before.
  • In 2.79 and earlier, left click to select never worked well with the Blender keymap. Several tools were impossible to use in this configuration. We should not offer an option that doesn't work well, and leads to user error. We also have to consider why people use LMB select in the first place (because they want it to behave in a standard way)
  • Many of the old alternative keymaps were not well maintained, and few people use them. There were too many.

What probably we want to do is this:

  1. Keep Blender's keymap the default, and mostly as-is, with a few minor tweaks here and there to improve internal consistency. We would like to drop LMB-select completely here, because it doesn't work well, and doesn't follow standards, and makes working with tools awkward.
  2. Add a second 'Industry Standard' keymap that works truly like industry standard apps. That means things like LMB to select, QWER for Select, Move, Rotate, Scale. F to focus. A to view all. T to show/hide manipulator. That kind of thing. This keymap we will make sure is well maintained, and works properly for all tools and modes.

This approach will greatly simplify things, and will make it so we can make things really, truly work well with LMB to select. It means there's two options: the Blender way and the industry standard way, and that's it. It's simple. Old Blender users can use the Blender keymap, and people who use Blender next to other 3D apps can use the Industry Standard keymap. This way we think we can maintain it well, and keep the most users happy.

That's cool. A few more thoughts, after discussing with Campbell Barton:

  • Blender 2.8 actually allows us to follow industry standard conventions even more, if we chose to, because of Active Tools, which can be activated via hotkeys. This was not possible in Blender 2.79 and earlier.
  • This means we can truly make QWER keys work properly in a way that's compatible with the industry standard, which we couldn't do before.
  • In 2.79 and earlier, left click to select never worked well with the Blender keymap. Several tools were impossible to use in this configuration. We should not offer an option that doesn't work well, and leads to user error. We also have to consider why people use LMB select in the first place (because they want it to behave in a standard way)
  • Many of the old alternative keymaps were not well maintained, and few people use them. There were too many.

What probably we want to do is this:

  1. Keep Blender's keymap the default, and mostly as-is, with a few minor tweaks here and there to improve internal consistency. We would like to drop LMB-select completely here, because it doesn't work well, and doesn't follow standards, and makes working with tools awkward.
  2. Add a second 'Industry Standard' keymap that works truly like industry standard apps. That means things like LMB to select, QWER for Select, Move, Rotate, Scale. F to focus. A to view all. T to show/hide manipulator. That kind of thing. This keymap we will make sure is well maintained, and works properly for all tools and modes.

    This approach will greatly simplify things, and will make it so we can make things really, truly work well with LMB to select. It means there's two options: the Blender way and the industry standard way, and that's it. It's simple. Old Blender users can use the Blender keymap, and people who use Blender next to other 3D apps can use the Industry Standard keymap. This way we think we can maintain it well, and keep the most users happy.

I agree here, it makes sense. But it would be good to introduce that choice already at a software launch, so newbies don't have to dig for it in some preferences menu :)

As for the QWER keys, they work in my keymap posted above just fine. The only issue there was that transform manipulators were missing assign hotkey context menu entry.

Also, in my keymap, I have resolved vast majority of the conflicts that made some tools unusable with left click select. That keymap is truly a total conversion. Every tool and every editor should be usable, no conflicts at all. I have yet to find one.

I hope you can use it as an inspiration for the industry standard variation for Blender 2.8. Just keep in mind it's meant to work with 2.79, not 2.8. But it truly makes Blender feel like whole different, a lot simpler to use piece of software.

For sure, we would want to make it easy to switch on startup.

Looking at your keymap might be helpful, although Blender 2.8 allows for us to actually emulate the industry standard interaction method much better than before, so we might want to solve things somewhat differently than you did for the 2.7 version, in which you had to work within the old limitations.

In fact, we may need help to actually create this 'industry standard' keymap. As you know, it's a fairly big job in itself.

The goal would be to make it truly like industry standard apps, where the W key activates the Move tool and lets you drag to move. Q for the select tool, and so on. RMB for context menus.

If you agree with this goal, and seeing as you experience doing this, would you be be interested in working with us to make it?

If so, we would create a Design Task here on developer.blender.org, where we can keep track of the Industry Standard keymap design. You could then start by implementing basic things like viewport controls, and QWER. Only add things that truly work. We could then keep a list of issues that might be needed to be changed in Blender to make sure the Industry Standard keymap works properly.

By then end, we could ship Blender 2.8 with the two keymaps. What do you say? Blender 2.8 might still be too rough to really make the final keymap, but we could start with a few basic things to get the ball rolling.

For sure, we would want to make it easy to switch on startup.

Looking at your keymap might be helpful, although Blender 2.8 allows for us to actually emulate the industry standard interaction method much better than before, so we might want to solve things somewhat differently than you did for the 2.7 version, in which you had to work within the old limitations.

In fact, we may need help to actually create this 'industry standard' keymap. As you know, it's a fairly big job in itself.

The goal would be to make it truly like industry standard apps, where the W key activates the Move tool and lets you drag to move. Q for the select tool, and so on. RMB for context menus.

If you agree with this goal, and seeing as you experience doing this, would you be be interested in working with us to make it?

If so, we would create a Design Task here on developer.blender.org, where we can keep track of the Industry Standard keymap design. You could then start by implementing basic things like viewport controls, and QWER. Only add things that truly work. We could then keep a list of issues that might be needed to be changed in Blender to make sure the Industry Standard keymap works properly.

By then end, we could ship Blender 2.8 with the two keymaps. What do you say? Blender 2.8 might still be too rough to really make the final keymap, but we could start with a few basic things to get the ball rolling.

Oh absolutely. I'd be more than happy to!

In fact, that was already my intention when I was doing this 2.79 one. I can do the same thing for 2.8 and I'd be happy to get feedback straight from the developers :)

Just let me know what I have to do.

Thanks.

This keymap discussion is off topic. I will start a new design task on this topic somewhere else, and until then we don't allow the keymap discussion to continue here.

In 2.8, will the interactive creation of polygons be as in many paid packages judging by the manipulators described for primitives?
It's great.

Hey that same INSET widget that appears in the top bar, would be useful for "pose breakdowner", and also for when using stuff like scaling brushes, or intensities of brushes and such stuff, would be a great addition that nothing depends completely on the mouse!

I would like to remember this concept of manipulator of transformation of objects, based on a free axis and a circle, I find it very interesting as an alternative to the current one.

https://github.com/a-nakanosora/Circle-N

A question a little out of topic: it would be possible to use the manipulators of transformation in sculpt mode combined with masks to restrict the movement of some vertices, to improve the performance of these in dense objects? I say this because Grab is infinitely faster than Proportional Editing but does not allow to adjust the pivot. Thanks.

https://www.youtube.com/watch?v=qbK9al4pMbE
Here's something like this I hope there will be in view of will be in 2.8 if I correctly understood the description above for primitives?

Vyacheslav: Yes, you understand correctly. That's more or less what we want to have, plus the ability to adjust with widgets after the fact.

Vyacheslav: Yes, you understand correctly. That's more or less what we want to have, plus the ability to adjust with widgets after the fact.

Super. In the UV editor, too, there will be manipulators for working with the vertex mode, which I really like. I hope there will also be a new interface with buttons?

Those are unfinished - more work needed.

Those are unfinished - more work needed.

In the new version of the anti-aliasing group, similar 3D 3d will not be added? I do not know where it can be discussed so I'll ask here. Many do not use a blender for moding games because it does not know how to set the anti-aliasing group as in max.

What about combined widget at least for Loc+Rot? It is kinda useful for animation.

Yes, we have that too. In 2.8 it's the Transform tool.

will we be able to turn off the "interactive creation" of primitives?

Probably, yes. The tool controls the underlying operator. Pressing Shift-A will most likely work just as it does today. The manipulators are only available when you activate the relevant primitive tool. Just like the Move tool is different from just pressing G, etc.

I would like to talk about VALVe's Source Film Maker, there is a widget named "screen manipulator". I think it has some pretty good ideas that we could have in Blender :

It's basically a screen space widget with for areas of action and it's own pivot point.
The big orange circle rotates the selection on the screenspace
The middle square moves the selection on the screenspace
Any screenspace action can be switched to screenspace depth action via holding a modifier key (i think shift). Holding down the modifier will make the current action take place in the remaining axis, basically, until the modifier is released.
Clicking and dragging will trackball rotate, as does our current light grey circle widget.
And most importantly :
The pivot point is always the widget's center.
The widget can be moved via the little orange dash on the left, which will move the widget and it's pivot point, but not the selection
Double-clicking that dash will bring back the widget (and it's pivot point) on the selection's origin.

As SFM has several snapping solutions like vertex, edge, face, object origin, ... This tool is very powerful, especially in animation as we want to rotate and translate all the time and wish to change pivot points all the time, it's really time gain.
I think we can really take some things from that, whether in Blender's widgets or in 3D cursor.

Most of that is covered by using the 3D Cursor as your origin. And in Blender 2.8, we want to make it so the 3D Cursor can snap to verts, edges, faces etc and can store orientations. This will make all or the kinds of things you mentioned much easier.

Yes, but some things are lacking, like being able to move the 3D cursor manually in the 3D space, simple snap to object's origin or any other type of snapping just on a keypress on-the-fly during the manipulation. And for now, managing the 3D cursor is done in a separated way. If you're manipulating an object and suddenly need to change pivot point, you have to stop manipulating, do several shortcuts, selections, and clicks to manipulate the 3D cursor, eventually switch back and forth between object/edit/pause modes, and then go back to manipulation.
While SFM's "screen manipulator" workflow is to let you manipulate your selection and your pivot point within a minimum amount of actions, and that is possible because of their widget and on-the-fly snapping types shortcuts (I realize I forget to talk about that, perhaps it's not the best place too...).

For now, we can almost do that by using the Shift S menu and changing the snapping options between two manipulations, of course. But it's heavier.

Dalai Felinto (dfelinto) closed this task as Resolved.May 7 2018, 9:28 AM

Hi,

sorry for commenting on already closed task. There's one thing that won't stop bugging me, and it's somewhat related to the new manipulators:

One problem with manipulators in 2.79 was that when you were rotating with manipulator, you still often had to resort to reaching for numpad to type precise rotation, because it happens very frequently that you want to rotate something exactly 90 or 180 degrees.

You can use snap for that, but a big problem with snap in Blender is that it groups incremental move snap with incremental rotation snap. Let's say you are working on a precise scene so you use vertex snap very often. Every time you want to rotate something precisely, you have to first switch snapping mode to increment, then activate it while rotating, and once you finish rotation, you have to switch snapping mode back from increment to vertex. This is quite frustrating experience.

So my suggestion would be to have hard-coded snap for rotation widget, so that when you hold down whatever is assigned as a snap key, in rotation mode, it will always snap to angular increments regardless of if the active snap mode is increment or not. It would help a lot with the workflow.

Great initiative on Widget Info! That's how you do it :)

It would also be great if values displayed in the widgets would sync with display unit selection that we discussed elsewhere.

This is great! I have a few suggestions for extrusions that I think would be really helpful:

  1. A "distance" value slot for precise extrusions.
  2. Quick buttons to toggle "individual" and "vertex normal" extrusions.
  3. Ideal behavior is all selected elements being extruded the same way. For example, like how Maya allows for scaling all individual face extrusions: https://youtu.be/3mvIl3nyz7Q?t=138

It would also be useful if some, if not all, the adjustable parameters actually appeared in the 3D Viewport near where the extrusion is taking place. This will allow users to keep their mouse near the manipulator instead of traveling to the top bar and back constantly.

KiJeon (0o00o0oo):

1: The distance we would like to implement via the 'tweak UI' concept. You can also already type values while extruding.

2: Individual and Vertex Normal Extrude are currently different tools. We might combine them, although it's not currently possible. The issue is that those different types of extrusions have different settings, and we don't have a method of displaying various settings depending on a 'type' setting. If we do get this working, we could perhaps combine all the extrude tools into one, which I agree would be nicer.

3: Not sure what you mean. You want vertex normal extrude to be default?

4: Same answer as #1. We will use the Tweak UI to do this

The visual feedback of manipulators will make life a lot easier for newcomers and "eyeballed" modeling.

I wonder if you are planning better snapping to geometry support for manipulators during operation.
Some can already be snapped to vertex, but wider support would be welcome and make them a lot more useful for precision modeling.
As it stands they are not yet very suited for hard surface modeling or situations where geometric precision or alignement is more desirable.

If it somehow integrated with a workflow similar to the outlined at T45734, it would certainly make a lot of people happy.

Thanks all for your wonderful efforts so far.

Some can already be snapped to vertex, but wider support would be welcome and make them a lot more useful for precision modeling.
As it stands they are not yet very suited for hard surface modeling or situations where geometric precision or alignement is more desirable.

If it somehow integrated with a workflow similar to the outlined at T45734, it would certainly make a lot of people happy.

It's probably also out of scope of Code Quest but i double this, T45734 was a must for a more serious level of modeling. It's a pity it stalled.

Added these features to the operators of NP Station and using them often.

@William Reynish (billreynish) For #3, Maybe this helps more: https://youtu.be/aKwE_tzV7l8?t=238. It looks like it's a mirrored operation, but it's not.

Each face selected gets individually extruded along their normals and able to be scaled without changing the pivot to individual.
I don't know if the current 2.8 extrude tool is designed to behaves this way, but this would be quite useful.

Another useful extrusion option, though not quite as priority as ones I listed, would be a thickness option for both vertex and edge extrusions. Example: https://youtu.be/dJh-5Yqe2L0?t=1408

That's Extrude Along Normals. We have had that type of extrusion in Blender for years, and will be adding it to the 2.8 toolbar also. It's on the todo already.

As for the second part, vertex and edge bevel extrude is also very useful. We should probably add that at some point, although it's not a high priority for now.

@William Reynish (billreynish) Actually, you're right, it's pretty much the same behavior. I think my main thing is when scaling individually extruded faces, it'd be more useful to have them scale on their individual origins by default temporarily.

For me, 1) That's the expected behavior, 2) Has more usage cases, 3) Saves from killing extrude, just to change the pivot to individual origins to scale, then to change back to the original pivot.

I wonder whether it will be possible to change the size of the manipulators? The manipulator for extrusion seems to me sometimes too big.
Will the manipulators for the uv editor be reworked? It would be nice to have there 2 options for working with faces, 1 as of now, and 2 same arrows as for vertices.

In the same way that the new extrusion tool allows to move in the transformation coordinates and in the normal one, I was wondering if it would be convenient to unify the transformation tools in edit mode a bit.

Extrude manipulators are unfinished still. They are too big, and secondary axes are too prominent. We have plans to make improvements in this area.

As for the multi-tool manipulator, it’s an interesting idea, but most likely not something we’d like to pursue. The different tools have different options and work in different ways, so it’s not as straightforward as one might think to combine them.

Also, we want to avoid error prone behaviors, where users might hit the wrong handle. This kind of thing could be implemented as an addon, though.

Extrude manipulators are unfinished still. They are too big, and secondary axes are too prominent. We have plans to make improvements in this area.

As for the multi-tool manipulator, it’s an interesting idea, but most likely not something we’d like to pursue. The different tools have different options and work in different ways, so it’s not as straightforward as one might think to combine them.

Also, we want to avoid error prone behaviors, where users might hit the wrong handle. This kind of thing could be implemented as an addon, though.

I am still quite curious what the secondary axes are for. I don't think I would ever see anyone needing to extrude along other axis than the local face Z one.

There has been some discussion on BlenderArtists about combining Inset and Extrude tool into one tool, something like "Face Bevel", which could do both what Inset and Extrude does. It would also fix the current issue of there being no face bevel in Blender (Bevel works only on edges or vertices even in face mode, and is currently supplemented by Inset tool with Ctrl key held down).

Modo has something like that (and I think Maya too), where manipulator has two handles, one for extrude axis, and one for inset axis, and effectively you are getting 3 tools inside one. It's that much more convenient since extrude and inset operations are often rapidly used in tandem during modeling, so users would not have to constantly switch between inset and extrude, or look in manual and search on internet how to do "Face bevel" :)

@William Reynish (billreynish) The Curve Extrusion tool looks very intuitive, and far superior to what Maya has.

One question: Could the curve also allow creating custom points (with bezier handles) to manipulate the curvature?
Maybe click along the curve to add a point. Drag and pull to delete a point.

We already talked about that kind of a possibility. It would probably make the tool harder to make, so for now we’ll most likely hold off on doing that, but perhaps it can be revisited later on.

Dalai Felinto (dfelinto) closed this task as Resolved.May 28 2018, 6:30 PM