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. Personally, the third one is the most interesting for me how it could be done. 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. How it affects the mouse pointer location/ movement control of the size by having a fixed starting position to activate.Location - where is going to be placed on the gizmo to not interfere with the other transform widgets if they are all enabled.First is the look - visual representation of it (icon, simbol, area etc.), is it clear enough to understand, does it clutter the widget making other functions more difficult to identify.The thing is, like always, how something is done.
Of course, joking and logical fallacies aside many people will use both the widgets and the keyboard shortcuts depending on the situation. :)Īn 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. With all dew respect that's a straw man argument.
I'm open for ideas though.Īfter all one just needs to press S to scale.īy this reasoning we have no need for widgets at all, since after all you just need press S, G, or R for transforms. After all one just needs to press S to scale. I can't think of a design where it would not just clutter the whole thing. This means the widget is visible/accessible only as long as the modal operator runs.Īfter some thought, maybe uniform scale widget is overkill. 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. 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 ? (Wanted to get some other stuff done first.)Īlso 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. UV transform manipulator should include planar transform and rotation circle, yep. Would the final design of the uv widget include planar transform as well as rotation circle ? View space rotation widget shouldn't interfere with other axes, I usually have no problems selecting the right axes. View axis rotation (white circle) does not interfere with other axes ? (it looks like they have similar radius) Clicking inside of outer white circle of rotation manipulator triggers trackball rotation now (also added mouse hover feedback):.As it is now it's more of a proof of Strichel (cenda), would do it a bit differently (less confusing), but I think the general idea could work. Planar transform ghost: Committed (blend-it), As Jonathan already said, it's kinda off-topic, but I'd indeed like to change this widget a bit.Rotation line thickness: Committed Brissaud (hadrien),.Uniform scale widget: Would be cool to have, but will wait for some further proposals on how manipulator will look (esp.Renaming "3D Widgets": Committed rBe13d05ba856f.3D Widgets: Think manipulator size should have an affect even with 3D Widgets enabled.Transformation data: Yes I'd like to have the current value printed in 3D View too, even as a general widget feature.Ghost when scaling: Indeed, I'd say we either visualize it better or remove it.Would like to hear opinions from others though. Ghosted object outline: Yes, could work.Alright, should really answer now :S Thanks again for the Gangl (januz),
0 kommentar(er)
