Multires Modifier: Subdivide / Unsubdivide damages UV #92201

New Issue

Mateusz · 2021-10-14T10:28:48+02:00

Mateusz commented

2021-10-14 10:28:48 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.40

Blender Version
Broken: version: 2.93.4, branch: master, commit date: 2021-08-31 09:23, hash: b7205031ce
Worked: (newest version of Blender that worked as expected)

Short description of error
Applying subdivisions via modifiers ends up in corrupted UV's

When you apply a subdiv or multires modifier, it will split the UV's at various areas, creating additional UV edges in the process.
This can be easily visualised by tagging Seams in the 3D Viewport.
To tag the seams we can use the menu operator Seams from Islands in the UV Editor under the menu UV.

We can use the Monkey primitive as an example since it is created with multiple UV islands.
Here is where Blender tags the Seams before the subdivisions are applied:

And when doing the same thing after the modifier is applied it will look like this:

Exact steps for others to reproduce the error

Object mode -> Add -> Mesh -> Monkey
Add a Subdiv/Multires modifier
Subdivide any number of times
Apply modifier
Switch to the UV Editing workspace
Select all vertices of the 3D Viewport
In the UV Editor use the menu operator UV -> Seams from Isalnds

You will see that the UV islands don't match the tagged seams.
If you proceed to drag UV points in the UV Editor around the pupil, you can see that a lot of UV edges have been split when the modifier was applied:

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.40 **Blender Version** Broken: version: 2.93.4, branch: master, commit date: 2021-08-31 09:23, hash: `b7205031ce` Worked: (newest version of Blender that worked as expected) **Short description of error** Applying subdivisions via modifiers ends up in corrupted UV's When you apply a subdiv or multires modifier, it will split the UV's at various areas, creating additional UV edges in the process. This can be easily visualised by tagging Seams in the 3D Viewport. To tag the seams we can use the menu operator `Seams from Islands` in the UV Editor under the menu `UV`. We can use the Monkey primitive as an example since it is created with multiple UV islands. Here is where Blender tags the Seams before the subdivisions are applied: ![image.png](https://archive.blender.org/developer/F11087570/image.png) And when doing the same thing after the modifier is applied it will look like this: ![image.png](https://archive.blender.org/developer/F11087590/image.png) **Exact steps for others to reproduce the error** - Object mode -> Add -> Mesh -> Monkey - Add a Subdiv/Multires modifier - Subdivide any number of times - Apply modifier - Switch to the UV Editing workspace - Select all vertices of the 3D Viewport - In the UV Editor use the menu operator `UV` -> `Seams from Isalnds` You will see that the UV islands don't match the tagged seams. If you proceed to drag UV points in the UV Editor around the pupil, you can see that a lot of UV edges have been split when the modifier was applied: ![Screenshot_2022-03-18_12-48-42.png](https://archive.blender.org/developer/F12933279/Screenshot_2022-03-18_12-48-42.png)

Mateusz commented

2021-10-14 10:28:48 +02:00

Added subscriber: @Zunio

Mateusz commented

2021-10-14 10:38:11 +02:00

painting in Mudbox after using Multires ( ugly seams ( probably padding ) at the edges of newly created inner uv islands )

painting in Mudbox after using Multires ( ugly seams ( probably padding ) at the edges of newly created inner uv islands ) ![image.png](https://archive.blender.org/developer/F11087760/image.png)

Richard Antalik commented

2021-10-14 23:00:50 +02:00

Added subscriber: @iss

Richard Antalik commented

2021-10-14 23:00:50 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2021-10-14 23:00:50 +02:00

I wasn't able to reproduce bad result with monkey, please upload example .blend file

Mateusz commented

2021-10-15 09:51:57 +02:00

from the left:

oryginal suzanne with seams from islands ( on each stage i'm repeating this function to check differences )
added multires modifier
applied multires modifier
new multires modifier added and unsubdivided
oryginal level 0 of a suzanne with corrupted uv's

Multires_UV_Seams.blend

from the left: - oryginal suzanne with seams from islands ( on each stage i'm repeating this function to check differences ) ![image.png](https://archive.blender.org/developer/F11133153/image.png) - added multires modifier - applied multires modifier - new multires modifier added and unsubdivided - oryginal level 0 of a suzanne with corrupted uv's ![image.png](https://archive.blender.org/developer/F11133085/image.png) [Multires_UV_Seams.blend](https://archive.blender.org/developer/F11133099/Multires_UV_Seams.blend)

Richard Antalik commented

2021-10-15 22:32:08 +02:00

Added subscriber: @Sergey

Richard Antalik commented

2021-10-15 22:32:08 +02:00

Thanks for example file.

When I apply multires on multires added object, I get significantly different result:

It's not perfect though. @Sergey do you know what can cause this issue? Also I haven't found similar report, so not sure if this is design limitation if seams are not transfered perfectly.

Thanks for example file. When I apply multires on `multires added` object, I get significantly different result: ![Untitled.png](https://archive.blender.org/developer/F11150207/Untitled.png) It's not perfect though. @Sergey do you know what can cause this issue? Also I haven't found similar report, so not sure if this is design limitation if seams are not transfered perfectly.

Sergey Sharybin commented

2021-10-18 12:44:23 +02:00

It seems that the root cause happened at the "Apply Modifier" stage. Applying should not destroy UVs.
Unfortunately, I am unable to reproduce the issue (tried 2.93.4, 2.93.5 and the latest master build) and can't really think of what could be causing. Can try usual bizz like running Blender with a single thread and see if the Apply Modifier is behaving wrong.

It seems that the root cause happened at the "Apply Modifier" stage. Applying should not destroy UVs. Unfortunately, I am unable to reproduce the issue (tried 2.93.4, 2.93.5 and the latest master build) and can't really think of what could be causing. Can try usual bizz like running Blender with a single thread and see if the Apply Modifier is behaving wrong.

Mateusz commented

2021-10-19 09:52:37 +02:00

Checked at 2.93.5 - at first moment uv islands stay the same but for sure uv seams have changed. Also i've done test with texturing in mudbox ( suzanne ). It acts like there are also uv seams inside uv islands ( ) ( it makes padding outside uv seam which bleeds color producing glitches inside uv islands ).

![image.png](https://archive.blender.org/developer/F11277358/image.png) Checked at 2.93.5 - at first moment uv islands stay the same but for sure uv seams have changed. Also i've done test with texturing in mudbox ( suzanne ). It acts like there are also uv seams inside uv islands ( ![image.png](https://archive.blender.org/developer/F11277578/image.png) ) ( it makes padding outside uv seam which bleeds color producing glitches inside uv islands ).

Raimund Klink commented

2021-11-04 12:27:47 +01:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Omar Emara commented

2022-02-23 13:10:27 +01:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-02-23 13:10:27 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Omar Emara commented

2022-02-23 13:10:27 +01:00

Can you try opening Blender from the command line with blender.exe --threads 1 and check if the problem persists?

Can you try opening Blender from the command line with `blender.exe --threads 1` and check if the problem persists?

Julien Kaspar commented

2022-03-18 11:51:26 +01:00

Added subscriber: @JulienKaspar

Julien Kaspar commented

2022-03-18 11:51:26 +01:00

I've been able to reproduce this bug reliably, going back as far as Blender 2.90.

I tested it with a single thread via the terminal and the issue still persists.

I've been able to reproduce this bug reliably, going back as far as Blender 2.90. I tested it with a single thread via the terminal and the issue still persists.

Julien Kaspar commented

2022-03-18 12:54:21 +01:00

I talked with @Sergey about the issue and updated the task description to make the issue clearer. There seemed to be some confusion on how to reproduce the bug.

Just to be clear: Applying the modifier does not lead to corrupted seam tags, but a corrupted UV map.
The red seams just serve as a way to visualise the issue.

I talked with @Sergey about the issue and updated the task description to make the issue clearer. There seemed to be some confusion on how to reproduce the bug. Just to be clear: Applying the modifier does not lead to corrupted seam tags, but a corrupted UV map. The red seams just serve as a way to visualise the issue.

Omar Emara commented

2022-03-18 13:35:34 +01:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Sergey Sharybin commented

2022-03-18 15:08:03 +01:00

Bisected to b88dd3b8e7, and with an updated steps from Julien it seems to be same issue as #81065.

What I am not sure about is why that report was considered a known limitation: the commit which caused regression does not state any user benefit, there is nothing in the release notes about extra manual steps required to be performed by artists after applying modifiers.

Not really sure there is an easy way to solve this from subsurf code: I might make it so loops which are inned to ptex faces are evaluated only once, but there is no easy way to ensure numerical equality of UVs evaluated at the ptex face boundaries. I'm also not sure this is something to be fixed in a subsurf specifically: subsurf is the most common modifier to be used in the workflow which shows the issue, but it is not the only one. Other modifiers might have same exact issue.

From the possible solutions:

Revert the commit
Document the expected behavior breakage ..
** .. And look into how applying modifiers could be less annoying for artists

Bisected to b88dd3b8e7, and with an updated steps from Julien it seems to be same issue as #81065. What I am not sure about is why that report was considered a known limitation: the commit which caused regression does not state any user benefit, there is nothing in the release notes about extra manual steps required to be performed by artists after applying modifiers. Not really sure there is an easy way to solve this from subsurf code: I might make it so loops which are inned to ptex faces are evaluated only once, but there is no easy way to ensure numerical equality of UVs evaluated at the ptex face boundaries. I'm also not sure this is something to be fixed in a subsurf specifically: subsurf is the most common modifier to be used in the workflow which shows the issue, but it is not the only one. Other modifiers might have same exact issue. From the possible solutions: * Revert the commit * Document the expected behavior breakage .. ** .. And look into how applying modifiers could be less annoying for artists

Philipp Oeser commented

2022-03-30 12:40:43 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-03-30 12:40:43 +02:00

Lets continue discussion in #81065 (Applying Subdivision/Multires Modifier De-merges UV's) (and maybe raise prio there again?), will merge reports

Philipp Oeser commented

2022-03-30 12:40:54 +02:00

Closed as duplicate of #81065

Philipp Oeser closed this issue

2022-03-30 12:40:54 +02: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

Multires Modifier: Subdivide / Unsubdivide damages UV #92201