A while ago, @ermo and myself developed Precision Drawing Tools, that now ships with Blender and has for some time. This project is not complete yet as we realise there are still many aspects of CAD oriented workflows that need to be incorporated into Blender, not least of which is making 2D drawings. We have done some work in this area, but are yet to finalise an exact requirements document.
So, to that end, if anyone wants to suggest improvements and additions to PDT, please let either of us know here, or start an âIssueâ on the PDT GitHub page.
You will also find the Wiki there, which gives an insight into the sort of things it does currently. I have other projects on the go, so have quite a heavy schedule, considering I am retired!!! Anyway, either of us know if you have any more requirements for this project that you would like us to build in.
A lot of devs have been getting pulled away from feature improvements to work on code maintenance issues. Things like bug fixing and updating / optimizing code have been eating up a lot of development time.
The design looks weak. (Pressing B or multiple Bs? Snap to scene or not? Restore object position using threshold?)
Using a B modifier during the transformation turned out to be more of a workaround than a solution.
The ideal, apparently, would be to create a new shortcut to initialize the transform operation. But which shortcut?
One thing we have to keep in mind is that the shortcut has to be convenient for different types of transformations (Move - G, Rotate - R, Scale - S). But there are conflicts with [Ctrl + G, Ctrl + R, Ctrl + S] or [Alt + G, Alt + R, Alt + S] or [Shit + G, Shift + R, Shift + S]. Ctrl would be an ideal shortcut as it is the snap shortcut. But Ctrl + S is the âSaveâ shortcut.
So use Ctrl + Alt + S?
With this lack of decision I ended up being assigned to another project, but as soon as itâs done Iâll revisit the snap one.
I feel we could free up the âclear transformâ hotkeys, make it only alt+something and into a pie menu containing all options. Then we can use alt+g, r and s for basepoint snapping
Basepoint snap have higher relevancy value than it is needed to be assigned to Alt+G/R/S, such a combos better fit their current assignment.
I am not sure that it is possible to come with better solution than pressing B (and I spent several years designing Blender snapping addons in attempts to find a nice option, and I am AutoCAD/3dsmax/Sketchup user as well, so I am familiar with different snaps realizations)
During pressing GB RB and SB hand moves in clockwise, so it is ergonomically efficient, especially if to take into account that GB will be used much more often, and it is great that those keys are placed close to each other. I mean, that pressing GZ or RX is even less erconomic, but using them even on a regular basis does not create any problems.
As you can see, all the possible alternatives are much weaker - shortcuts are completely filled and even if to free them, shortcuts are less ergonomic than keystrokes.
Also, the goal of this development is to provide a nice wide range default option that will cover the essential part of demands, since dedicated CAD snap system requires a separate infrastructure for a limited range and better be made as an addon anyway.
I agree, a long time ago I realized that those three hotkeys were being taken up by what is basically the same operator so I built a custom Ctrl+A âreset and applyâ pie menu to free them up for other things.
I am not sure that there is a problem with restore object position, since it clearly shows that B button was pressed correctly. This allow to detect if you accidently pressed wrong button.
Such a visual feedback is important for fast work, so it make sense to ask to add it even if it possible to find a solution without it.
What about holding the G button while transform is active to activate basepoint snapping ?
Since G is already a key for transform, then you would use the same button for basepoint snapping, that is an efficient use of the same key without needing to move your finger to another key.
kinda how the snapping turns on when you hold ctrl while you transform an object
Lookinâ good ! any chance you can share it, so I donât have to make one myself ?
@dragosh double G activates vertex/edge slide in edit mode. Iâm not sure whether the input system can distinguish between a a double press and a press plus a hold, but I like the idea. Same for rotation, double R activates trackball rotation.
Any chance youâd submit the current design as implemented as an experimental feature? That way, people can at least use it while a (possibly) better design is figured out.
Pressholding is a speed killer because it is not confident.
The same issue as with holding ctrl - it is ok to use temporal override for 5-10 operations in a row, but if you need more you just turn on regular snap.
Not sure if it is a good option, since this will force user to switch basepoint snap option back and forth when it is necessary to alternate them often (which from my experience, happens all the time)
GB is a stable comprimise between those cases.
Pressholdings are ineffective by definition, because it cause lots of troubles during working with massive laggy scenes, and it always turns into a finger pushups if you try to work faster using them.
Blender generally trying to avoid using speedkillers (pressholdings, timing and directional actions, precise motoric actions, threshold delimited actions), and this makes its approach strong and universal.
Reason why i suggested press and hold option is because im using basic snapping a lot and i use ctrl to activate snapping like almost all the time cause my finger is there on the key all the time,
i also remapped my own keys, 2xRMB to cancel operation, RMB orbit, iâm lazy and i hate extra operations, pressing B after G would just make things harder for me cause i miss click the B button a lot,
thatâs mostly cause the G button is such a pain to use and its located in a uncomfortable position and i am using it like almost all the time, not to mention that iâm also trying to speed tap everything, which also creates issues of blender not registering my keys, so oftentimes when when transforming i press G so fast and then Z for axis lock when suddenly a pie menu pops up asking me:
âHello dear sir, would you like to change your viewport to this lovely Render of lagging death ?â and too bad i already changed the mode and iâm suddenly in the wireframe view, which ofc i didnt want.
These are my experiences so far, iâm lazy and i want to do everything efficiently or rather with less steps as possible, but sometimes the shortcuts are just making everything worse/harder
Well, indeed, lazyness (efficiency) is important, so we are testing relevancy factor and assigning appropriate solution.
For example, pressholding is ok for tab pie menu, to delimit fast object-edit mode and fast modes pie menu, but for quite highly relevant operation it does not pass laggy scenes filter (up to 20 000 - 40 000 objects per scene) like BIM imports, where basepoint snap is important for editing, but you have to dutifully hold button during the whole lag every time it is lagging.
It also block the ability to use local axis in GBZ or GBX way
Gatting a little more into Unreal lately Iâm starting to remember how much snapping and precision modeling is also vital for game artists. When you try to model everything on a fixed grid ⌠it sure works. Somehow. To some extend. But I donât know if Iâm missing something but is blender really not able to snap all selected vertices to the grid for example?
No, not independently. Theyâre snapped as a whole, unfortunately, even when using individual origins. However there might be a better way to do what you want to do ?
for this type of thing I just use a custom operator to quantize geometry on-demand. it doesnât really make sense to snap individual elements en masse while doing a transformation, because if everything is already on the grid, everything will still be on the grid if youâre transforming while snapping. Itâs far more frequent that you find an element that has been bumped slightly out of position and a quantization operator will move all verts to their nearest grid position.
Thatâs the problem exactly. Since snapping is currently averaged between the selection it makes it way to easy to bump individual vertices out of position. Itâs one of those errors that occurs quietly and can drag through unnoticed way too easy.
