Could not create merged face blender ошибка

$begingroup$

$endgroup$

3

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.

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.
@Brendon Murphy (meta-androcto) 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.

I think what’s possibly needed here would be an auto merge?
I’ll run some more tests before looking at closing this task.

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.

@Paul Kotelevets (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.

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.

// 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.