UV Select Overlap incorrectly detects some faces as overlaps #103707

New Issue

Memm · 2023-01-07T03:21:13+01:00

Memm commented

2023-01-07 03:21:13 +01:00

System Information
Operating system: Windows-10
Graphics card: NVIDIA GeForce GTX 960

Blender Version
Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a9
Worked:

Short description of error
Select Overlap operator gives incorrect results.

Exact steps for others to reproduce the error
Download example .blend

incorrect overlap detection.blend (for Blender 3.5)
incorrect overlap detection.blend

UV editor > Select > Select Overlap

2 faces will be selected which are not overlapping (it's a single island, there are no UV overlaps here).

**System Information** Operating system: Windows-10 Graphics card: NVIDIA GeForce GTX 960 **Blender Version** Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: `b292cfe5a9` Worked: **Short description of error** Select Overlap operator gives incorrect results. **Exact steps for others to reproduce the error** Download example .blend - [incorrect overlap detection.blend](https://archive.blender.org/developer/F14143772/incorrect_overlap_detection.blend) (for Blender 3.5) - [incorrect overlap detection.blend](https://archive.blender.org/developer/F14129956/incorrect_overlap_detection.blend) UV editor > Select > Select Overlap 2 faces will be selected which are not overlapping (it's a single island, there are no UV overlaps here).

Memm commented

2023-01-07 03:21:13 +01:00

Added subscriber: @Memm

Pratik Borhade commented

2023-01-09 06:19:16 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Pratik Borhade commented

2023-01-09 06:19:16 +01:00

Added subscriber: @PratikPB2123

Philipp Oeser commented

2023-01-09 10:54:31 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2023-01-09 10:54:31 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Philipp Oeser closed this issue

2023-01-09 10:54:31 +01:00

Philipp Oeser self-assigned this 2023-01-09 10:54:31 +01:00

Philipp Oeser commented

2023-01-09 10:54:32 +01:00

0796210c8d seems to have fixed this.
So this is now resolved in 3.5 master, I`ll check with developers if that commit is good for LTS backporting.

Will close though.

0796210c8d seems to have fixed this. So this is now resolved in 3.5 master, I`ll check with developers if that commit is good for LTS backporting. Will close though.

Brecht Van Lommel commented

2023-01-09 10:59:54 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2023-01-09 10:59:54 +01:00

That's suspicious, I would not expect it to have been fixed by this. This may indicate a bug in either the new commit, or a remaining bug in the UV overlap detection code.

Brecht Van Lommel commented

2023-01-09 11:01:30 +01:00

Changed status from 'Resolved' to: 'Confirmed'

Brecht Van Lommel reopened this issue

2023-01-09 11:01:30 +01:00

Brecht Van Lommel commented

2023-01-09 11:01:47 +01:00

I think this needs to be checked more carefully to ensure it's really fixed.

Alexander Gavrilov commented

2023-01-09 11:07:52 +01:00

Added subscriber: @angavrilov

Alexander Gavrilov commented

2023-01-09 11:07:52 +01:00

In #103707#1471390, @brecht wrote:
That's suspicious, I would not expect it to have been fixed by this. This may indicate a bug in either the new commit, or a remaining bug in the UV overlap detection code.

This works for cloth, so I'd look at the calling code. Cloth itself needed some minor changes to cope with slightly different output. At first glance the UV code seemed like it shouldn't care, so I changed the call there to use the new function, but I might have been wrong there.

The new code has the following differences in its output:

No duplicate (a,b) + (b,a) pairs, and which of the two is output is unpredictable.
Different ordering of the output list.

> In #103707#1471390, @brecht wrote: > That's suspicious, I would not expect it to have been fixed by this. This may indicate a bug in either the new commit, or a remaining bug in the UV overlap detection code. This works for cloth, so I'd look at the calling code. Cloth itself needed some minor changes to cope with slightly different output. At first glance the UV code seemed like it shouldn't care, so I changed the call there to use the new function, but I might have been wrong there. The new code has the following differences in its output: * No duplicate (a,b) + (b,a) pairs, and which of the two is output is unpredictable. * Different ordering of the output list.

Philipp Oeser removed their assignment 2023-01-09 15:15:32 +01:00

Pratik Borhade commented

2023-01-11 05:18:09 +01:00

Hi, can we can close this report unless we've any particular file/case which still fails overlap operation.
But Issue is still there in 3.3 and 2.93 so we can open a separate report (or modify this) which defines core problem in overlap detection code

Hi, can we can close this report unless we've any particular file/case which still fails overlap operation. But Issue is still there in 3.3 and 2.93 so we can open a separate report (or modify this) which defines core problem in overlap detection code

Memm commented

2023-01-11 06:59:29 +01:00

I just compiled the latest master from github "commit 86464cfcef2c982ae532b47553207be13f3d3815" Blender 3.5 Alpha (make developer debug) and I get the exact same bug, same .blend file as my original post.

Although there's a small numerical error so the .blend file might not get the bug unless you slide the vertex in the middle of the triangle a little more counterclockwise. It works if it's closer to the previous loop vert and breaks when it's closer to the next loop.

Works

Breaks

Another thing is you need to do a UV unwrap before you do Select Overlap, otherwise the bug doesn't always come up???

So from what I can tell the only change from 3.3.1 and 3.5 Alpha is it became a little less consistent to reproduce, but the bug is still there.

I just compiled the latest master from github "commit 86464cfcef2c982ae532b47553207be13f3d3815" Blender 3.5 Alpha (make developer debug) and I get the exact same bug, same .blend file as my original post. Although there's a small numerical error so the .blend file might not get the bug unless you slide the vertex in the middle of the triangle a little more counterclockwise. It works if it's closer to the previous loop vert and breaks when it's closer to the next loop. Works ![image.png](https://archive.blender.org/developer/F14139542/image.png) Breaks ![image.png](https://archive.blender.org/developer/F14139544/image.png) Another thing is you need to do a UV unwrap before you do Select Overlap, otherwise the bug doesn't always come up??? So from what I can tell the only change from 3.3.1 and 3.5 Alpha is it became a little less consistent to reproduce, but the bug is still there.

Chris Blackbourn commented

2023-01-12 03:18:17 +01:00

Added subscriber: @Chris_Blackbourn

Chris Blackbourn commented

2023-01-12 03:18:17 +01:00

Hi Memm,

Sorry, I just want to clarify, as occasionally "make developer debug" and "make debug" can give slightly different results.

Is the current file ("incorrect overlap detection.blend") showing the bug with "make developer debug" on your machine? Or do you need to modify the file to show the bug?

If possible, can you upload a .blend file which shows the bug with no changes required?

Hi Memm, Sorry, I just want to clarify, as occasionally `"make developer debug"` and `"make debug"` can give slightly different results. Is the current file ("incorrect overlap detection.blend") showing the bug with "make developer debug" on your machine? Or do you need to modify the file to show the bug? If possible, can you upload a .blend file which shows the bug with no changes required?

Jesse Yurkovich commented

2023-01-12 03:53:40 +01:00

Added subscriber: @deadpin

Jesse Yurkovich commented

2023-01-12 03:53:40 +01:00

I implemented the current support for UV overlap and can reproduce the original issue from "incorrect overlap detection.blend" on 3.4.1. This is most likely because the vertex is colinear with that edge there and the overlap test is considering it intersecting (precision etc.). Indeed, just nudging the circled vert slightly is enough to prevent the issue:

That this is a "single island" doesn't really factor in as overlaps can still occur for such topologies. Generally interior verts can't be ignored for overlaps so we can't just consider the borders either. I can see if adjusting the intersection epsilons/bias improves things but those types of changes often make other scenarios worse.

I implemented the current support for UV overlap and can reproduce the original issue from "incorrect overlap detection.blend" on 3.4.1. This is most likely because the vertex is colinear with that edge there and the overlap test is considering it intersecting (precision etc.). Indeed, just nudging the circled vert slightly is enough to prevent the issue: ![image.png](https://archive.blender.org/developer/F14143739/image.png) That this is a "single island" doesn't really factor in as overlaps can still occur for such topologies. Generally interior verts can't be ignored for overlaps so we can't just consider the borders either. I can see if adjusting the intersection epsilons/bias improves things but those types of changes often make other scenarios worse.

Memm commented

2023-01-12 04:26:02 +01:00

@Chris_Blackbourn

Here's a slightly modified .blend that breaks in 3.5.
incorrect overlap detection.blend

@deadpin

These sorts of "triangles" are created often by retopology tools like Instant Meshes or QuadriFlow. Maybe somehow test for them specifically as an edge case? Or more specifically don't consider a point as intersecting if it's on an edge if that's what its currently doing. Just some thoughts.

@Chris_Blackbourn Here's a slightly modified .blend that breaks in 3.5. [incorrect overlap detection.blend](https://archive.blender.org/developer/F14143772/incorrect_overlap_detection.blend) @deadpin These sorts of "triangles" are created often by retopology tools like Instant Meshes or QuadriFlow. Maybe somehow test for them specifically as an edge case? Or more specifically don't consider a point as intersecting if it's on an edge if that's what its currently doing. Just some thoughts.

Chris Blackbourn commented

2023-01-12 06:29:50 +01:00

Confirmed in debugger.

Chris Blackbourn commented

2023-01-12 06:48:47 +01:00

Issue appears to be the quad in the middle not being triangulated correctly

If the central quad is triangulated, everything seems to work fine.

Issue appears to be the quad in the middle not being triangulated correctly ![image.png](https://archive.blender.org/developer/F14144276/image.png) If the central quad is triangulated, everything seems to work fine.

Chris Blackbourn commented

2023-01-12 07:10:26 +01:00

Update: In the file source/blender/editors/uvedit/uvedit_select.c, line 4396, replacing BLI_polyfill_calc with BLI_polyfill_beautify appears to fix the problem, at least for this particular file.

@deadpin , do you want to take it from here or should I keep on going?

Update: In the file `source/blender/editors/uvedit/uvedit_select.c`, line 4396, replacing `BLI_polyfill_calc` with `BLI_polyfill_beautify` appears to fix the problem, at least for this particular file. @deadpin , do you want to take it from here or should I keep on going?

blender-admin commented

2023-01-19 06:25:55 +01:00

This issue was referenced by 163d4aa094

This issue was referenced by 163d4aa094d1407c474bbef6895a793425f8c00b

Jesse Yurkovich commented

2023-01-19 07:07:43 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jesse Yurkovich closed this issue

2023-01-19 07:07:43 +01:00

Jesse Yurkovich self-assigned this 2023-01-19 07:07:43 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UV Select Overlap incorrectly detects some faces as overlaps #103707