Gizmo Design #54661
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
17 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#54661
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 is an ongoing design document for the design of tool Gizmos in Blender 2.8.
About Gizmos
A 'gizmo' is a visual object on the screen which allows users to use tools in a visual, direct way. It both makes it easy to perform actions using tools along axes, but more importantly, it allows users to interactively adjust the result of using a tool.
Gizmos also help open up Blender to people who use it without a keyboard, and to people who haven't mastered all the shortcuts to use the many tools. This is not the only reason why we have gizmos though - we expect they will be used by experienced users too for added precision and control.
Here's a list of gizmos for Blender 2.8:
Move
Drag anywhere to move perpendicular to the view. Use the handles for axis specific movement.
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:
Rotate
Drag anywhere to rotate perpendicular to the view. Use the handles for axis specific rotation.
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:
Tick marks appear while holding down Ctrl for snapping:
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.
Extrude (Normal orientation):
After Initial Extrusion:
Use + to extrude again, or use arrow to adjust length.
Extrude (Global orientation):
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
Initially, the user is presented with this axis widget to start spinning on any axis. The user can choose if they want to spin on the X, Y or Z axis with a radio button in the Tool Settings. The Orientation follows the Scene Orientation.
When hovering over the handle, a circle is displayed to visualise the the spin:
When the user is performing the spin, the gizmo changes to make it possible to make adjustments. The large ring adjusts the angle. The rotation handles adjust the axis. The Arrows move the center point.
Select something new, or hit the + to start a new spin.
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
Adjust the Bisect plane using this manipulator. It works just like Move+Rotate combined, but with a transparent plane to visualise the cut plane.
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.
Shear Tool
This Gizmo works just like the Scale Gizmo. It allows users to shear along any axis, and uses the Scene Orientation setting to set the orientation.
To Sphere
The initial center point is controlled with the Pivot dropdown. After initial tool engagement, we display a gizmo to manipulate the center point, like so:
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.
Camera Gizmo
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:
Added subscribers: @WilliamReynish, @ideasman42
Added subscriber: @michaelknubben
Added subscriber: @brita
Added subscriber: @lichtwerk
not sure this is the right place, but reg. uniform scaling using the Scale manipulator we had this report ( #54482 ), 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.
@WilliamReynish : doh! (should have known better). Sorry for the noise
Added subscriber: @Rawalanche
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?
@Rawalanche : answered in #54482
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:
Added subscriber: @Okavango
@WilliamReynish 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.
Added subscriber: @LucianoMunoz
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.
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!.
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.
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.
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:
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.
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.
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:
What probably we want to do is this:
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.
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.
Added subscribers: @PawelLyczkowski-1, @JonathanWilliamson
@WilliamReynish It was my understanding that @PawelLyczkowski-1 and @JonathanWilliamson were in charge of the new Keymap? Has something changed?
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.
Added subscriber: @Ghostil
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!
Added subscriber: @wevon-2
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.
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.
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.
Added subscriber: @StanislavOvcharov
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.
Added subscriber: @L0Lock
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.
Changed status from 'Open' to: 'Resolved'
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.
Changed status from 'Resolved' to: 'Open'
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.
Added subscriber: @0o00o0oo
This is great! I have a few suggestions for extrusions that I think would be really helpful:
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
Added subscriber: @DuarteRamos
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 #45734, it would certainly make a lot of people happy.
Thanks all for your wonderful efforts so far.
It's probably also out of scope of Code Quest but i double this, #45734 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.
@WilliamReynish 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.
@WilliamReynish 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.
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" :)
@WilliamReynish 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.
Changed status from 'Open' to: 'Resolved'
Manipulator Widgets Designto Gizmo DesignChanged status from 'Resolved' to: 'Open'
Hey I have 2 questions
would there be a possibility to have the gizmos not dissapear maybe just dim when using them, the case with rotations in euler is that with the gizmo dissapearing is really hard to see how the euler axes are behaving.
also when using the location axes, if you have done rotations in the character, there is no way to use an axis specifically without it modifiying more than one curve what in maya would be "parent axis" mode, i would propose that this would happen when setting the axes to "normal" (instead of local or world), or introduce a special one for it.
Luciano: Correct, the gizmo now disappears when using rotate. It would be nice to keep the other axes visible but dimmed, while interacting with it.
Added subscriber: @Znio.G
i like how Viewport Manipulators work when u hover over their axes they are highlighted and easy to read, right now when u try to rotate is a bit confusing , maybe that's how the gizmos should behave too so u can remove those infinite lines or something.
Unfortunately, there is an annoying usability issue with rotate widget (and rotate mode in general):
Snapping in rotation mode activated either using free rotate tool or rotate gizmo is tied to "increment" snapping mode. This snapping mode combines move snapping to grid with rotate snapping to angular increments. These two are very different features for very different use cases.
I, for example, use mostly vertex snapping, which forces me to have increment snap mode disabled in favor of vertex snap mode, but then every time I rotate, and I can't snap interactively and instead have to pause and spend mental energy on calculating and typing the right value on the numpad. That breaks fluidity of the process.
In 2.8, we can now activate multiple snapping mode at the same time, so I can have Increment and Vertex mode enabled at the same time. That is not a solution though. The two interfere with each other significantly, and I am not interested in ever snapping to grid at all. The problems especially arise when the grid point aligns very closely to the vertex point I want to snap to. Then it's often impossible.
Since Gizmos are being touched here in 2.8, could we please, please.... finally decouple increment snap from rotation snap? Snapping meshes to grid in order to create for example a modular game level layout is completely different use case to snapping to angular increments when rotating them. These two should not be encompassed withing a single button/feature. I don't know of any other software which combines these two.
Changed status from 'Open' to: 'Archived'
This is a mega-task and not useful to keep open for the purpose of handling remaining issues, @WilliamReynish has already split most/all of these into smaller tasks.
Anything remaining from this tasks should be broken into smaller tasks - eg: #57220, #57234
Added subscriber: @DanielPaul