Maniphest T54996

The bridge tool fails in a situation with multiple rows of faces facing each other
Confirmed, NormalTO DO
Actions

Assigned To
None
Authored By
Adam Friesen (ace_dragon)
May 8 2018, 2:45 AM
Tags
  • BF Blender
  • Modeling
  • Papercut
Subscribers
Adam Friesen (ace_dragon)
Campbell Barton (campbellbarton)
Characterhero (TheCharacterhero)
Chingiz Jumagulov (Krayzmond)
Eugene Du (APEC)
Francesco Sorrentino (zeirus)
Lukas Ziechmann (bl_cat)
2 More Subscribers
Tokens
"Love" token, awarded by APEC."Like" token, awarded by TheCharacterhero."Love" token, awarded by dulrich.

Description

System Information
Win10 Pro 64 bit; AMD Ryzen 2700X; Nvidia GTX 1060 6GB; 32 gigs RAM

Blender Version
Broken: hash d1be30f (buildbot build May 4).
Worked: never

Short description of error
In a situation where you have multiple rows of faces that face each other across empty space (with other areas where they face away from each other). The bridge tool (even with loop pairs checked) is unable to give priority to the direction the normals are facing. The result of this is that instead of getting nice bridges among the multiple rows of cubes, the tool produces faces that overlap and have zero area. As hinted, the loop pairs checkbox in this case does not do anything and the result is the same.

Exact steps for others to reproduce the error
Open the .blend, invoke the bridge operator (the result is the same whether or not "loop pairs" is selected.

blend

IffyBridge.blend559 KBDownload

IffyBridge.blend586 KBDownload
(updated blend)

An additional note; I submitted this issue years ago, but it was never fixed and I couldn't find my old report. If the bug is not going to be fixed, then just close this as a todo item or with a "won't fix" tag.

Related Objects

Mentioned Here
rB5dc1183580e9: Codesign: Possible fix for stamp appearing prior to archive
T54597: Bridge Edge tool causes unintended results with a specific .blend file

Event Timeline

Adam Friesen (ace_dragon) created this task.May 8 2018, 2:45 AM
Adam Friesen (ace_dragon) updated the task description.
Adam Friesen (ace_dragon) updated the task description.May 8 2018, 2:51 AM
Adam Friesen (ace_dragon) updated the task description.
Lukas Ziechmann (bl_cat) added a subscriber: Lukas Ziechmann (bl_cat).May 9 2018, 10:34 PM

Hi @Adam Friesen (ace_dragon),

I can reproduce this behavior using the operator in the Edge-Special menu. Although checking 'loop pairs'-option does yield a slightly different result than the other options, it can't really be considered the desired result.
If that is a feature you urgently need however, you can already use the add-on "loop-tools" that ships with blender. This produces the expected result.

Lukas Ziechmann (bl_cat) lowered the priority of this task from 90 to 50.May 9 2018, 10:37 PM
Philipp Oeser (lichtwerk) claimed this task.May 14 2018, 2:13 PM
Philipp Oeser (lichtwerk) added subscribers: Campbell Barton (campbellbarton), Philipp Oeser (lichtwerk).

T54597 is somewhat related, I will revisit this shortly and see if I can nail this.
Note as in T54597 the situation improves if individual components are moved/rotated just slightly out of the aligned setup [which of course is not a solution at all...]

Like I said, I'll give it a go, if that doesnt succeed, I'll have to ask @Campbell Barton (campbellbarton) to take over...

Campbell Barton (campbellbarton) updated the task description.Jan 31 2019, 8:34 AM
Campbell Barton (campbellbarton) added a comment.Jan 31 2019, 8:37 AM

I'm not sure about the blend file in this report, but found a case where loop-pairs fails in a more obvious way (where the pairs aren't calculated in a consistent way), posted updated blend.

Rigoletto Eikenberg (rigoletto) added a subscriber: Rigoletto Eikenberg (rigoletto).EditedAug 9 2019, 10:38 PM

I periodicaly got wrong results too, added screenshot and blend file. I guess its the same probllem.

bridge_edge_loop_bug.blend876 KBDownload

Philipp Oeser (lichtwerk) removed Philipp Oeser (lichtwerk) as the assignee of this task.Nov 12 2019, 4:21 PM
Adam Friesen (ace_dragon) added a comment.Nov 26 2019, 7:46 PM

The bridge tool in this situation is still broken in 2.82 alpha.

If there is no interest in fixing the bug, then one might as well close the report as "won't fix" :-/

Dalai Felinto (dfelinto) added a project: Tracker Curfew.Dec 23 2019, 4:36 PM
Sybren A. Stüvel (sybren) removed a project: Tracker Curfew.Feb 4 2020, 3:40 PM
Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Bug".
Sybren A. Stüvel (sybren) added a subscriber: Sybren A. Stüvel (sybren).
In T54996#818522, @Adam Friesen (ace_dragon) wrote:

If there is no interest in fixing the bug, then one might as well close the report as "won't fix" :-/

The fact that that didn't happen could tell you something ;-)

This is the result I get with 2.82 alpha @ 5dc1183580e932870064b44246e8fb750a8d806e with the original attached blend file.

I'm assuming the report is about the circled faces, but I'm not entirely sure. The report mentions zero area faces, and the ones I circled are merely overlapping.

Increasing the number of cuts does show that there is some twisting going on:

This does looks like a real bug to me, and not just a limitation of the current design.

Adam Friesen (ace_dragon) added a comment.EditedFeb 5 2020, 6:32 PM

The bug is that the cubes in the center shouldn't have faces overlapping them at all. There's supposed to be four different bridges that are made with no overlaps (when the selected mode is "loop pairs"). This is what I mean when I say the design does not take the normal direction into account when finding the nearest face(s) to pair with.

Meanwhile, the bridge operator that comes with the Looptools addon (which is bundled with Blender) tackles this case perfectly. There is no reason to not just copy what it does when the loop pairs mode is selected.

The correct result (from Looptools).

Campbell Barton (campbellbarton) moved this task from Backlog to Bugs on the Modeling board.Jun 17 2020, 5:18 AM
Daniel Ulrich (dulrich) awarded a token.Jul 11 2020, 9:03 AM
Characterhero (TheCharacterhero) added a subscriber: Characterhero (TheCharacterhero).Jul 11 2020, 10:03 AM

I will not add a countdown until the topic is open.
If this is relevant, then I described in more detail on the forum: https://devtalk.blender.org/t/blender-bridge-edit-loops/14347

Characterhero (TheCharacterhero) awarded a token.Jul 11 2020, 10:03 AM
Eugene Du (APEC) awarded a token.Jul 11 2020, 10:13 AM
Eugene Du (APEC) added a subscriber: Eugene Du (APEC).
Francesco Sorrentino (zeirus) added a subscriber: Francesco Sorrentino (zeirus).Jul 11 2020, 10:17 AM
Chingiz Jumagulov (Krayzmond) added a subscriber: Chingiz Jumagulov (Krayzmond).Jul 11 2020, 11:25 AM
Adam Friesen (ace_dragon) added a comment.Sep 1 2020, 4:11 AM

This is still a thing in 2.91 alpha.

Is there a reason why the face normals cannot be taken into account when bridging pairs, I would think the Bmesh system supports such a thing?

Campbell Barton (campbellbarton) changed the subtype of this task from "Bug" to "To Do".Sep 21 2020, 10:54 AM
Campbell Barton (campbellbarton) added a project: Papercut.

Marking this report a todo, papercut.

Currently the bridge tool only sees edge-loops, it isn't aware of surrounding geometry and how it would best be integrated into the bridge result.

While it can be supported, it's not a mistake in the implementation.

Campbell Barton (campbellbarton) moved this task from Bugs to Papercuts on the Modeling board.Sep 21 2020, 10:55 AM
Rigoletto Eikenberg (rigoletto) added a comment.Apr 27 2022, 8:24 PM

The results can be changed if i rotate one or more edges with "Rotate Edge CW / CCW" (changing index of the edges),
then the direction of the bridge changes sometimes.
But i cant find a pattern to get predicted results. It seem not to belong if the index are ordered CW /CCW.

It cant be random, so maybe if the edge index are considered the should be a solution for a switch to change the direction!?