F2: Vertices not merging on face creation #68572
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#68572
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.86
Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash:
blender/blender@f6cb5f5449Worked: (optional)
Short description of error
Even though auto merge is active, vertices laying directly on top of each other will not merge after create quad from vertex operation. auto grab is switched off in F2 settings. Increasing auto merge to higher thresholds (0.1) does not resolve issue and vertices won't merge when a quad is created from a single vertex selection. Does not occur with quad created from edge selection or more than one vertex selected.
Exact steps for others to reproduce the error
Turn off auto grab in F2 addon and leave other settings default.
Set auto merge to 0.001 or higher.
delete front face on default cube, grab any single vertex around the gap and fill it with f key.
The selected vertex (the furthest from the original selection) will not have merged with the one it now lays on top of.
Added subscriber: @WickedInsignia
Added subscriber: @BrendonMurphy
hi, confirming this.
Well, if F2 with no autograb creates matching vertices, that means, it is filling regular quad mesh grid.
For that purposes is used F2 from edge, not from vertex.
This is the way F2 solves grids by design.
Example GIF:
In cases, if grid is not regular, and also dense (for example, in baroque modeling) automerge can merge wrong casual vertices, that brings mesh to mess, that's hard to clean up.
That's why automerge support is not uncluded.
I can confirm this behavior was built into F2 from 2.79b, my bad.
The issue is AutoMerge not recognizing the vertices are within the merging threshold. If I wanted them to always merge, I don't have that option. I need to drag it and snap to the vertex it lays on top of.
This apparently still existed in 2.79b too, but seems like a bug behavior to me, since AutoMerge isn't acting in the way one would expect.
It seems like a useless feature for the vertices not to merge when AutoGrab is off. If we needed to move the vertex after face creation you could simply rip it.
This "feature" gets in the way of rapidly filling multi-face segments with a single vertex selection and spamming F.
We need a screenshot with such case.
Here is a simple example of annoying mess that automerge brings to mesh with F2.
Here's a use case of filling in faces with a corner selection, which would be possible with a couple of F taps if this wasn't an issue.
Considering how F2 treats edges and allow you to spam F to fill multiple segments, the same is expected here.
Yes, you could do this with an edge selection, but the point is that Automerge isn't acting as it should in this case.
Across the software, vertices on top of each other will merge with Automerge on, except for this one feature in F2.
The example you've shown would never result in a desired manner with F2. It's an annoying mess even without the vertex merging, and at the absolute least in that case automerge is doing what it should.
That is an example where an edge selection should be used.
This seems to be a case of choosing the lesser evil.
F2 was tested for a very large base of models on all possible occasions.
It's workflow methods allows to solve such situations in almost the same time.
It was designed for a way more complex work , It was never supposed to be the best regular grid filler, even if it already makes it better, than any other tool in Blender.
Sorry.
I'm not saying that's what F2 is. I use Blender for professional work as well, you don't need to go shooting your highly polished work at me like I don't know the benefit of F2 in complex work.
I was alarmed that AutoMerge was not working here, that is all. It works predictably across the rest of the software. To me, that's a bug, not a workflow.
Additionally, I don't see any benefits of the vertex not merging when the AutoGrab option is available for those who want to edit afterwards.
In the situation you've attached, I don't see how auto-merging the last vertex if it's exactly on top of another would slow work down.
It doesnot speed up much, it doesnot slowdown much, it, basically, allows to use one point selection instead of two on simple grids, and bring ability to mess on complex grids.
Well, that's just doesnot worth to obtain such an ability)
F2 already provides everything for such tasks to be completed.
So now that we've established it does nothing to speed-up or slow-down work, we may now focus on why it's a problem:
AutoMerge inconsistent behavior.
In every other case, AutoMerge will merge two vertices on top of each other. This is what the tool is expected to do.
When a tool does something that is not expected, it is a bug.
I don't care about pros who have been using F2 for years and accepted this behavior. I care about new people coming to the software who are confused as to why AutoMerge is not merging vertices in this case. There is no reason given in the software why this shouldn't happen, and now we know there is also no productive reason why this shouldn't happen.
So, if it does not affect work time but causes confusion, why not fix the bug that I reported from the very beginning??
Well, the problem that there is no inconsistent behaviour, and no bug.
If F2 doesnot include automerge support by design, just like any other addon, that creates geometry.
If it will contain automerge for at least some mode, and other not - that can be claimed as a bug or inconsitency, and will be claimed just by the right the next person.
So, hello again all that accidental mesh mess and unnecessary doublechecks of current mode, that we've got during multiple testing such ability, especially if to take in account how deep in interface it is now.
So.
Automerge for F2 is claimed as unnecessary, dangerous and harmful for workflow during multiple tests, so it is officially not supported by development team and maintainer.
Thus, we also take care of beginners who are immediately accustomed to the right solution and will not suffer when their level rises enough to make complex things.
Automerge support for F2 addon is cancelled.
Paul, F2 at the very least treats merges differently at the quad from vertex level. The expected response from a user is that vertex-based fills will merge just like edge-based fills.
Being accustomed to that is not learning the software. It is becoming accustomed to an inconsistent behavior, which you still haven't managed to explain the professional benefits of. I've explained why it is not of benefit, and you agreed that it did not increase or decrease working time. Therefore, the benefit is that changing it would make it more intuitive, and would not hurt existing users in a meaningful way.
Are you just allergic to doing fixes? I don't get it. This is a bug. I've explained why it's a bug, and you are pushing against it because you don't want what is ultimately an unintuitive behavior to change because you've become accustomed to it.
At this point I give up.
This was a confirmed bug. An obvious, clear-as-day inconsistency with no benefit but because "experienced users" don't want things to change it will stay in and frustrate new users.
I've explained everything I can, and been met with stops for no real reason other than a fear of changing something.
I won't be rushing to report any more bugs in the future.
@BrendonMurphy It's up to you what happens here.
hi, lowered priority,
There is an issue here possibly a bug or possibly just the way the addon works.
My test was a simple cube, delete 1 face, select 1 vert, use f2 addon to fill.
The last vert created is not connected to the cube. This effectively creating a double vert at same position.
This is with autograb either on or off, so nothing really to do with auto grab.
This is unexpected behavior as expected behavior in this case would be for the last vert to be joined.
I think what's possibly needed here would be an auto merge?
Using an edge with F2 addon to create the face works as expected, also traditional method of select non manifold then pressing F with F2 enabled also works as expected.
I'll run some more tests before looking at closing this task.
Thank you. This is exactly what I've been trying to get across. Inconsistent behavior from Auto-Merge on "Quad from Vertex" operation.
I think Paul was trying to explain that it's by design but couldn't come up with a use case in which Auto-Merge being blocked by the addon would actually result in a desired outcome.
The problem that's just cube.
Automerge doesnot makes any kind of troubles at scale of such primitives, because, actually, nothing can cause problems at this scale.
Well, of course, we performed a series of tests, because it seems obvious and handy at first look, and figured out, that it causes sufficient problems at serious level of work, F2 was designed for:
There are more complex examples, but they can't be shown because of NDA.
As it was told, F2 was tested for almost every possible issue, and it's testing still goes on just daily.
Today we are guaranteed, that F2 will not mess during making such complex objects in any way, no matter what options and where are turned on, and that just saves our files and lifes.
@1D_Inc Where would Auto-Merge cause an issue on the creation of those examples? Saying that it would cause an issue on "complex models" without explaining why doesn't help.
I came across this bug while working on a complex model and found it inconvenient.
I would think if someone doesn't want their vertices to Auto-Merge, they would turn Auto-Merge off.
F2 already merges vertices when a face is made from an edge-based selection, even with Auto-Merge off, so I don't see what the problem is. Auto-Grab also prevents the merge.
"We ran a variety of tests" Is the only reason I've heard so far for why this bug exists.
A better example - combining regular mesh with complex
F2 with autograb in that cases is used with cancelling autograb, and in that case created regular vertex should not be automerged with anything.
It is impossible to split "no autograb merge" and "cancelled autograb merge", if automerge will appear, it will influence both modes.
Mathematically or logically.
Aaaah okay. I wasn't aware that you couldn't have AutoGrab on and cancel without it AutoMerging.
I think that logically you could create a state in which cancelling AutoGrab would not AutoMerge...and even if it did, you could rip the vertex.
However the example was adequate and I'm happy to accept the quirky behavior.
Hopefully anyone with the same issue as me can read through this and come to the same conclusion.
Apologies for the frustration and interrogation from my end. Thanks for taking the time out to explain that!
At scale of massive production we cannot afford strategy like "be more accurate and doublecheck what options are enabled".
It is also hard to check if model has accidentally got wrong automerging issue at that scale, as they are made by different people.
So we prefer just exclude the possibility of the appearance of such problems at all.
Sorry.
Changed status from 'Open' to: 'Resolved'
closing as resolved. thanks for time and explanation @1D_Inc
Yeah I totally get that, no need to apologize.
Now that I know it's a necessary sacrifice I'm happy to accept it :)
Thanks a lot Paul, I think my own inexperience and frustration with the "bug" was getting in the way.
Sorry to have stretched this out, but it was a good learning experience and any future bug reports I make will be more efficient as a result.
Thanks!
// Meanwhile, good news for automerge users!
Blender development still tries to clone F2 from 2014 in Poly Biuld tool, so they recently has come to idea to build quad from vertex, and already made an automerge)
https://twitter.com/pablodp606/status/1166359374069194755
You can influence this development with proposals while it is in process, for example, to ask Pablo to make "quad from vertex" not as long, but instant as F2 with autograb does.
It's a real way for you to get F2-like behaviour with automerge support in Blender by default, keeping F2 addon without automerge for complex cases, described in that topic.
Sweet! Thank you for the update Paul :)
You're welcome)