I’m sure that you’re aware of the difference.
2 Likes
Whichever View 3D icons are finally chosen for the snapping behavior, the icons in this menu need to match those icons.
9 Likes
They don’t need to necessarily. Current icons are more intuitive in this menu, but they do not work on the mesh, and the “industry standard” icons are intuitive on the mesh, but not in this menu.
They do not match in other software either:
If you’re going to give the user a Circle, a Square, and a Triangle for telling them specific snap points, then the user needs to be shown (visually) what the Circle, Square, and Triangle mean in the menu.
I don’t know what RandomCAD does - or why their menu doesn’t match the view - but I do believe that the point of icons is to clearly communicate to a user what the tool is doing.
It was discussed prior to use icons that are somewhat related to the actual target; the decision has been made that the icons should be these arbitrary shapes that are familiar to people who don’t use Blender. It makes no sense to use CIRCLE for a vertex in the viewport, but “4 DOTS” as an icon in the SNAP MENU. The menu literally has the word VERTEX in it, so I don’t think we need to illustrate it with dots to lessen the confusion.
By the way, it’s ironic how people are all “Blender isn’t XYZ Competitor” when a suggestion they don’t like is made, but when it supports what they want - suddenly, Competitor is the Gold Standard. 
(Not directed at you, FreeMind. Just a thought that occurred to me.)
8 Likes
Those icons make no sense, I prefer the current ones. Circle for vertex, square for face and parallel lines for edges.
3 Likes
There already was similar icons problem.
I will try to answer the different questions in a single reply.
Menu icons to match Snap symbols
The plan is to indeed to try matching them. From the commit message:
Also note that later we should also try to change the icons shown in the snap menu to match the symbols that the artists see in the preview window.
Help with this would be welcome:
- Pull request with updated blender_icons.svg and tweaked viewport menu.
- Remember to include screenshots in the patch to show how they look in the menu.
- For the Face/Volume we only need to show the icon for the face
- Similar to how in 4.0 we only show the first icon of the repeated Help url entries.
- Similar to how in 4.0 we only show the first icon of the repeated Help url entries.
Tooltips
“(…) follow an actual standard (tooltips) and make Blender welcoming”
I would also like to see a patch for that. But I suspect we will end up with something too distracting (with the constant changing of the tooltip text).
Decision Process
It is disappointing to hear with little to no explanation that such a decision has been made after asking for feedback in this thread. Could you expand on your thought process and address the feedback that has been collected in this thread ?
Thanks for wording your questions so nicely by the way.
I’m happy to do so. The days preceeding bcon3 were more hectic than usual (too many final decisions), leaving communication a bit behind indeed.
I will tell a long story here, please indulge me:
-
June 30, 2019: Germano starts a development grant to work on snapping and transform tools.
-
July 5, 2019: Germano, Campbell and I meet together to define targets. As a followup I prepared a design for base snapping.
From 2019 to 2023 not much happened. I was working full-time for Blender but I could not prioritize this project. Every now and then I would poke the module team about the state of things, but there was a lot of under-the-hood work that had to be done before we could have more “fancy” snap tools. Besides, Germano was officially working as a bug-triager - that said he never stopped helping with modeling-related development, but was mostly done on the side.
January 2023, I got back from a holidays visiting my sister. She is (also) an architect and we had a good time with me showing her Geometry Nodes, while she showed me what she had been modeling in Blender. The lack of (base) snap in Blender pained me. So, inspired and energized, I decided to once again stir that pot.
Around January I went over the snap patch with Pablo Vazquez, and brought Julien Kaspar into the mix. I wanted to make sure (non-CAD) modellers were happy with the solution. At the same time I cleared out Germano triaging duties to free him for a final sprint. The lack of “transform during snap” was considered blocking. So I relied a lot on Julien to help testing while Germano iterated on the implementation.
-
Apr 20: I see the original snap icons patch by Erik and promptly show it to Germano. Around that time we got into Blender 3.6 LTS bcon2. I’m once again saddened to see that we missed another window.
-
Apr 21: After seeing some concerns there, I add my first comment to that thread - basically I’m happy with the patch, it adds new useful functionality, and it does so with a tried-and-proofed set of symbols.
-
May 1: I start to notice that the patch is risking getting stalled.
-
June 5: Base Snap is in Blender and covered on Blender Today (you can see my joy there).
Even though Base Snap was merged 
, there was still work to be done to polish its behaviour and get the Transform while Snap functionality in Blender.
Around that time I wanted to look at the snap symbols patch again. Germano wanted to try a different solution, and I believe that around then he decided to ask here for feedback. I didn’t follow the discussions here, and continued minding my own business.
Finally in August I was again uneasy with this going anywhere and bcon3 approaching. So I suggested Germano that we wrap this up once I was back. I expressed myself poorly, because he didn’t realize I still wanted to be involved.
Two weeks ago I was watching a video about new snapping tools in Blender. And this is how I learned about the new snap icons being committed. I did some digging and asked around to understand why this was decided how it was. I then lobbyed to revert that decision on the UI meeting preceeding bcon3.
So what is my decision process?
- Listen to everyone.
- Work closely with stakeholders.
- Respect the different roles.
I make a decision considering everything, but the decision role is not “a consensus”, or “democracy”. Even though in some cases polling a large number of users can help to guide a decision.
In this particular case I tried to use a principle called Falsification by Karl Popper (I found about it on Black Swan by Nassim Taleb). The idea is not to try to find evidence to support my original thesis (that CAD symbols could work), but to try to disprove it.
In other words, I knew that I could make arguments to support that solution, but could I try to find anything wrong with those icons? And this is indeed where those thread can really help. And although I could find arguments in favour of the other solution, there was little to discredit the CAD symbols.
On the other hand, I did find a few things which I consider bad about the “minimalistic icons”:
- We don’t do rotating icons in Blender - that could change one day, but shouldn’t be done lightly.
- That and the variation in size of the icons produces considerable noise when hovering an organic mesh like Suzanne.
I don’t expect many to notice this (or maybe to get annoyed by this). But for me this raises a flag regarding how this was being designed. We could of course iterate over the design further, but given that the original design was working fine, I didn’t see the point.
I’m also very wary of the thin line between feedback and design by committee, and this was getting too close to the latter.
With all that in mind I used another principle. This one from Stephen King, On Writing. Stephen uses early peer-feedback to find what may be unanimously bad. If something is clearly bad, he changes it. If his stakeholders (his wife in particular) is adamant about a point, he tackles it. However, whenever there is conflicting responses to his novels he just get to be the tie-breaker.
I’m no Stephen King, but I was playing the role of designer and commissioner for the related snap improvements. As such I don’t mind making a pure subjective call, and here we are.
All in all I hope this paints a better picture for this (not so) arbritary last minute change.
Further
For anyone wanting to hear more about the design process and how we handle feedback, I cover some of this on The challenge of design in open source projects talk I gave at Penpot Fest this year:
I plan to give a rehashed version of this at Blender Conference this year. So if anyone still has any questions let me know. I won’t have time to spend here iterating over the snap symbols. But I would love to expand the talk to address any questions.
16 Likes
Yes I completely agree. I think having this discrepancy is harmful, the “mesh element” icons need to be redesigned in accordance in time for release. I don’t agree with the design, but since a decision has been made, keeping Blender consistent with itself is the more important thing. (Not just in the snap menu, but the three element icons in the viewport header as well, when in edit mode).
1 Like
I completely respect Dalai’s lengthy response to all the above; honestly, that’s more explanation than I would have given.
Re: the icons - personally, I’ve zero skillset to submit a patch… wish I could help on this. I’ve read the instructions, of course, and I’ve compiled Blender a few times… but I still need to learn more about the inner-workings of source, pulls, submits, and all that. I’m hopeful that over the next few weeks/months I’ll be able to get competent with that, so in the future smaller things like this will be something I could assist with.
Thank you for taking time to do such a thorough write up, I did not expect such a long reply. Although I don’t agree with the decision I see where you are coming from, and I understand the complexities of making this kind of decisions in tight timeframes.
Hope you know that the animosity on this is coming from excitement to see this great feature make it it, at least on my part.
Kudos to @mano-wii for the hard work !
2 Likes
Clearly something is not right here.
Since users opinions doesn’t matter, then the “UI team” should at least vote.
That’s concerning.
1 Like
I’m not sure I want my name associated with this lobbying attempt. I may disagree with the chosen design, but I respect the decision and we’ll see where it leads us. It’s no big deal
3 Likes
Polygon is not trying to lobby anything. Dalai has been going back and forth between saying the feedback in the original thread was “non-conclusive”, to saying he listens to feedback, and then back to saying the feedback was conflicting and non-unanimous. This is deceptive, and there is nothing wrong with calling that out.
And for reference, if anyone bothers to check back the original feedback, out of 10 responses only 1 was clearly preferential to one set of icons, and 1D also seems to prefer that set. Redwax didn’t really show a clear preference so Ill add Redwax as neutral. That is 70% pro one set of icons and 10% neutral. Calling that not conclusive does feel wrong and that is what Polygons is getting at.
Hadriscus, I think everyone commenting here have had blender changes they really liked but the majority disagreed with them, or a dev superceded their decision, so nobody here is a stranger to respecting the devs decision. The concern is not about the icons, it is about how the decision was made. I can’t say I’m surprised Polygon feels something isn’t right, considering the conclusiveness of the feedback, and gathered whatever quotes proved that conclusiveness. Compared to any other comment on devtalk I don’t see how it counts as lobbying. Not like Polygon asked anyone quoted to say something if they agree with them.
Again, nothing wrong with simply calling something out. Then again Steven Spielberg on Directing may have different opinions on that.
4 Likes
If I had to choose, I’d go with the minimalistic icons too… It fits better in a general DCC software like Blender, imo…
2 Likes
I’ve noticed that many people genuinely appreciate the so-called “minimalist” style that I’ve suggested (Kindly note that my expertise lies in development, not design).
To provide a bit more context, the current polygon-based style was the result of a prior decision.
However, due to certain reservations about this style and a gap in communication with Dalai, I initiated a poll to evaluate the viability of the “minimalist” style.
I understand this initiative may have resulted in some discord, for which I apologize.
However, the alternative minimalist style will not be disregarded.
Perhaps it’s not the solution some were hoping for, but I’m proposing to incorporate this alternative style as a theme option.
See here for more details:
13 Likes
Having it as an alternative would definitely be a welcome addition.
I would not make it a theme option though, this seems more like a user preference that should belong in Edit > Preferences > Viewport.
Snap icons seem like something a user would probably consciously set up once for his workflow, rather than a stylistic decision at the whim of a theme author, that would then change arbitrarily depending on current theme.
I understand there is reluctance in adding more options to the already crowded user preferences, but I hope this is considered a worthy additon. Alternatively make it independent per-viewport, with a selector directly inside de very snap popover.
6 Likes
I don’t imagine many people are going to want to use both options, in the same session, in different workspace tabs.
10 Likes
Honestly, if you look at the sample count for responses, if you say it’s a small dozen, what percentage is that of the potential users? Less than 1%? The developers should have the room to make decisions they see fit in this sense, because even if they were to take community feedback as is, there may well be a large backlash later, because a much larger userbase disagrees with the decision that was taken.
What @dfelinto said is he takes the concerns of those against a decision into account, that does not mean you have to agree and let the community decision be the final decision. I appreciate the detailed account of the decision making process in this case.
And as always, in FOSS, undecided means add an option to the preferences/ make it theme able. Though, most likely, those who haven’t seen this thread won’t even know there is another option and likely won’t bother if the default works fine, which it should.
3 Likes
I mean, I was just following Stephen King on Writing. Those dozen users represent an archetype of a blender user, including some of them who use cad software, so other users in that archetype are more likely to feel the same way. I wouldn’t be so quick to disregard them like that, especially considering they wrote justifications on what they preferred.
Golly if only there was a way to tackle the small sample size, you know? Like, somehow make it not be that small percentage. If only there was a way. Maybe Taylor Swift on Songwriting has something to say about samples that can save us from this catastrophe.
Just a few new random thoughts I had today:
-
When “snap with” is set to “Active”, select multiple objects, and deselect the active object. When moving and snapping these objects, they act as if “snap with” is set to “median”. Maybe they should still respect the origin of the non-selected active object.
-
When “Snap with” is set to “Active”, moving and placing the 3D cursor gives nonsensical and unpredictable results. Shouldn’t the result be based on the active selection? Or Maybe the 3D cursor should completely ignore the “Snap with” option…?
-
“Transform Pivot point” and “Snap with” are pretty much the same thing, except that one of them is only used when snapping… Maybe they can be merged…
Every single option, except for “closest” is (or can be) shared between the two.
To do this, add “Transform pivot” as a “Snap with” option, and remove “Center”, “Median” and “Active”.
So “Snap with” would only have two options: “Transform pivot” (Default) and “Closest vertex”.
Would be nice if we could experiment with this and see how such a change would affect intuitiveness and workflow.
NOTE: This turns the “B for custom snapping point” thing obsolete for movement, because the 3D cursor transform pivot would take that role. This seems more of a “Blender way” of doing things.
For Rotation and Scale, this “B” point set is still required, but should be renamed to “Set Rotation/Scale Reference point” or just “Reference point” for short. -
Renaming, so it’s a bit more informative:
Closest > Closest vertex (Because “Closest what?”)
Snap with > “Snap pivot” or “Snap origin” or “Snap transform pivot” or just “Snap” or “Pivot” (Because I don’t think the word “With” makes grammatical sense here). -
More “Snap to” options:
Face perpendicular
Face Parallel
Face Median/Center
Object origin
3D Cursor.
Edge parallel -
There is still a lack of tools to easily align one mesh to another. “Align Rotation to target” helps only if the mesh is aligned to the object origin axes. And it does not work at all in Edit mode unless the user only has one element (Edge, or face) selected
-
There are no icons for “Face project” or “Face nearest” when snapping.
-
Snapping to vertexes is a lot more common than snapping to increments. Probably should be the default in the blender startup file.