Custom Manipulators: New Transform Manipulator (Design) #47032
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
34 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#47032
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?
Custom Manipulators: New Transform Manipulator (Design)
Motivation
The current transform Manipulator is quite old and misses some industry standard features. Within the currently ongoing *Custom Manipulator Project //, we have the chance to redesign it from scratch with a more advanced feature set in mind.
Current State
A rewrite of the transform manipulator was already done in the [wiggly-widgets ]] branch (update, now in [ https:*developer.blender.org/diffusion/B/browse/custom-manipulators/ | custom-manipulators ). It’s similar to the old manipulator but has a couple of new features:
*The work done for this can be tested in the wiggly-widgets branch, but be aware that it's not considered stable yet.//
Call for Designs
To continue the transform manipulator rewrite and to slowly move things to a final phase, I need people to help me creating a final design. You can help by creating proposals or mockups.
It might help to split the discussion up into 3 different topics:
This task will be updated as discussions evolve.
Changed status to: 'Open'
Added subscriber: @JulianEisel
Added subscriber: @Lapineige
Added subscriber: @Januz
I'm really liking this, some thoughts:
The ghost widget is a cool idea, but maybe a ghosted outline of the object would be clearer. It would also help to "eyeball" distances. For objects where it would be too expensive to calculate (like >1 million polys) it could use a bounding box.
I don't think the ghost is really needed in scaling. Since there's the colored lines to see the axis already.
+1 For both rotation ideas.
Have you also considered having transformation data besides the object instead of the header? It could be clamped to the view3D limits so it doesn't go out of view. (Maybe this should be discussed in a bigger task in the future, since it would be inconsistent with the other modal ops)
When the 3D Widgets setting is on, shouldn't manipulator size become disabled? It doesn't seem affect the size anymore.
Also 3D Widgets could be renamed to something more specific like "Lock size to 3D View".
2D manipulators: I think it would basically be the same, with less axis. Planars wouldn't be necessary.
When all 3 manipulators are on at the same time, the white circle only does translation. Maybe there could be a second circle to do scaling too. EDIT: Actually two circles would be confusing. Maybe the uniform scale widget could be a square, then you can have circle+square.
The rotation lines could use an extra pixel of thickness. It would separate them better from the grid lines (specially when using shaded widgets), and it would give them a larger clickeable area.
Added subscriber: @hadrien
I dig this, thanks for all the work Severin.
ghost arrow is great, why not have it for planar transform as well ?
I second Diego's feedback : a way to have uniform scale included into the all-in-one gizmo would be handy
Added subscriber: @DuarteRamos
Added subscriber: @ClaasKuhnen
Julian,
If you need help with the proposal let me know and I will chip it. I have quite an experience in those areas from many systems I work with on a daily basis.
Maybe contact me via my email info AT ckbrd DOT de.
Claas
Hey guys, just a quick heads up: Thanks a lot for the comments, keep going! Currently I'm missing the time to answer thoughtfully, but in about 3 weeks everything should be back to normal and I'll be able to do that.
Hi Julain,
No problem, let me know when you have time and want to chat if you need feedback.
Really looking forward to this.
Claas
Added subscriber: @DavidUllmann
Added subscriber: @AditiaA.Pratama
Added subscriber: @JonathanWilliamson
Added subscriber: @PawelLyczkowski-1
Design: New Transform Manipulatorto Custom Manipulators: New Transform Manipulator (Design)Added subscriber: @blend-it
Can I suggest dual-color "little planes" for visual appearance of 2-axes constrained widgets (aka planar widgets)?
Added subscriber: @Blendify
Added subscriber: @bliblubli
for spot size widget aperture size appearance, a cone (the yellow one) instead of an arrow :-)
(original widget idea here )
Added subscriber: @Cenda
I love 2-axes constrain from Softimage.
demo here:
http://www.screencast.com/users/CenekStrichel/folders/Jing/media/c3da8c31-9b34-429d-8879-1e1f393792bb
Added subscriber: @ideasman42
@blend-it this task is specifically for the Transform widget.
@Cenda this is pretty slick, but seems to me the initial learning curve is a bit overly difficult. At least from the video (and having never used Softimage), the indication for current transform and for initial feedback on mouse position is not very obvious. It also would be very subject to confusion/conflict for people using the same mouse button for Action/Selection.
@JulianEisel +1 for each of these.
Alright, should really answer now :S Thanks again for the feedback!
@Januz,
@hadrien,
@blend-it, As Jonathan already said, it's kinda off-topic, but I'd indeed like to change this widget a bit. As it is now it's more of a proof of concept
@Cenda, would do it a bit differently (less confusing), but I think the general idea could work. Will try at some point.
Some more updates:
Looks great ! Just some remarks :
View axis rotation (white circle) does not interfere with other axes ? (it looks like they have similar radius)
Would the final design of the uv widget include planar transform as well as rotation circle ?
Also a more general question : ux-wise, is there a predefined way widgets are going to be tied to other operators ? I get that the transform manipulator has its own display toggle but bmesh operators for example don't. How are widgets going to fit in that picture ? Will current hotkeys for mesh operations be tied to "widget toggle" instead of the actual operation ?
After some thought, maybe uniform scale widget is overkill... I can't think of a design where it would not just clutter the whole thing. After all one just needs to press S to scale.
Ghosted object outline sounds cool, especially if it is subtle !
View space rotation widget shouldn't interfere with other axes, I usually have no problems selecting the right axes. (If you mean that with interference ;) )
UV transform manipulator should include planar transform and rotation circle, yep. Just didn't get around to do that yet. (Wanted to get some other stuff done first.)
Not exactly sure I get what you mean, I think you ask how modal operations like the knife tool would register a widget? There's support for attaching a widget to a modal operator. This means the widget is visible/accessible only as long as the modal operator runs.
Right, can't think of a good way either. I'm open for ideas though.
Added subscriber: @SpectreFirst
I think that many people who came to Blender from Hexagon and Silo will agree with me that Hexagon's universal manipulator is one of the best and I really hope that new Blender manipulator will be similar to it. In my opinion one of the biggest problems in Blender is rotation manipulator which clutters everything while being used with other manipulators. In Hexagon rotation parts of universal manipulator are cropped to small arcs so I would recommend to use the same approach.
http://www.versluis.com/wp-content/uploads/2015/05/Bridge-Tool.gif
I'm also used to the corner 2-axes constraints, but simple rectangles should work as well.
As for the scale part in the middle, I would rather prefer to have tweak manipulation just as it is now and since it looks like Blender uses distance between the clicked point and manipulator center as a scale value, adding scale point in the middle of the manipulator probably won't work anyway.
I don't have any initial ideas for how to tackle this, but I think that leaving out a universal scale on the widget is a very poor choice. The reason being is that many people will either choose to use the widgets exclusively, or not at all (particularly those using tablets). By leaving off an essential part of scaling from the widget simply breaks the ability to use the widget exclusively for those transform operations.
In my opinion the widgets for fundamental transform tools must enable all essential operations from the widget, with no need for keyboard input.
By this reasoning we have no need for widgets at all, since after all you just need press S, G, or R for transforms.
Added subscriber: @voyager25
Added rotation indicator overlay (9d8b0348b7).
Added subscriber: @chrisoffner3d
As mentioned *[here ]]and[[ https:twitter.com/ChrisOffner3D/status/715993254014140417 | here ]]on Twitter and what Julian[ https://twitter.com/Severin_b3d/status/716002707702685697 | asked me to add here:
When it comes to tackling the Scale manipulator it would be nice to avoid an annoying issue I see with almost all Scale manipulators in any 3D software:
So it would be nice to design a scale manipulator handle which lets you scale on a plane even if that plane is parallel to the camera axis. I do remember seeing a scale manipulator somewhere which at the tip end of for example the Y axis handle had a secondary little handle which allowed you to scale on the XZ plane. Alternatively that could also be a little plane handle with some slight "thickness" to it which goes through the Y axis arrow - as shown in my first mockup with the torus side view example. As long as this handle is also visible and reachable in an orthographic side view where the targeted plane is parallel to the camera axis, it should do the trick just fine.
How would a little yellow cube in the center of the widget clutter up the whole thing?
Am I misunderstanding what you mean by 'uniform scale widget'?
Alternatively, here's how MODO does uniform scaling - with a cyan circle at the center:
MODO's scale tool does however suffer from the same issue mentioned in my previous comment.
Added subscriber: @chris-35
Chris, the difficulty is integrating scale with translate and rotate as well. Unless we make it impossible to display all three at once ? but would'nt it be a tad lame ?
Aah, I see. How about having three shapes at the center, like in the MODO cyan ring example? A square for uniform scale (square signifies scale), then inside that a ring for free form rotation (if that is considered necessary) (ring signifies rotation) and inside that a triangle for free form (screen space) translation (triangle signifies "direction")?
Might be cluttered but maybe it's worth a try to make it visually pleasing?
Maybe uniform transforms better be offset from the center, which as you said is busy already. I could picture a uniform scale widget like this yellow handle :
Like Alex pointed out ("since it looks like Blender uses distance between the clicked point and manipulator center as a scale value, adding scale point in the middle of the manipulator probably won't work anyway.")
How it is positioned, not sure. Fixed orientation ? Screen or world space ? It is difficult to make things not overlap.
In this mockup, the scale handles are moved out from the rotate circle so that there is more space for clicking in the center (for both viewplane grab and trackball rotate).
Added subscriber: @VukGardasevic
With all dew respect that's a straw man argument. :)
An example could be made - for instance even the universal scale widget will fail to do anything if a single vertex is selected, ergo we don't need it, heck we don't even need scale transform. :)
Of course, joking and logical fallacies aside many people will use both the widgets and the keyboard shortcuts depending on the situation. The thing is, like always, how something is done.
There are three problems:
Looking only at the first one - that decision can be to a certain extent arbitrary and subjective (with limitations of being understandable) however the 2 and 3 are function related so that's the real problem like it was pointed out in previous posts. Personally, the third one is the most interesting for me how it could be done.
Without trying to derail the discussion about the visual design - how is it planned that the new universal manipulator widget will be triggered/activated?
Is it going to be by SHIFT+clicking the
SpaceView3D.transform_manipulatorsicons in the 3D view's header, like you currently do in Edit mode when combining different selection modes by SHIFT+clicking on the vertex/edge/face selection icons?If so, will there be versions where only Translate & Scale handles are visible in the manipulator but no Rotate (and likewise with all other combinations of two out of the three transform options)?
Added subscriber: @wevon-2
Maya uses MMB for dragging handles and attributes forn anywere of screen.
If you click over a handles becomes selectet (idem for attributes) and then you can use MMB for dragging it.
Blender use MMB for camera rotate, and RMB for dragging objects. RMB could be used in Maya MMB way. This works for the rotate and scale manipulators too. If there isn't any manipulator in viewer, could work like now, dragging from the camera point of view.
There is some incompativity, because in Blender, RMB popups a menu over attributes :(
@JulianEisel asked me for some designs, so here they are. The idea is here for the manipulator to be lighter and less intrusive, staying away from the thing that is selected, unless a handle hits the edge of the screen, then it stays on-screen of course. On the second mockup the handles stay on the edges even when the selection doesn't take much of the 3d View. I haven't read the whole task yet btw.
Here is some more. Here handles are at the edge of the selection, unless they would be off-screen, then they stay on-screen and overlay the selection.
I'm not sold on this idea btw, just exploring.
Maybe a middle ground - you have a circular work area inside your view 3d, defined by viewport ratio, and transform manipulator handles stay on it's edge. Would minimize handles being in the way for LMB selection scheme.
Here it is with the 2-Axis handles. They work like @chrisoffner3d described.
Added subscriber: @AxelMening-4
axis mess - my version :)
in blend file 3d manipulator made of mesh
3DManipulator.blend
@PawelLyczkowski-1 interesting idea with widgets on the boundary of the selection...I have a hard time imagining it working in practice, though. The main reason being that your handles would be constantly moving with the view angle and would require constant recalculation in order to not obscure the selection. Additionally it presents the problem of the handles being very far apart from one another (in many instances), requiring much more mouse movement to manipulate them. Extra mouse movement needs to be avoided to reduce fatigue.
The biggest issue, though, in my opinion is that it'd be almost impossible to form muscle memory around the widget its self, as it's components would be in relative, ever-changing locations.
Thanks a bunch for the mockups @PawelLyczkowski-1! I have a similar opinion on them as @JonathanWilliamson though, especially possible muscle memory breakage and long mouse movements scare me a bit (performance shouldn't be an issue, old manipulator used to recalc all its data on every redraw).
Still good to consider such different alternatives, that's exactly why I was asking you for mockups :)
Note that Blender is already able to distinguish between a simple click-action and a drag-action, which can be used for solving the vertex selection vs. manipulator dragging conflict. Setting the vertex selection operator to a 'Click' event and the manipulator tweak operator to 'Tweak' does the trick and I find it really intuitive. We should definitely consider it for the new keymap.
I added support for customizable keymaps for manipulators some while back to the wiggly-widgets branch btw, so it can be tested there too.
You haven't run into any problems with that? I did into some. Will have to test again to see what they are exactly.
@wevon-2, your suggestion better fits into #47345 since it applies to all manipulators, not just transform manipulator.
@chrisoffner3d, It's already possible to combine different transform types by shift-clicking the icons in current vanilla Blender. It should work just like that ;)
One idea I have been having is for the camera widget. Currently, there is no ability to edit the properties of the camera without looking through the menus. It would be great if these can be accessed while looking through the camera.
Added subscriber: @0o00o0oo
I'm not sure if this would be covered in the scope of this task, but would it be possible to register drag direction as positive?
I find myself kind of blindly hitting, say, "1" then hitting the "-" when realizing it needed to go the other way.
It would be nice if I dragged in a direction, Blender would automatically register that as positive, overriding the need to do the guesswork.
It's really weird. It's not ever been a feature in Blender, but I still catch myself expecting the transformation to happen in the direction I drag if I punch in a number.
Added subscriber: @YuryBaranov
@JulianEisel Idea of handle that allows to scale object on two axes that are parallel to viewplane is pretty good, please consider it. As well as similar planar handle for UV-space.
would it be also possible to enable the ability to rotate the widget so you can by hand create a local orientation.
Step 1:
Activate Widget only adjustment (rotation + position)
Step 2:
Adjust widget as needed
Step 3:
Deactivate Widget adjustment
Step 4:
Use widget now for custom local manipulation inside edit/object mode
Added subscriber: @dballesg
Hi,
After read the posts here, and saw the CAD Snapping addon by Mano-Wii, it remembered me the notion of "mini wigdets". We could have them outside the manipulator's Bounding Box, allowing to select between Grab, Rotate, Scale, and Global, Local, Normal, Gimbal and View, without need to travel all the way through the interface.
I didn't added them on the User Persp view, but they will need to appear as well. And I didn't all the possible combinations, becuase with those I thought it shows the idea more clearly.
Grab / Global
Grab / Local
Rotate / Global
Rotate / Local
Scale / Global
Scale / Local
Cheers,
David
Added subscriber: @mano-wii
Nice idea, I like it.
I'm not a big fan of the borders around the letters and would prefer to keep it cleaner and more minimal. Just the letters, a littler bolder and with cleaner and crisper drawing than what we see on your screenshots, might work though.
I for one am in need to change the manipulator space all the time (Global, Local, Normal etc.), so having this right in the viewport would be useful.
Not sure if we really need to also have the G/R/S icons on there. Switching between Grab, Rotate and Scale is something I personally feel is very intuitive hotkey behaviour and not something that would have to add to visual clutter on the manipulator.
It's not something I'm fiercely against either though. Just throwing out there where I see potential to reduce things to the essentials.
Hi Chris,
The borders where there to create a clicking region.
I did the mockup bassed on other text that you can see on Blender's viewport, and I'm not sure that text can be antialiased. Maybe can be done with a small icon image but I don't know how that will affect people with high D.P.I monitors.
I wasn't sure about the G/R/S either. Maybe it will be better to have it as an option on the manipulator, so the user can hide/show it.
Cheers,
David
Yeah, in that case I'd prefer to have clean solid squares, maybe half-transparent, and the letters cut out of them (i.e. the letters form negative space). In any case I think it should be antialiased so that the manipulator looks more legible and modern.
Making G/R/S an option is an option ;P but I'm generally in favour of designers and developers making design decisions instead of pushing it on the user by adding every possible option imaginable. As Blenders users, we already have more than enough options and preferences to juggle.
Let's not add more where it isn't really needed.
Without giving much importance to the 3D cursor, we can have the next interaction with the 3D manipulator, leaving the right mouse button to select exclusively.
Seeing the fourth drawing, where the planes are added to the manipulator, if the arrows are preserved, the current interaction is kept, thus any transformation plane is accessible.
Added subscriber: @bunny
This is a godsend for animation. Thank you!
Testing 43b415b, the planar widgets disappear when combining the Translate and Rotate widgets by shift-clicking the icons in the header. It would be very helpful if they remained with Translate + Rotate active, just like they do with Translate + Scale active.
I'd also appreciate the rotation rings having some width, so when the manipulator is scaled with UserPreferencesView.widget_scale they're easier to grab and feel more 2D, like ribbons, whereas they currently feel bulky and 3D, like tubes.
Currently the widget_scale setting mentioned above is limited to a maximum of 200, and doesn't allow a higher number to be typed in directly. Estimating from its size at 200, on a large 4K screen I'd like it to be at 800 or 1000, and in VR probably bigger than that.
Finally, I think a little yellow cube in the center is really simple and intuitive for uniform scale. The language of arrows meaning translate, rings meaning rotate and cubes meaning scale is really great, and the grab hotspot is large enough to accommodate a ghosted yellow cube appearing there when Translate + Scale were active. Click and drag on the yellow cube to scale, click and drag outside the cube but within the grab hotspot to translate.
Yuk! It's been a while since I answered here... sorry guys...
I have some plans for this, but let's discuss this once I opened up a separate design task for camera manipulators.
I find that confusing too, but it's indeed not in scope of this task. Tip: The arrows of the transform manipulators always point towards the positive direction.
I wouldn't consider this part of the design of transform manipulators, IMHO it should be handled as a separate design task. But yes, something like this would be nice and manipulators could be used for intuitive tweaking.
I'm not so sure about this, for people that don't use the manipulators all the time and only keep them visible they are nothing but visual clutter. IMHO this is functionality that can be implemented as an add-on, people that want to use it can enable it.
Re images #2 & 3: I guess you mean being able to select a transform manipulator axis, so that the next time you LMB-drag the transformation will be constrained to the selected axis? I thought about this idea too - it might be pretty handy - but I'm afraid it will be annoying for people who switch back and forth between using manipulators and shortcuts/LMB-drag: they'd always have to make sure no axis is selected if they want unconstrained transformation using LMB-drag. I yet have to find a proper solution to this.
Re images #4 & 5: I'm an absolute opponent of using modifier keys to toggle functionality. In most cases, they are bad & lazy design :) In this specific case, the functionality of planar transformation manipulators is far too useful to hide them behind a modifier key, people will have a hard time discovering it. IMHO they should simply always be visible (or only on mouse hover?).
Yeah, but it's kinda tricky... how can we combine all the manipulators without causing visual clutter/conflicts? IMHO it's fine to neglect the planar manipulators when rotation & translation manipulators are combined (or rotation & scale).
Hmmm, I'd argue the current rotation manipulators feel pretty lightweight and don't block the view too much. I can see why you'd want the other (IMHO more bulky!) ones though, would be interesting to test it a bit.
Right, having such a low limit there seems stupid. Committed 83c17d8de8.
Yes indeed, this looks like a solution that could work.
Hi Julian, you have understood how to select the manipulator, but deselecting it is as simple as selecting another manipulator or attribute. The manipulator of movement has a small circle that would allow to recover the movement with respect to the view. Perhaps you have been confused by the third drawing that shows a single manipulator, since the action is being performed. This way you can use the whole area of the 3D view to activate the selected manipulator in exchange for losing the direct access to the 3D cusor.
I think you could add the "active attribute / manipulator" concept, referring to the last attribute or manipulator that has been used or selected. LMB would modify this active "attribute / manipulator" from any empty area (of manipulators) of the 3D view. Sometimes this attribute could be directly related to a manipulator but sometimes not.
Figures 4 and 5 show the current operation of the tool, but with visual indication.
Frankly speaking, I don’t really understand why are we trying to reinvent the wheel here giving the fact that universal manipulators were already implemented in several different applications (Hexagon, Silo, Modo) and are already working perfectly fine for more than a decade. As someone who has been modeling with universal manipulators for more than twelve years, I have to say that this topic is not just a funny concept that I would like to play with, this is an absolutely vital part of my workflow so please excuse me if some of my observations sound harsh.
So, why do we even want to modify the existing setup while all three manipulators are presented on screen?
Well, what is my proposal in this case? Simple: let’s add planar handles and trim rotational circles to make them less cumbersome. Here is my mockup of how it could be done without sacrificing any productivity and with all possible combinations of modes. As you can see, I’ve just added planar handles and moved them around a bit so they won’t interfere with each other when enabled together. The only tricky case is that you’ll have to make two versions of Rotate manipulator but again, that scheme has been working perfectly fine in other programs so I don’t see any reasons why it should not work in Blender.
Added subscriber: @Kosyne
I too would like to see something like the 'Universal' manipulator that Alex mentioned. Maybe even a toggle of some sort to choose exactly what functionality you want on the manipulator (in case some users find it is unwieldy or adds clutter)
This comment was removed by @hadrien
Your mockup looks good Alex ! only two remarks :
We are not accounting for the gimbal rotate handles... yet another thing to consider.
Added subscriber: @jta
Added subscriber: @MikeErwin
Added subscriber: @kwj
I like it already, but there are two things missing:
This little circle at center for free rotation in viewport which I used a lot for Pose mode on bones and that little box for free move in UV editor, since without it we still have to use "G" for free move.
Take a look at image from Alex, please fix it otherwise it feels kinda incomplete.
Added subscriber: @bdube-1
When the manipulator widget for the 2D image editor is done, I would like to see some or all of that applied to scaling and transforming background images in the 3D viewport. The current state is not that bad, but my use case involves many background images that need to be accurately scaled and positioned.
I apologize if this is already mentioned above. I did check, but the page is getting long.
Added subscriber: @ArtturiMantysaari
Hi, I also made one mockup about the manipulator without knowing that someone was already doing a work with it. So I share my mockup here also:
My idea for that design was, that those circles are "cut points" for some specific axis. For example, if you press circle on the Z-axis, you will cut the connection to Z axis and you are able to move it on all the other axis, except Z. (shift + Z).
My original topic: https://blender.community/c/rightclickselect/kzbbbc/#5a1a9d211de2fb4c48e7a5b9
Added subscriber: @Znio.G
Changed status from 'Open' to: 'Archived'