The bridge tool fails in a situation with multiple rows of faces facing each other #54996

New Issue

Adam Friesen · 2018-05-08T02:45:04+02:00

Adam Friesen commented

2018-05-08 02:45:04 +02:00

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 withloop 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, theloop 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.blend

IffyBridge.blend (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.

**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.blend](https://archive.blender.org/developer/F3300781/IffyBridge.blend) [IffyBridge.blend](https://archive.blender.org/developer/F6462204/IffyBridge.blend) (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.

Adam Friesen commented

2018-05-08 02:45:04 +02:00

Added subscriber: @Ace_Dragon

Lukas Ziechmann commented

2018-05-09 22:34:38 +02:00

Added subscriber: @LukasZiechmann

Lukas Ziechmann commented

2018-05-09 22:34:38 +02:00

Hi @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.

Hi @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.

Philipp Oeser commented

2018-05-14 14:13:39 +02:00

Added subscribers: @ideasman42, @lichtwerk

Philipp Oeser self-assigned this 2018-05-14 14:13:39 +02:00

Philipp Oeser commented

2018-05-14 14:13:39 +02:00

#54597 is somewhat related, I will revisit this shortly and see if I can nail this.
Note as in #54597 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 @ideasman42 to take over...

#54597 is somewhat related, I will revisit this shortly and see if I can nail this. Note as in #54597 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 @ideasman42 to take over...

Campbell Barton commented

2019-01-31 08:37:28 +01:00

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.

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 commented

2019-08-09 22:38:13 +02:00

Added subscriber: @Rigoletto

Rigoletto Eikenberg commented

2019-08-09 22:38:13 +02:00

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

I periodicaly got wrong results too, added screenshot and blend file. I guess its the same probllem.[bridge_edge_loop_bug.blend](https://archive.blender.org/developer/F7656539/bridge_edge_loop_bug.blend) ![bridge_edge_loop_bug.png](https://archive.blender.org/developer/F7656538/bridge_edge_loop_bug.png)

Philipp Oeser removed their assignment 2019-11-12 16:21:30 +01:00

Adam Friesen commented

2019-11-26 19:46:26 +01:00

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" :-/

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*" :-/

Sybren A. Stüvel commented

2020-02-04 15:40:12 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-02-04 15:40:12 +01:00

In #54996#818522, @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 @ 5dc1183580 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.

> In #54996#818522, @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. ![image.png](https://archive.blender.org/developer/F8320844/image.png) 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: ![image.png](https://archive.blender.org/developer/F8320872/image.png) This does looks like a real bug to me, and not just a limitation of the current design.

Adam Friesen commented

2020-02-05 18:32:33 +01:00

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

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). ![Bmesh_correctBridge.jpg](https://archive.blender.org/developer/F8323708/Bmesh_correctBridge.jpg)

Characterhero commented

2020-07-11 10:03:13 +02:00

Added subscriber: @TheCharacterhero-4

Characterhero commented

2020-07-11 10:03:13 +02:00

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

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

Eugene Du commented

2020-07-11 10:13:51 +02:00

Added subscriber: @APEC

Francesco Sorrentino commented

2020-07-11 10:17:42 +02:00

Added subscriber: @Zeirus

Chingiz Jumagulov commented

2020-07-11 11:25:10 +02:00

Added subscriber: @MeshVoid

Adam Friesen commented

2020-09-01 04:11:18 +02:00

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?

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 commented

2020-09-21 10:54:53 +02:00

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.

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.

Rigoletto Eikenberg commented

2022-04-27 20:24:43 +02:00

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!?

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!?

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

The bridge tool fails in a situation with multiple rows of faces facing each other #54996