Page MenuHome

Blender 2.8 UV packing scales UV islands non uniformly
Closed, ResolvedPublic

Description

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:


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.

Event Timeline

Sebastian Parborg (zeddb) closed this task as Invalid.
Sebastian Parborg (zeddb) claimed this task.

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/

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

Brecht Van Lommel (brecht) reopened this task as Open.

This was indeed an unintentional change

@Ludvik Koutny (rawalanche), please be professional and avoid the personal attacks, mistakes happen if you triage dozens of bugs a day.

Brecht Van Lommel (brecht) triaged this task as Confirmed, Medium priority.

This was indeed an unintentional change
@Ludvik Koutny (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.

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


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

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:

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:


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

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

@Brecht Van Lommel (brecht) any ideas? Or did you manage to reproduce this too?

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

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.

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