Thank you for working on this. I mostly played with absolute grid snapping and found some issues.
Absolute Grid Snapping: In orthographic front/side/top views it snaps to a position far away from the origin
Possibly related to the above: if snap mode is set to grid and when viewed from orthographic front/side/top views, snap base point gizmo is not visible
Video
Absolute Grid Snapping: Prone to jumping off compared to Increment mode
Video
Absolute Grid Snapping: It does not work well with Z-axis constraint
@FreeMind, please don’t flood this thread with requests. I could hardly get anything out of that.
For each item:
Usefulness needs to be better discussed between artists
Already mentioned in the main task (Change the current behavior of the incremental snap: Snapping according to the distance to the snapping point and not to the grid)
Already mentioned in the main task (Change the current behavior of the incremental snap: Make the incremental value adjustable)
Usefulness needs to be evaluated as it changes the existing behavior too much and takes away part of the usability of the 3D cursor
Usefulness needs to be discussed, Blender already allows typing equations in location fields (eg. cos(45))
Partially incorrect statement - Press TAB to enter values for other axis.
Already mentioned in the main task (Transform Tools: Perform on a base point)
I agree but it’s not really related to “Snapping & precision modeling”
Already partially implemented with Edit Mesh: Improve 'AutoMerge'. The usability of face intersection needs to be better discussed between artists
OK! Added item: “Tool for creating Arcs” in the main task
Master: Activate rotate tool → Hold Ctrl → Rotate any axis → Rotation “snapping” works
PR105941: Activate rotate tool → Hold Ctrl → Rotate any axis → Rotations “snapping” doesn’t work. To make it work, you have to reverse the order and first start rotating and only then pressing and holding Ctrl.
PS. Are there any plans for adding adjustable parameters for the rotating snapping? People have been asking for this for years. As of right now it is either free rotation or only by mere 5° increment.
The main problem is that Ngon holes doesnot belong to mesh paradigm. Different software use Solid/NURBS engines or meta-mesh engines for that purposes, at the cost of an incompatibility with mesh file formats.
(Maya and Sketchup already faced that)
I can agree that there are lots of ideas that is possible to propose at this topic, but without proper testing of those ideas this topic will get messy.
Our studio already faced that when tried to design our local CAD toolsets, it just grow exponentially all the time.
However, we find 1point, 2point and 3point aligning transformations (from 3 base points to 3 target points - full matrix transformations) quite critical for precise modeling.
It can be used for new Align tool and for enhancing Bisect tool to make it more precise, making it following the desired edge with 2points, or desired face with 3points.
2pt and 3pt precise alignment of a 3dcursor and object origins is also mentionable.
I think it could be a nice goal after implementing 1pt basepoint snapping and current set of tasks.
To be fair, i can’t think of a use for this right now. Anyone?
Not only must it be adjustable, it should also work for the move tool, not just for rotation.
This does not affect current functionality, as It would be a unique active tool, similar to “Scale cage”. And it is indeed very useful. Here’s are some use examples:
A cube is rotated in edit mode. All sides of it are not perpendicular to the objects local axis. This tool would let the use align the cube to the local axis easily, or align the local axis to the cube, or align the cube to another non perpentidular face of another object, either in edit mode, or object mode, without adjusting the local axis etc. There are plenty of uses. Primarily, alignment, or alignement and scaling an object to perfectly fit between two points in space.
The user should not be doing math. Writing two numbers is easier. Input distance, Tab, input direction, apply.
It should not lock to an axis at all, unless the user asks it to. What should happen, by default, is that the movement distance gets locked, but the direction of movement continues to follow the mouse, Only when the user specifically inputs a direction it would lock to that direction. Pressin “X/Y/Z” would lock to an axis, typing the orientation in degrees would lock to that direction, clicking or inputting coordinates on a point in space would orient the movement towards it (Snapable).
It is related to UX for precision modeling.
Automerge is basically boolean, that happens when the model interacts with self after every action. Therefore, uses for Lines on face intersection, or face merging when faces overlap, are the same as when the user needs to use boolean operations in another way. It’s just a different, fast, workflow to get the same result as constantly using a boolean modifier. Maybe I could mock up a video of some use cases to show how fast and powerful this can be.
Snapping functionality and drawing tools are not the same. Use case: Move an object paralell to an edge of another object. Current workaround: You have to create a custom transform orientation…
It’s just a very simple papercut for me… Turning off “Even thickness” results in a crooked models with unprecise measurements.
Results that give precise, straight results, should have a priority. The same logic should apply everywhere. For example, the “Draw cube” tool is alright for organic modeling, but completely useless for precision modelling, as it does not let the user input precise coordinates and dimension while addint those cubes…
But there are no draw line/polyline active tools. That’s the main point.
Better presentation of number input boxes is Related to UX for precision modeling.
Here’s another thing i noticed: Snapping doesn’t work for The scale cage tool, It can only do increments, but not what is set in the snapping options.
3D Cursor was in center of old precision paradigm.
Not just one point mentioned by Freemind were relative to 3D Cursor use, but several.
3D Cursor was used as a reference point.
Since 2.8, it has rotation and became a reference orientation.
But it is not well exploited.
All Shift S menu operators are ignoring it.
There should be a task to improve 3D cursor rotation use and 3D Cursor use in general.
If you want to pertinently compare new tasks to 3D Cursor use, you have to release full potential of 3D cursor, first.
For instance, point 1 or 2 can currently be solved, using 3D Cursor.
Snap 3D Cursor to an edge with Align Rotation to Target option to orient 3D cursor like edge.
Then disable Align Rotation to Target option and snap 3D Cursor to vertex.
Then, move 3D cursor to specified distance using its own orientation.
Then snap to 3D Cursor.
But to be able to snap and create a modal keymap to trigger 3D Cursor movement like an object, user has to use Cursor active tool.
If this active tool had G,R,S as modal keymaps to trigger transform of 3D Cursor instead of tool, it would be more used.
Cursor active tool should be seen just as click and drag tool to place 3D Cursor, but as a mode to transform it.
Many to tools that we want to create about a reference point or or a reference orientation could be exposed as submodes of this tool.
Agree that it could be exploited much more, but the ability to click on a surface and get the rotation into the cursor and then set the cursor as the transform orientation is already quite useful
There are two main poles of a possible workflows - ARTwork and CADwork.
From the point of ARTwork any CADwork-related conditions and solutions (separate click, aliased wireframes, precision, exactness, linear but complex shapes and assemblies) will look cumbersome, superfluous, obsolete, boring and so one.
From the point of CADwork any ARTwork-related conditions and solutions (release confirms, antialiased wireframes with fresnel or other effects, vignettes, sketching and brushing unprecise actions, organic shapes and so one) will look superficial, cursory, insufficient and distracting.
For example, from the point of a CADwork and its requirements the ability to click on a surface and get the rotation into the 3d cursor is an insufficiently accurate/precise functionality because the result is exact only for a single axis (a normal, or Z-axis), even if it can be considered as useful in ARTwork.
To satisfy any CADwork case, it require satisfying minimal precision requirements - as the result of an action at least two axis should be aligned precisely.
Indeed, many options in Blender are focused only on normal and Z axis.
But the simple fact that 3D cursor is an orientation corresponding to 3 axis, now, should help for CAD work.
If alignment on Z axis can be already possible, just locking Z axis and adding a step to align X or Y axis of cursor to a target can radically improve its potential.
A major problem to define cursor rotation is that cursor wire is not coloured following color code for axis.
So, an overlay showing its orientation would be required for possible new tools to rotate it or align its orientation.
Currently the only way to know, what cursor orientation is while transforming it, is to enable a transform gizmo showing it.
Sure, but it is a separate design task.
For example, it is reasonable to set up center, then snap X and Y axis because it will set Z axis automatically.
Development is underway, and I am pleased to announce that yesterday, one of the long-proposed features was finally integrated into Blender. It is the ability to navigate while transforming (navigating during Move, Rotate, and Scale).
This feature can be enabled through an option located in the Keymap settings. This option had to be created because some modal modifier keys (such as using the mouse wheel to edit the influence of proportional editing) needed to be modified to avoid conflicts with the navigation shortcuts. Now, you have to press Alt in these cases.
In the description, you can find other links for more details.
Now it’s time to focus on another feature of Snapping & precision modeling improvements, with improvements in “Perform on a base point” and “Snap to Grid” being the most promising
One of the most awaited improvements… thank you very much @mano-wii
Now… waiting for snap base point.
Good job.
ps… Please consider working in snap bisect/knife on scene objects, not just in what is being edited… like 3ds ‘quick slice’ tool.
… and/or expose internal snap system to python api.
Hi, @mano-wii
Thank you for a new build. I’ve finally got some time to test it and I got a question about the way edge basepoint snap is performed.
Here is a video (sorry for the quality, my recorder is lagging for some reason, there are no visual lags during testing).
The problem is that (unlike unrestricted) axis-restricted basepoint snap doesnot follow the target when axis restriction is used during edge snapping. Can you please check/clarify it?