Wouldn’t Individual Elements ideally be a Snap With option instead of a separate Snap To section? Any Snap To option (like Face Nearest) that doesn’t work with the selected Snap With could be hidden or greyed out.
If we have presets, I don’t think we’d need the Target Selection options for every Snap To option. What’s the use case there? It seems like overkill and could end up being more work to toggle all of them when switching. Plus, it makes it so that the user has to remember what’s enabled or disabled if the filter is off.
Overall, I’m really happy to see this getting some attention. Thank you!
Yes and that’s absolutely fine. It just shouldn’t be one over the other just because of an assumption how the users should work. Especially not if it’s a (relatively speaking) minor thing like whether to have presets or not. If settings could be stored per viewport and there are presets then this should cover the whole range, I think.
I don’t either. I’m trying various combination of Move, Press B (or hold B, or click B ), to snap one vertex to another and cannot determine what exactly is supposed to be happening. There’s a “circle indicator” appearing in some arbitrary place near the desired target, and the chosen vertex moves without any predictability.
If I just cntl-move, everything moves and snaps as expected. So not sure what this “B Key mode” is meant to do.
Did you downloaded special test build?
It works pretty simple
you start transform operation
then press B to enter basepoint snapping mode, the selection transform is reset to indicate that mode was enabled and provide a possible source for snapping base.
LMB to set snap base (snap from)
LMB to set snap target (snap to) to finish operation
This idea was proposed before by the way. If you need precision transforms often/in a row, it is assumed that you perform very CAD-like workflow (like drafting).
I guess there should be no problem to add “autobase mode” checkbox in snapping preferences, that will allow to start any transform operation from setting basepoint first automatically for such kind of a purposes, but it is needed to be consulted with Germano.
One alternative I’ve suggested before was to make waiting for base point be an operator parameter instead, and be an option of the supported transform modes, like transform.translate or transform.rotate when invoked (by keyboard shortcut, menu or toolbar button).
That would open up the possibility for users to set up multiple different hotkeys for each behavior, like say have G behave normally like it does now, and set up a new key like say W to ask for a base point first, or even making it a global keymap preference one could toggle (for precision modellers), like the ones now available on the keymap preferences header.
I think that drafting workflow support is a design task that require a separate attention to design because of a multiple possible solutions (by tools, by modes, by prefs, etc) and specific conditions to test and satisfy, and also to avoid heavy functional fractioning which is a cost of any functional flexibility.
At the moment the basepoint snapping solution is focused on being safe - it is minimalistic, versatile and makes possible critically demanded things that was impossible before.
It is a neat but sure step.
For example, “autobase mode checkbox” approach is not directly compatible with gizmo/active tools transform paradigm, however, gizmo/active tools transform paradigm has never been supposed to be easily compatible with precise CAD-like actions which are typical for drafting, since the initial goal of their design is to satisfy ARTwork rather than CADwork, while B-key solution affords soft transition from gizmos to modals during transform operation.
It doesnot necessairly makes autobase solution bad, I would like to have it since falling into pure modals solutions is quite typical for precision-dependent workflows, but it makes such a solution too limited to start from.
Even watching your video and reading the step by step, this makes no sense at all to me. The actions on my screen do not match your video. Is there some hotkey in preferences I’m supposed to be assigning for this build to activate this test feature?
Yes. Start grabbing something in object mode or edit mode. During grabbing press B to set two points - the basepoint and its target (from - to)
Similar technique works for rotation and scaling transforms.
Base point snapping is not meant for a single vertex. Select the entire cube, and then use B to choose which part of the cube you want to snap with. If you have a single vertex you almost certainly want that vertex as the base point anyway.
Your supposed to press B after starting the move operation (pressing G or while dragging a gizmo), not before.
This will allow you to pick which part of an arbitrarily complex geometry will snap to a target, instead of the old behavior which would always snapped the closest one.
Effectively, the B key puts one into a new mode, but there’s little (if any?) messaging/feedback on the screen to indicate i’ve entered a new special mode.
The targeting selection seems somewhat arbitrary; I cannot repeat the “correct steps” at will - sometimes the edge ends up where I expected, sometimes not.
#1 could benefit from something similar to this third-party add-on, which displays via text in the view what is going on.
Even with that, I’m struggling to do the same. It is incredibly frustrating.
Like, throw-something-at-the-wall-level-screaming-FRACK!!! level of frustration.
For comparison’s sake: This snapping plugin took me less than 30 seconds to understand and start using productively: QuickSnap - Blender Market
ETA: After another 10 minutes of clicking and yelling, I’ve finally found the “finger click drag rhythm” this requires; I’ve noted that one does not “press b” to set the initial snap point - one needs to HOLD B DOWN, “nagivate a target circle to the desired spot”, then let go of B.
Pressing B just picks some point (wherever you happened to let go of), and then continues the movement with bad results. Personally, I think there are too many finger gymastics/chording required. It’s not elegant, and not enjoyable at all.
Maybe it require some time.
I know about this addon (and several oothers), it doesnot look compatible with gizmos and heavy alternating. It is similar to autobase functionality proposed before.
(But I like they promote snapping to invisible geometry as a feature, while it was cut out from Blender since 2.8. There are a lot of cut things that have to be replaced with addons and sometimes it even can’t be solved at the addon level.)
That’s weird, such an action was planned to be disabled by default because of sumultaneous pressholdings during working with gizmos. It should be clicking B to initialize basepoint search instead of a holding.
Both modals are supposed to be “press” by default, and setting the second to “release” will turn clicking B into holding B if is needed by someone.
Ok, the mystery continues to unravel. If I HOLD B, and never let go of the LMB, then it begins the “set origin point” procedure.
So press B not actually required (though it does work, which leads to user confusion as to “what am I supposed to be doing?”)
This system does work, once you determine the secret of the key combos. But until then, it’s like playing Tetris in Hell with blender giving you no idea whatsoever as to what is going on. I really do not like it having to be a two-key combo - ie, a “sub action of move, but first you have to move”.
Maybe it’s a language thing? To me , Press is not the same thing as Hold. (forgive me if that statement sounds accusatory or insulting, i absolutely mean no offense as i know we have many different cultures here)
Such a concept isnt new, there are others subactions like switching between global vs local axis restriction (GX vs GXX), grab vs loop slide (G vs GG), numeric input during axis restriction (RZ30) and so one. It exists from the very beginning of a Blender.
Press = a single moment button reach bottom
Release = a single moment button reach top after press
Click = press + release
Hold = prolonged retention
