Blender 2.8 UV packing scales UV islands non uniformly #61239

New Issue

Ludvik Koutny · 2019-02-06T15:42:31+01:00

Ludvik Koutny commented

2019-02-06 15:42:31 +01:00

System Information
Operating system: Windows 10
Graphics card: GTX1080Ti

Blender Version
Broken: 2.8 latest master

Short description of error
Pack feature of UV editor in Blender 2.8 scales packed islands non uniformly, making it useless, for anything. A 3D software with no functional UV packing feature is a big problem, as it means any UV mapping work has to be done outside of Blender.

UV islands before Pack:

Same UV islands after Pack:

Exact steps for others to reproduce the error
1, Open attached file:
PackBug.zip
2, In Mesh mode, select all mesh elements and Uwrap the mesh using Cube projection:

3, In the UV editor, select all UV islands and pack them using "Pack" operation

Result: Pack feature produces garbage, non uniform UV layout

Expected: Pack feature does not alter scale of the UV islands in ANY way unless explicitly allowed by user.

**System Information** Operating system: Windows 10 Graphics card: GTX1080Ti **Blender Version** Broken: 2.8 latest master **Short description of error** Pack feature of UV editor in Blender 2.8 scales packed islands non uniformly, making it useless, for **anything**. A 3D software with no functional UV packing feature is a big problem, as it means any UV mapping work has to be done outside of Blender. UV islands before Pack: ![Pack_Broken.JPG](https://archive.blender.org/developer/F6528546/Pack_Broken.JPG) Same UV islands after Pack: ![Pack_Broken_After.JPG](https://archive.blender.org/developer/F6528551/Pack_Broken_After.JPG) **Exact steps for others to reproduce the error** 1, Open attached file: [PackBug.zip](https://archive.blender.org/developer/F6528593/PackBug.zip) 2, In Mesh mode, select all mesh elements and Uwrap the mesh using Cube projection: ![image.png](https://archive.blender.org/developer/F6528597/image.png) 3, In the UV editor, select all UV islands and pack them using "Pack" operation ![image.png](https://archive.blender.org/developer/F6528605/image.png) Result: Pack feature produces garbage, non uniform UV layout Expected: Pack feature does not alter scale of the UV islands in **ANY** way unless explicitly allowed by user.

Ludvik Koutny commented

2019-02-06 15:42:31 +01:00

Added subscriber: @Rawalanche

blender-admin commented

2019-02-06 15:42:31 +01:00

#61277 was marked as duplicate of this issue

Sebastian Parborg commented

2019-02-06 15:50:40 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-02-06 15:50:40 +01:00

Changed status from 'Open' to: 'Archived'

Sebastian Parborg closed this issue

2019-02-06 15:50:40 +01:00

Sebastian Parborg self-assigned this 2019-02-06 15:50:40 +01:00

Sebastian Parborg commented

2019-02-06 15:50:40 +01:00

This is not a bug but a feature request.
All features requests go to: https://rightclickselect.com/

This is not a bug but a feature request. All features requests go to: https://rightclickselect.com/

Ludvik Koutny commented

2019-02-06 16:20:05 +01:00

In #61239#614563, @ZedDB wrote:
This is not a bug but a feature request.
All features requests go to: https://rightclickselect.com/

Are you being serious?

Non uniform scaling of packed islands literally defeats the point of UV packing. It's literally impossible to use this feature to any benefit. At the same time, UV packing is absolutely essential feature of any 3D package.

Furthermore, it's a regression from 2.79, where UV packing did not scale the UV islands:

If you fail to recognize significance and severity of this, I have to question whether you are fit to triage bugs for any software application even remotely related to 3D graphics O_o

> In #61239#614563, @ZedDB wrote: > This is not a bug but a feature request. > All features requests go to: https://rightclickselect.com/ Are you being serious? Non uniform scaling of packed islands literally defeats the point of UV packing. It's literally impossible to use this feature to any benefit. At the same time, UV packing is absolutely essential feature of any 3D package. Furthermore, it's a regression from 2.79, where UV packing did not scale the UV islands: ![Packing279.JPG](https://archive.blender.org/developer/F6528891/Packing279.JPG) If you fail to recognize significance and severity of this, I have to question whether you are fit to triage bugs for any software application even remotely related to 3D graphics O_o

Brecht Van Lommel commented

2019-02-06 16:46:16 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-02-06 16:46:16 +01:00

Changed status from 'Archived' to: 'Open'

Brecht Van Lommel reopened this issue

2019-02-06 16:46:16 +01:00

Brecht Van Lommel commented

2019-02-06 16:46:16 +01:00

This was indeed an unintentional change

@Rawalanche, please be professional and avoid the personal attacks, mistakes happen if you triage dozens of bugs a day.

This was indeed an unintentional change @Rawalanche, please be professional and avoid the personal attacks, mistakes happen if you triage dozens of bugs a day.

Sebastian Parborg was unassigned by Brecht Van Lommel

2019-02-06 16:47:25 +01:00

Brecht Van Lommel self-assigned this 2019-02-06 16:47:25 +01:00

Ludvik Koutny commented

2019-02-06 16:54:30 +01:00

In #61239#614646, @brecht wrote:
This was indeed an unintentional change

@Rawalanche, please be professional and avoid the personal attacks, mistakes happen if you triage dozens of bugs a day.

I am sorry I got heated up. Non the less, the report is very clear, screenshots and repro scenes provided, and the issue is significant. I honestly still find it difficult to believe this was just an oversight, since it was so quickly concluded as feature request.

> In #61239#614646, @brecht wrote: > This was indeed an unintentional change > > @Rawalanche, please be professional and avoid the personal attacks, mistakes happen if you triage dozens of bugs a day. I am sorry I got heated up. Non the less, the report is very clear, screenshots and repro scenes provided, and the issue is significant. I honestly still find it difficult to believe this was just an oversight, since it was so quickly concluded as feature request.

Sebastian Parborg commented

2019-02-06 17:32:04 +01:00

This is the result I got when following the instructions in both 2.79 (git) and 2.8 (2.8 to the left and 2.79 to the right):

As you can see the difference is not that much so I thought you were requesting something that had not been in blender before.
You should have made it clear from the bug report that this was not the case.

But instead you just said to expect garbage output. And because I got nearly the same in 2.79, you can see how I made my conclusion.

This is the result I got when following the instructions in both 2.79 (git) and 2.8 (2.8 to the left and 2.79 to the right): ![test.png](https://archive.blender.org/developer/F6529414/test.png) As you can see the difference is not that much so I thought you were requesting something that had not been in blender before. You should have made it clear from the bug report that this was not the case. But instead you just said to expect garbage output. And because I got nearly the same in 2.79, you can see how I made my conclusion.

Ludvik Koutny commented

2019-02-06 17:36:01 +01:00

In #61239#614667, @ZedDB wrote:
This is the result I got when following the instructions in both 2.79 (git) and 2.8 (2.8 to the left and 2.79 to the right):

As you can see the difference is not that much so I thought you were requesting something that had not been in blender before.
You should have made it clear from the bug report that this was the case.

But instead you just said to expect garbage output. And because I got nearly the same in 2.79, you can see how I made my conclusion.

Yeah, sorry. Now I am very confused.

https://youtu.be/YXGVPEZQ1_g

I am using latest 2.8 master downloaded from Blender.org this morning. No matter how many times I repeat those steps, I always get the wrong, non uniformly scaled pack. I have no idea how you are able to get the right pack

> In #61239#614667, @ZedDB wrote: > This is the result I got when following the instructions in both 2.79 (git) and 2.8 (2.8 to the left and 2.79 to the right): > ![test.png](https://archive.blender.org/developer/F6529414/test.png) > > As you can see the difference is not that much so I thought you were requesting something that had not been in blender before. > You should have made it clear from the bug report that this was the case. > > But instead you just said to expect garbage output. And because I got nearly the same in 2.79, you can see how I made my conclusion. Yeah, sorry. Now I am very confused. https://youtu.be/YXGVPEZQ1_g I am using latest 2.8 master downloaded from Blender.org this morning. No matter how many times I repeat those steps, I always get the wrong, non uniformly scaled pack. I have no idea how you are able to get the right pack

Sebastian Parborg commented

2019-02-06 17:49:18 +01:00

I'm using the latest commit on the 2.8 git branch. But I don't see any obvious fixes for this problem in the commit log.

Just for the sanity of both of us, here you have a video when I try to reproduce this in 2.8:
output.mkv

I'm guessing that something might have broken it and then fixed it today? I'll try the commit from the build bot too.

I'm using the latest commit on the 2.8 git branch. But I don't see any obvious fixes for this problem in the commit log. Just for the sanity of both of us, here you have a video when I try to reproduce this in 2.8: [output.mkv](https://archive.blender.org/developer/F6529577/output.mkv) I'm guessing that something might have broken it and then fixed it today? I'll try the commit from the build bot too.

Ludvik Koutny commented

2019-02-06 17:57:05 +01:00

In #61239#614684, @ZedDB wrote:
I'm using the latest commit on the 2.8 git branch. But I don't see any obvious fixes for this problem in the commit log.

Just for the sanity of both of us, here you have a video when I try to reproduce this in 2.8:
output.mkv

I'm guessing that something might have broken it and then fixed it today? I'll try the commit from the build bot too.

Hmm, I've tried even newer build from buildbot, from today's afternoon, and it's the same. I wonder if it could be Linux vs Windows thing :|

> In #61239#614684, @ZedDB wrote: > I'm using the latest commit on the 2.8 git branch. But I don't see any obvious fixes for this problem in the commit log. > > Just for the sanity of both of us, here you have a video when I try to reproduce this in 2.8: > [output.mkv](https://archive.blender.org/developer/F6529577/output.mkv) > > I'm guessing that something might have broken it and then fixed it today? I'll try the commit from the build bot too. Hmm, I've tried even newer build from buildbot, from today's afternoon, and it's the same. I wonder if it could be Linux vs Windows thing :|

Sebastian Parborg commented

2019-02-06 18:05:59 +01:00

Yeah, probably. I get the same result as before with a commit from feb 5.

@brecht any ideas? Or did you manage to reproduce this too?

Yeah, probably. I get the same result as before with a commit from feb 5. @brecht any ideas? Or did you manage to reproduce this too?

Sebastian Parborg commented

2019-02-06 18:19:05 +01:00

@Rawalanche I guess you could see if loading factory settings helps? (I doubt it but just in case)

Brecht Van Lommel commented

2019-02-06 18:21:35 +01:00

It may be related to the aspect ratio of the assigned image textures. If they are non-square the UV editor does a correction for some operations.

I couldn't immediately reproduce the bug, but can go over the code to check what changed compared to 2.79.

It may be related to the aspect ratio of the assigned image textures. If they are non-square the UV editor does a correction for some operations. I couldn't immediately reproduce the bug, but can go over the code to check what changed compared to 2.79.

Ludvik Koutny commented

2019-02-06 18:48:29 +01:00

Reset to factory settings did not help, but Brecht is right, it has something to do with aspect ratio of the texture. I have replaced the texture on the first material slot of the mesh with square aspect ratio texture and pack is no longer distorted. That's very odd behavior for three reasons:

1, It does this correction based on texture of the first material in the material slots, even when the object can have multiple materials, each having multiple textures of different aspect ratios.

2, It does this correction even when none of those non-square textures are selected in the UV editor

3, This "correction" can't be disabled from user side in any way :/

Reset to factory settings did not help, but Brecht is right, it has something to do with aspect ratio of the texture. I have replaced the texture on the first material slot of the mesh with square aspect ratio texture and pack is no longer distorted. That's very odd behavior for three reasons: 1, It does this correction based on texture of the first material in the material slots, even when the object can have multiple materials, each having multiple textures of different aspect ratios. 2, It does this correction even when none of those non-square textures are selected in the UV editor 3, This "correction" can't be disabled from user side in any way :/

Brecht Van Lommel commented

2019-02-13 19:24:56 +01:00

Added subscriber: @khader-1

blender-admin commented

2019-03-11 12:44:14 +01:00

This issue was referenced by 403ae48063

This issue was referenced by 403ae48063d91126bd36ca56920290bcb53f504e

Brecht Van Lommel commented

2019-03-11 14:35:41 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-03-11 14:35:41 +01:00

Adam Janz commented

2019-12-04 16:40:49 +01:00

Added subscriber: @AdamJanz

Adam Janz commented

2019-12-04 16:40:49 +01:00

Just for future reference, the UV stretching issue (caused by assigning an image with a different aspect ratio than the image the unwrap occurred on) can be corrected by the Magic UV addon (included in Blender). The feature is called "Preserve UV", accessible from the "U" menu in edit mode in the 3D view (once Magic UV is enabled). Example .blend attached.

Scenario shown in the .blend file:

Make sure the Magic UV add-on is enabled in Blender's preferences.
A "non-square" image has been added to the Cube's material, and the Cube has been unwrapped. The UV layout appears normal (non-stretched).
In the shader editor, if you just click on "Browse Image to be linked" and change to "square.png", you will notice the UV layout will become stretched. Change it back to "non-square.png", and the UV will appear normal again. This is important. In order for the addon to work correctly, the currently assigned image MUST possess the same aspect ratio that the UV unwrap occurred on.
Now in edit mode, hit "U" in the 3D view, select "Preserve UV", and choose the image called "square". Notice the square image automatically becomes assigned AND the UV layout is preserved (non-stretched)! This handy feature was added by the developer a few years ago to deal with this very issue and makes it possible to switch between square and non-square images (or vice-versa) while preserving the aspect ratio of the original image where the UV unwrap occurred. :-) There is another option that pops up during the process allowing you to change the "aspect origin", but I honestly don't know how this works, and leaving it set to "center" seems to work fine.

I hope this helps someone who may encounter this issue in the future.

PreserveUVTest.blend

Just for future reference, the UV stretching issue (caused by assigning an image with a different aspect ratio than the image the unwrap occurred on) can be corrected by the Magic UV addon (included in Blender). The feature is called "Preserve UV", accessible from the "U" menu in edit mode in the 3D view (once Magic UV is enabled). Example .blend attached. Scenario shown in the .blend file: 1. Make sure the Magic UV add-on is enabled in Blender's preferences. 2. A "non-square" image has been added to the Cube's material, and the Cube has been unwrapped. The UV layout appears normal (non-stretched). 3. In the shader editor, if you just click on "Browse Image to be linked" and change to "square.png", you will notice the UV layout will become stretched. Change it back to "non-square.png", and the UV will appear normal again. This is important. In order for the addon to work correctly, the currently assigned image MUST possess the same aspect ratio that the UV unwrap occurred on. 4. Now in edit mode, hit "U" in the 3D view, select "Preserve UV", and choose the image called "square". Notice the square image automatically becomes assigned AND the UV layout is preserved (non-stretched)! This handy feature was added by the developer a few years ago to deal with this very issue and makes it possible to switch between square and non-square images (or vice-versa) while preserving the aspect ratio of the original image where the UV unwrap occurred. :-) There is another option that pops up during the process allowing you to change the "aspect origin", but I honestly don't know how this works, and leaving it set to "center" seems to work fine. I hope this helps someone who may encounter this issue in the future. [PreserveUVTest.blend](https://archive.blender.org/developer/F8189493/PreserveUVTest.blend)

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

Blender 2.8 UV packing scales UV islands non uniformly #61239