Page MenuHome

Applying Subdivision Modifier De-merges UV's
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.14736 Core Profile Context 20.8.3 27.20.12027.1001

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-22 12:02, hash: rB8d1123ba220b
Worked: working in 2.90

Caused by rBb88dd3b8e7b9: UV: remove selection threshold for nearby coordinates

Short description of error
When applying a subdivision modifier, certain UV's points disconnect from their neighbors. This does not seem to occur with the F3 menu subdivide operation.

Exact steps for others to reproduce the error

  • Open default blender scene.
  • Subdivide cube - 1 level and apply it. Do this step 4x
  • In the UV editor use "Alt select" to select face loops at random.
  • Alt click around until a face loop is not fully completed, this will reveal unmerged vertices.
  • Check area that did not complete by moving faces, vertices, edges etc to confirm unmerged UV's.

This does not seem to be an issue with the newly added rB9a52b30cc0de in my eyes, rather an issue with subdividing.

Event Timeline

One way to find out if a face is disconnected is to move it:

But I'm not sure if this is really a bug.
I'm not sure what the UV editor considers "connected".
But we cannot guarantee 100% accuracy in all operations.

(CC @Campbell Barton (campbellbarton))

Perhaps it's not a bug, I'm not sure, however I do know that it is certainly undesirable behavior. I think that if UV's were merged before any operation, then they should stay that way, unless specifically told to do otherwise, like in a cut operation etc. Perhaps it's not just related to this issue, but it's an underlying quirk with the UV workflow currently? Thanks for your time.

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Sep 29 2020, 8:56 PM

I can confirm this working in 2.90, broken somewhere between rB396d39c6b904 and rB0721fbb6e1e2

This is caused by rBb88dd3b8e7b. @Campbell Barton (campbellbarton) so I would say there is no bug here? subsurf probably generates small differences in UV coordinates due to numerical instability, this used to be ignored by UV selection code, now user should ensure those are perfectly matching using the merge tool first?

Campbell Barton (campbellbarton) changed the subtype of this task from "Report" to "Known Issue".

poke. Bug still here and it is important!

if bug is «unsolvable», why don`t we have just workaround (merge by distance)? at least it will eliminate issue on the user`s side.

I think the whole behavior of breaking uvs by moving polys is just not right and this is creating huge issues when exporting to meshes to other software. Also causing render engine errors. And there is no way to actually visualize if you accidentally have "De-merged UVs".
Breaking of UVs should only be possible on user's explicit demand. Right now, if you just start moving verts or poligons in the UV editor with the wrong "Sticky selection mode" you can make a huge mess without noticing. I am not sure what the intention of these "modes" is, but it all looks totally broken and buggy to be honest.

Philipp Oeser (lichtwerk) added a project: Restricted Project.Tue, Jul 20, 9:59 AM