Smart UV Project doing very bad UV projection in recent builds #39601

New Issue

Sanc Tuary · 2014-04-04T20:28:08+02:00

Sanc Tuary commented

2014-04-04 20:28:08 +02:00

System Information
Operating system and graphics card
winxp sp3

Blender Version
Broken: blender-2.70-6026295-win32
Worked: blender-2.70-a7242c3-win32

Short description of error
Smart UV Project does not project correctly

Exact steps for others to reproduce the error

File -> Load Factory Settings
Split screen in two, make one of the windows the UV/Image Editor
Select default cube and go to Edit Mode
Select All, press U -> Smart UV Project
Notice in the UV/Image editor that the faces are now distorted squares, not perfect square as they should be (and were in 2.70 stable or early post-2.70 builds)

**System Information** Operating system and graphics card winxp sp3 **Blender Version** Broken: blender-2.70-6026295-win32 Worked: blender-2.70-a7242c3-win32 **Short description of error** Smart UV Project does not project correctly **Exact steps for others to reproduce the error** - File -> Load Factory Settings - Split screen in two, make one of the windows the UV/Image Editor - Select default cube and go to Edit Mode - Select All, press U -> Smart UV Project - Notice in the UV/Image editor that the faces are now distorted squares, not perfect square as they should be (and were in 2.70 stable or early post-2.70 builds)

Sanc Tuary commented

2014-04-04 20:28:08 +02:00

Changed status to: 'Open'

Sanc Tuary commented

2014-04-04 20:28:08 +02:00

Added subscriber: @sanctuary

Sanc Tuary commented

2014-04-04 20:32:05 +02:00

forgot to add screenshots :

bad elongated projected uv in recent blender-2.70-6026295-win32 :
http://i.imgur.com/Cex4ygD.jpg

correct proportioned faces in old blender-2.70-a7242c3-win32 :
http://i.imgur.com/Kkg0Atr.jpg

forgot to add screenshots : bad elongated projected uv in recent blender-2.70-6026295-win32 : http://i.imgur.com/Cex4ygD.jpg correct proportioned faces in old blender-2.70-a7242c3-win32 : http://i.imgur.com/Kkg0Atr.jpg

Adam Friesen commented

2014-04-04 21:44:35 +02:00

Added subscriber: @Ace_Dragon

Adam Friesen commented

2014-04-04 21:44:35 +02:00

It looks like the code was changed to try to fill in the entire image space rather than just a part of it.

This type of thing really should be an option rather than how it works now, I say keeping it as an option because I could see the utility of it for texture painting.

It looks like the code was changed to try to fill in the entire image space rather than just a part of it. This type of thing really should be an option rather than how it works now, I say keeping it as an option because I could see the utility of it for texture painting.

Sanc Tuary commented

2014-04-04 21:50:32 +02:00

Yes, if that change is intentional making it as an option in F6 is really needed, as while it would be indeed ok for texture painting, for assigning an existing texture it would only lead into nasty image distorsion on the object surfaces.

Campbell Barton commented

2014-04-05 13:54:17 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-04-05 13:54:17 +02:00

In fact this looks like a float precision issue, if you chance the margin the result flickers back and fourth.

Thomas Dinges commented

2014-04-08 08:48:36 +02:00

Added subscriber: @ThomasDinges

Sergey Sharybin commented

2014-04-10 18:30:58 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-04-10 18:30:58 +02:00

@ideasman42, who maintains smart uv?

Riccardo Giovanetti commented

2014-04-11 17:43:44 +02:00

Added subscriber: @Harvester

Riccardo Giovanetti commented

2014-04-11 17:43:44 +02:00

Here on Win7 Pro 64bit, Blender 2.70a 64bit (Hash: f93bc76) there is the same issue and it seems to affect also the "Lightmap Pack" UV projection method.

Here on Win7 Pro 64bit, Blender 2.70a 64bit (Hash: f93bc76) there is the same issue and it seems to affect also the "Lightmap Pack" UV projection method.

Sanc Tuary commented

2014-04-12 13:50:40 +02:00

very bad, that nasty bug is now in official 2.70a too , the smart uv project is then not trustable anymore for unwrapping and texturing.

a very bad regression in comparison to official 2.70 in which it didn't happened.

very bad, that nasty bug is now in official 2.70a too , the smart uv project is then not trustable anymore for unwrapping and texturing. a very bad regression in comparison to official 2.70 in which it didn't happened.

Adam Friesen commented

2014-04-12 21:35:23 +02:00

I don't get it, it's an important tool for many and I can't see the fix being that hard to do.

If it became widely known that some bugs were treated like this than it will attempt to seal the idea that FOSS = We couldn't care less about what the user needs.

Is it such a formidable task to fix important tools just because you might not maintain it, should we rather not be giving the impression that Blender is not made with the user in mind (and torpedo any chance for FOSS to have a future in 3D)?

This is basically a case of, "let it be, it's not my problem", a commercial company doing may eventually get sued out of millions if they knowingly did that. Is the Blender way supposed to be professional or not?

I don't get it, it's an important tool for many and I can't see the fix being that hard to do. If it became widely known that some bugs were treated like this than it will attempt to seal the idea that *FOSS = We couldn't care less about what the user needs*. Is it such a formidable task to fix important tools just because you might not maintain it, should we rather not be giving the impression that Blender is not made with the user in mind (and torpedo any chance for FOSS to have a future in 3D)? This is basically a case of, "let it be, it's not my problem", a commercial company doing may eventually get sued out of millions if they knowingly did that. Is the Blender way supposed to be professional or not?

Thomas Dinges commented

2014-04-12 21:55:04 +02:00

Ace Dragon, your comment brings 0 value into this discussion here. This is the bugtracker and not Blenderartists!

The report is open for only 10 days, and as you might have noticed, we have 239 reports in total now. We cannot tackle everything at once.

Ace Dragon, your comment brings 0 value into this discussion here. This is the bugtracker and not Blenderartists! The report is open for only 10 days, and as you might have noticed, we have 239 reports in total now. We cannot tackle everything at once.

Sanc Tuary commented

2014-04-13 00:16:23 +02:00

On a Blenderartist thread thanks to some users helping, some odd behaviour of that bug has been noticed, some people actually observed only the correct behaviour in 2.70a

But as soon as they use Load Factory Settings in 2.70a, they will obtain only the buggy behaviour.

If i use the startup and user prefs blend of an user that do not observe the buggy behaviour , i don't see it either (until both of us use Load Factory Settings) , i loaded a 2.69 blend into 2.70a with "load ui" enabled and the bug disappeared too (to re-appear if i did a Load Factory Setting).

It's very strange, but seems to hint there's something in the default factory setting of 2.70a that is different from the default factory setting of previous versions that is contributing to that bug as the users that at first saw the correct behaviour of the smart unwrap have imported their old versions settings into 2.70a (and probably why after load factory settings they observe the bug).

If what i write is not understandable, you can check some blender users helping to test around this bug here :
http://blenderartists.org/forum/showthread.php?318765-Blender-2-7x-development-thread/page38

On a Blenderartist thread thanks to some users helping, some odd behaviour of that bug has been noticed, some people actually observed only the correct behaviour in 2.70a But as soon as they use Load Factory Settings in 2.70a, they will obtain only the buggy behaviour. If i use the startup and user prefs blend of an user that do not observe the buggy behaviour , i don't see it either (until both of us use Load Factory Settings) , i loaded a 2.69 blend into 2.70a with "load ui" enabled and the bug disappeared too (to re-appear if i did a Load Factory Setting). It's very strange, but seems to hint there's something in the default factory setting of 2.70a that is different from the default factory setting of previous versions that is contributing to that bug as the users that at first saw the correct behaviour of the smart unwrap have imported their old versions settings into 2.70a (and probably why after load factory settings they observe the bug). If what i write is not understandable, you can check some blender users helping to test around this bug here : http://blenderartists.org/forum/showthread.php?318765-Blender-2-7x-development-thread/page38

Sanc Tuary commented

2014-04-13 01:22:28 +02:00

after testing more, it looks like when indeed you use old blender version the bug disappear, but in appearance only, because it is in fact not buggy at Margin = 0
While it is immediately buggy at Margin = 0 with default factory settings.

But as soon as you increase slowly the margin, even on the situation in which it was appearing not buggy at Margin = 0 we'll still observe the elongated faces appearing after a small margin increase.
Probably confirming what campellbarton said :
https://developer.blender.org/T39601#9

still strange that depending on the default factory or older user settings, the bug is visible or not at Margin = 0

after testing more, it looks like when indeed you use old blender version the bug disappear, but in appearance only, because it is in fact not buggy at Margin = 0 While it is immediately buggy at Margin = 0 with default factory settings. But as soon as you increase slowly the margin, even on the situation in which it was appearing not buggy at Margin = 0 we'll still observe the elongated faces appearing after a small margin increase. Probably confirming what campellbarton said : https://developer.blender.org/T39601#9 still strange that depending on the default factory or older user settings, the bug is visible or not at Margin = 0

Campbell Barton commented

2014-04-24 19:31:21 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-04-24 19:31:21 +02:00

Campbell Barton self-assigned this 2014-04-24 19:31:21 +02:00

Campbell Barton commented

2014-04-24 19:31:21 +02:00

The problem is when packing boxes exactly the same size, decisions about where to place the box were comparing values which were so close to being the same, that it came down to floating point precision giving erratic/unpredictable results.

That it even gave the results it did before, was mostly accidental, it would flicker when changing margin size.

Committed some changes to box packing, so its more deterministic,

6c57ee53bf
72e9052713
d5647a37b4
e6c1a23341
69de54f99a
ae71729c8b

The problem is when packing boxes *exactly* the same size, decisions about where to place the box were comparing values which were so close to being the same, that it came down to floating point precision giving erratic/unpredictable results. That it even gave the results it did before, was mostly accidental, it would flicker when changing margin size. Committed some changes to box packing, so its more deterministic, 6c57ee53bf 72e9052713 d5647a37b4 e6c1a23341 69de54f99a ae71729c8b

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

Smart UV Project doing very bad UV projection in recent builds #39601