Page MenuHome

Smart UV Project doing very bad UV projection in recent builds
Closed, ResolvedPublic


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)



Event Timeline

Sanc Tuary (sanctuary) updated the task description. (Show Details)
Sanc Tuary (sanctuary) raised the priority of this task from to Needs Triage by Developer.
Sanc Tuary (sanctuary) set Type to Bug.

forgot to add screenshots :

bad elongated projected uv in recent blender-2.70-6026295-win32 :

correct proportioned faces in old blender-2.70-a7242c3-win32 :

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.

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

Thomas Dinges (dingto) triaged this task as Normal priority.Apr 8 2014, 8:48 AM

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 :

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 :

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

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,