Feel free to download and use the build mentioned there.
If you have any specific requests related to updating the build or fixing issues, I will do my best to address them. However, please note that this thread is focused solely on the Snapping & precision modeling improvements task.
Snap to Edge divisions, instead of just the center. The user should be able to input any division number.
Snap on the edge, a specific distance from the edge vertex. For example, one meter increments from one vertex (Last hovered over), on the edge.
Direction increment snap. When translating, extruding, or similar, there is no way to snap to direction increments, such as 45, or 15, etc, degrees from the original location. The user can rotate object in 5 degrree increments when holding ctrl, but this should be more flexible, and among the snap options.
Reference line transformation. Step on 1: Set a point to rotate or scale around, step 2 select rotation axis. step 3: Set second point, step 4: Transform the selection by moving the two points (These points may snap to things), Step 5: apply. Other versions of this tool could be just for rotation, or just for scale.
Translate by inputing direction and distance. Currently, the user can input an axis of translate, but not something like āMove the selection 1 meter at 15 degrees on the z planeā.
Inputing a distance when moving should not lock the direction to an axis. Currently if you move an object and write a distance it automatically snaps to the X axis.
Reference point translation: Step 1: Select origin point, Step 2: Move the selection, by snapping the selected origin point somewhere. Step 3: Apply.
Click and drag - Confirm on release. Quick click - Confirm on second click. Both are very important and both should be always possible, instead of it being a global setting to use either one or the other. āRelease confirmā works better for organic modelling, āsecond click confirmā works better for precision modelling, because the user has to input numerical values on the Numpad. Especially important when an action takes multiple steps.
Automerge improvements: An edge crossing a face should create a vertex at the intersection. Two intersecting faces should create an edge between them. Two overlapping faces should cleanly create a face where they overlap, or merge into a single face. User optional.
Various multistep ways to create planes, boxes and other primitives using active tools, with numerical dimention or coordinate inputs for each step. Also, Various multistep ways to draw arcs, circles and ellipses: Specify two points, three points, specify center point then start and end, two points and degrees, etc. The last steps would be to set the divisions of the arc/circle by scrolling the mouse wheel (or numpad input) and apply.
A quick operator method: Select two vertexes, generate a circle or an arc between them with one operator, then adjust the last operator settings.
All āSnap toā options should be checkboxes. The user shouldnāt have to hold āShiftā to toggle multiple. Just click and drag.
Edge parallel snapping.
Fix the buggy desctructive extrude.
Precision first! Operators such as extrude, or modifiers such as āCurve to meshā or āSolidifyā should always default to āEven thicknessā.
Curve/Edge offset tools (with even thickness, of course). Also Face Inset with negative values allowed.
Replace the āKnifeā tool with a āDraw lineā and āDraw polylineā active tools. The cutting and merging should happen based on the automerge settings.
Move the numerical input box from the 3D view header to gizmos on the 3D view.
MOST IMPORTANT, yet most difficult: Allow unlimited holes on faces. This limitation creates extra edges that get in the way of precision modelling and boolean type workflows.
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?
