UVs get broken when the option "correct uvs" its used
Closed, ResolvedPublic


Relates to: T31951

As you can see in the attached picture, when the loop its slide or if a loop cut its done using the "Correct uvs" option, the vertex at the uv editor will be splitted, they move just a bit but its enough to generate some issues, with the selection and the subsurf modifier.

1- create a mesh
2- do a uv map , any one will work
(a grid and a unwrap its the simpliest)
3-select a loop at edit mesh
4- Use "Slide edge"
5- at the operator menu activate "correct uvs" ( at tool shelf or F6)
5B- create a new loop using "loop cut and slide" (Ctrl+R) if you ar using this remember to activate the option "correct uvs" under the "input" menu at the "User Preference" . Its Disable by default and the operator dosnt have redo so it needs to be active before cut.
6-check the uvs at the uv/image editor

you should find that the vertex slided and the neighbours were splited.

Tested on:

Windows 7

blender 2.63a official
and build from graphicall rev 46913
but this remain the same since 2.62 i cant remember exactly witch revision, probably after bmesh

Another thing I found this report, http://projects.blender.org/tracker/index.php?func=detail&aid=29771&group_id=9&atid=498 its near but its not the same thing



Confirmed. I think the correction is done with a strange hack using projected geometry. Currently I am working on new code to correct uvs in the bratwurst branch so it may be fixed there. We'll have to see.

It would be nice if the correct UV's option was enabled by default. I didnt even realise it was there until now. I can't see any reason for people not wanting correct UV's if they are adding a loop to a mesh that already has UV's. :)

Closed duplicate report: http://projects.blender.org/tracker/index.php?func=detail&aid=31859&group_id=9&atid=498

Assigning to Antony due to he's working on this :)

Hi, sorry for not replying for too long. I am going to work on this code now because I may need to hook my UV transform correction code there. Anyway, I think the bug is easily explained: Each loop must be projected separately on a face. I will probably fix this by searching for an optimal face first and flushing the result to all coincident loops, just as I do for my new uv transform correction code.

The uv behaviour is fixed in r48340. However this bug exposed that this behaviour will happen on every loop customdata probably. We will have to eventually find a more general way to do it.

i have tested using a custom build rv48341 ((from oscurart) for windows x64, and the uvs are no longer ditorted but the last vertex at the seam become welded. . im not sure if welded is the rigth word.
i have attached a jpg and a blend file ( name_rv48341)

This has happened before though as far as I know? It is a bug and should be corrected but I will take care of it after I have prepared my code for GSOC which deals with this problem.

I just tested it using the official 2.63a from blender.org and it breaks the uvs, that little offet, but doesnt weld anything near the seam.

I have tested again and it does weld them in 2.63a as well. In the second file with the sphere, the UVs are already coincident that's why there's no difference. If not, could you post a file that shows seam uvs staying separated after transform correction? Note, make sure to refresh the image editor by zooming after the transform to see the updated result. I am almost certain because there's even a comment in the code about that and I have tested it.

added a new jpg, do i do a new test file with the official build?
i just move an other edge from the sphere

OK, I see it now, investigating.

Hi, this is not so straightforward to solve. I working on the same problem in bratwurst in a way that will solve the problem for more transform modes and support islands as well,

Fixed, r53641. Better before bratwurst merge since it's quite a nasty bug.