Page MenuHome

UV sphere unwrap is an elongated ellipse
Closed, ResolvedPublic

Description

Windows 7 Professional 64bit
Blender 2.63.0 r46461:46487M ("blender-2.63a-release-windows64.zip" from official site)
Factory settings, no add-ons.

Tested also on this build: http://graphicall.org/827 (r48353 and r47700) with a few additional add-ons, but the problem persists even when disabling all add-ons and returning to factory settings.

The problem is that the unwrap of the UV sphere (32 segments, 16 rings, equator seam) is not a perfect circle as it has always been but an elongated ellipse. (Blend file included.) I have tried different unwrapping methods (angle based, conformal) turning on/off "use subsurf data" and they do have a clear effect on the resulting UV map but none of them create a perfect circle like before. I tested this on an official 2.61 build and the UV map produced with that is perfectly fine. The image attached shows the problem. The green UV map I made with Blender 2.61 and the red UV map came out of Blender 2.63.

Event Timeline

I also made a thread about this in BlenderArtists: http://blenderartists.org/forum/showthread.php?261744-UV-Sphere-unwrap-distorted

Are you sure you're using Angle Based unwrap? At some point it was Conformal used in the trunk, so some file could have wrong default unwrapper.

I can not see any difference between how Blender 2.61 and current trunk are unwrapping UV sphere when Angle Based unwrapper is used.

Yes I am. As I said before using angle based with subsurf data gives the best results but the map is still visibly distorted.

Ah, pardon. Somehow missed that.

Antony, would you have time to check on this report? Thanks!

An important question is what version of blender was the sphere created in? It would help a lot if you could test this with 2.62 too. To me it looks like the attached file also misbehaves on 2.62 but the difference is faint so I could use an extra pair of eyes. Can you also create a sphere in 2.61 and test the behavior of the unwrapper in 2.62/2.63? To me the result looks exactly the same in this case. So probably the sphere mesh creation code is different. This still won't explain how it's possible for the same mesh to unwrap correctly in 2.61 and not in 2.63.

I did more testing. Saving a 2.63 generated file in legacy format and reunwrapping in 2.61 results in the same (buggy) unwrap which makes me believe it could be an error during mesh conversion/construction. Can you verify please?

I just tested this on Blender versions 2.60, 2.61, 2.62, and 2.63. All official zipped 64 bit Windows versions from the official site. Versions 2.60, 2.61, and 2.62 seem to perform correctly. The UV map isn't mathematically perfect but I guess it has never been since I never noticed it before. Version 2.63 on the other does not produce an identical UV map to those of the earlier versions regardless of what settings I use. It is not even close.

Creating a UV sphere in 2.61 and appending it to 2.62 worked correctly and the UV map was as good. On 2.63 the UV map was distorted.

On the custom build that I use the UV map is correct (when using subsurf data) so my problem is solved. I initially noticed it was distorted and when using subsurf data it still wasn't mathematically perfect (as I had always assumed it would be) so I though there was something wrong with it. Now that I've properly compared it to older UV maps (which also aren't picture perfect) it is as good as it is going to get. It seems that the official 2.63a version does have a problem though. I simply cannot get it to produce the correct UV map.

More oddities. I opened an older file made in 2.62 with the custom build. It works fine but when I make 128 segment 64 ring UV sphere and unwrap it the map is distorted regardless of settings. It seems that this bug is also linked to the complexity of the UV sphere as 64 segments and 32 rings produce a perfect map. Or it could be just that the save was originally made in 2.62 but I did save a few times after opening it.

Hi, can you test unwrapping a file generated in a certain mesh version system without saving in another mesh version system?

I get identical results on these cases:

sphere made in 2.61 with default options -> unwrap in 2.61, 2.62, 2.63 (sphere covers all uv space)
sphere made in 2.63 with default options, save in legacy format (save as dialog) -> unwrap in 2.63, 2.62, 2.61 (sphere covers all uv space minus a small margin on the right)

Can you please test that last case?

I made thee spheres of increasing complexity and cut the bottom off in 2.61. Unwrapping works correctly in versions below 2.63. In 2.63 the UV map is distorted regardless of settings. I did notice something interesting though.

UV map of a 32 s. 16 r. sphere covers all UV space except 2 small squares at the top. Turning on subsurf data reduces this distortion to a single square.
UV map of a 64 s. 32 r. sphere covers all UV space except 1 small square at the top. Turning on subsurf data has minimal effect on the distortion.
UV map of a 128 s. 64 r. sphere covers all UV space except 1 small square at the top. Turning on subsurf data actually increases the distortion to 2 squares and makes the UV map a perfect ellipse.

Making a sphere in 2.63a and saving with legacy provides mostly correct results.

In 2.62 32/16 and 64/32 UV spheres produce correct UV maps but 128/64 UV map is distorted only when subsurf data is enabled. Without it the UV map is correct.
In 2.61 the UV maps are correct on all three spheres, same with 2.60.

We're doing a numerical minimization here, limited precision errors in the solver are expected too, especially as the mesh resolution gets higher. So giving a perfect sphere was never guaranteed. However that's not the cause here.

These unwrapping algorithms are based on giving minimal distortion of a _triangulated_ version of the sphere. If there is an asymmetry in how the sphere is triangulated, this will show in the result. As far as I can tell the UV unwrapper triangulation code didn't change, but the UV spheres creation code did. Different vertex order or slightly different vertex coordinates due to precision are likely to be the cause here.

This unwrapper was never guaranteed to give perfect results, it just happened to be the case in 2.61 for this particular mesh. Maybe there's a tweak possible to make this case work symmetric again, but in general this is not something that can be expected.

I found a pretty simple trick to make it to symmetric triangulation in cases like this. Now we bias the choice of how to split a quad into two triangles slightly towards one of two possibilities, so that in case they are equal, floating point errors do not decide the direction and symmetry is preserved.

Fix in svn, thanks for the report.

Brecht Van Lommel (brecht) changed the task status from Unknown Status to Resolved.Aug 24 2012, 3:30 PM