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

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)

Changed status to: 'Open'

Added subscriber: @sanctuary

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

Added subscriber: @Ace_Dragon

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.

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.

Added subscriber: @ideasman42

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

Added subscriber: @ThomasDinges

Added subscriber: @Sergey

@ideasman42, who maintains smart uv?

Added subscriber: @Harvester

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.

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.

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?

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.

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

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

Changed status from 'Open' to: 'Resolved'

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

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