Now that I think of it, the Two parallel lines icon would be better suited for Parallel to edge snapping…
1 Like
Two parallel lines icon would be better suited for Parallel snapping…
Always has been.
Because it is logical.
1 Like
Correct me if I’m wrong, but from what I gathered on this thread, it seems what most people liked about the “Minimal” icon set was how informative it was. The way icons rotated to the snapped geometry helped disambiguate what was being snapped to, this seems superior to industry standard for dense geometry and complex scenes.
I come from a CAD background, I very familiar with the so called “industry standard”, but I don’t have a strong feeling either way. I’d adapt well to a new set of icons, and also enjoyed that aspect of the minimal icon set.
Maybe a good compromise would be some middle ground combining the best aspects of both. Keep the current industry standard icons, but make them “attach” to related geometry like minimal where possible. Rotate the perpendicular icon to actually be perpendicular to the snapped edge; align the “hourglass” to the edge direction; add some form of normal indicator to the face snap.
10 Likes
Seconded. I use SketchUp and AutoCAD daily, plus Revit, Rhino and others. They all have different icons, but I don’t remember ever getting confused just because of that—as long as you have a consistent and readable system almost any indicator will do (SketchUp doesn’t even use icons, just dots with different colors). Honestly, more detail-oriented QoL issues like four-way transform cursor obscuring the snap icons look more important to me than the specific shapes of the icons.
12 Likes
The problem is different.
In the software you listed all the icons are the same order, this is why you switch between them without problem, even between apps that doesnot have any icons.
The problem occurs when different apps will have the same icons set but displayed in different order.
Imagine if square icon will be used in Autocad for vertices, in Revit for edges and in 3dsmax for faces snapping - this will immediately make switching between those applicatiins hard and distractive.
This inconvenience is something to better be avoided.
1 Like
I would like some feedback for this list.
Actually, specifically the merging of “Transform pivot” and “Snap with”. I think that makes a lot of sense.
I don’t see how the two are ever the same, other than for moving, where there really is no discernible pivot.
I would you want to merge them?
Notice what I’ve written:
“Snap with” and “Transform pivot” would only be changed for movement, as movement only requires one pivot point, which is then moved (and the whole mesh follows). It is the only transform mode that doesn’t use the transform pivot option, but rather the “Snap with” as the origin. As is now, the transform pivot option is ignored and replaced with whatever the “Snap with” option is, but they are basically the same thing.
As is now, The “Snap with” option is only relevant to moving and doesn’t do anything for rotation and scale. Only the transform pivot is relevant to them.
Scale and Resize, for referenced transforming, requires two points. One is the origin point (Set by transform pivot), and the other is the “reference point” (Set with “B”). The “Snap with” option doesn’t do anything when rotating or scaling, as the reference point just snaps to whatever the “Snap to” option is.
So, to put it shortly: scaling and rotating would work exactly as they do right now, except that “Press B to set the basepoint” should be renamed to “Press B to set the Reference point”, (calling it a “base” is inaccurate. I’d say that The transform origin is what i’d call the base point for scale and rotate). And for movement, “Snap with” would be replaced with the transform pivot option.
2 Likes
Hi guys, I really like even just the basic “B-reference point” thing that is already awesome.
What would be even better is a hotkey (since we are touching hotkeys), during the transform operation to switch pivot point: from current to cursor and viceversa (or even cycle them all).
Also a way to set the snap target (vertices, edges, faces, etc…) during transform would be welcome.
What do you think?
7 Likes
Any news on face center snapping?
1 Like
The new basepoint snapping in Blender is great. But now I am missing an “apparent edge intersection”.
Here is my example. I have three hexagon wires, and I am trying to align the three. The two of them align, easily, but the third needs to snap at the edge intersection between the two
6 Likes
I think 3D view could use a new tool - Snap Tool.
When you’d enter this tool, just hovering over the 3D view without any key held would be picking the base point, and then you could press down and LMB click-drag to move the object/geometry from the base point and release the LMB over the target point.
It could be then even more useful if this tool could be hotkeyed to active on button press and deactivate on button release.
So if I want to snap a corner vertex of a cube to corner of another cube, I could:
- Hold down a key and move the cursor over the start point
- Click and hold the LMB to start dragging from the base point under the cursor
- Release LMB at the target to finish the snapping
- Release the key to exit the snap tool
3 Likes
“apparent edge intersection”
This is powerful CAD-like snap, but in Blender this will force massive calculations supporting which it was not originally designed for, so it is hard to realize properly or fast enough (at least we faced certain problems when tried to prototype it, so we used solved it a bit differently - in explicit way)
I think 3D view could use a new tool - Snap Tool.
Such an approch will have heavy limitations.
In tool realization it will have to be released as tool duplication for grab rotate and scale and duplication and extrude and all the other tools that support basepoint snapping.
It is supposed to be solved as “autobase snapping” checkbox which starts preliminaly searching of a basepoint before envoking any operation, and proceeding the envoked operation with searching target.
This way there will be known limitation like no heavy alternation support (between restricted and unrestricted actions), which assumes lots of switching of this checkbox the same way it happens in the other software. It will be also more likely gizmo-incompatible, since mouse position will be utilized for searching basepoint instead of aiming gizmo (gizmo utilizing concepts usually contradicts precise modeling workflows in general, because precise modeling workflowd assumes lots of different simultaneous restrictions per action). However, now it is technically possible to achieve.
I think at the next step could be nice to have snapping to 3dcursor as to a vertex (with optional taking into account its normal), to solve self-snapping translations.
Isn’t it just edge/edge essentially? At least that’s what i am thinking of. No need to run face/face, edge/face etc. With edge/edge, it’s about two edges that may have an intersecting point. Pretty similar to what the tiny CAD tools addon does, with a V2x | Vertex at intersection.
I think what you may be alluding to here is that pressing G and then B everytime is a bit long? If that’s the case I would agree and I wish there is a way in the preferences to always transform with a base point. That can be similar to that ALT toggle for navigation while in a transform command that landed in 4.0
1 Like
Tinicad and our enhaced versions (like project edges to faces and other similar tools like here at 4:25 ) works with predefined selection - so you have to calculate a very limited input which is simple to computer.
In snapping case you have to calculate all the intersections of everything that is visible on the screen in order to chose the closest to the mouse.
Some time ago we wrote a tool that founds intersecting edges in mesh, including apparent (not coplanar) which is useful, for example, for fixing issues after inset operation of a complex-shaped ngons, like coastline, and the speed of a such kind of a calculations was quite dependent from the selected elements amount.
For sure I hope that apparent intersections snapping could have a stable realtime compatible realization, but we faced certain problems when tried to prototype it, so reaching a proper solution could be challenging.
IDK, if this fits here but, is there a way to get “Local/Global” coordinate transform switch option in “Object” mode “Transform menu” (just like it’s in “Edit” mode)? I find lack of it quite hindering for precise scene building/‘set dressing’.
This is a development discussion thread for feedback on snapping features.
For general support and Q&A try a place like https://blender.stackexchange.com/ or Blender Artists Forum
Local coordinates in Object Mode would always be [0,0,0], what would you expect to see there?
They expect to see world space transforms on a parented object.
Imho it is valid. World transforms can be accessed through world matrix in Python, but that’s a bit impractical. I personally never needed that but I don’t do archviz and I suppose this is where it becomes most handy
4 Likes
As noted by @Hadriscus. And IMHO too, is good, simple way to improve UX for snapping & precision modeling tasks (am also C4D user where this is sort of 'standard part of a toll-box, as ‘this small thing’ makes a huge difference, since it takes away specific parts of ‘uncertainty’ by giving user ‘deeper’ control and clarity).
BTW
Not only in archviz, but it also helps w/ practical work on set building for theatrical plays and movie sets (where props are ordered/composited hierarchically and relative (to each other).
If you want to make a case for this, it’s best to describe one or more usecases in detail, show how existing methods don’t cut it, etc. there is no guarantee that someone will take an interest in it, but it should start with this.
3 Likes