This is strange english I think. Smooth and Sharp are adjectives.
At least it should be ‘Unwrap by Smoothness’. But that sounds strange to me and I would have no idea what it would mean.
I’d prefer :
‘Unwrap Preserving Angles’ (for angle based)
‘Unwrap Minimizing Stretch’ (for SLIM)
As those
a) both start with ‘Unwrap’
b) clearly describe the desired outcome.
I was trying to come up with something like this. Makes more sense, it’s proper english and is clear enough (the name of the method itself doesn’t have to appear in the interface, I guess, or perhaps just in the tooltip)
I’ve pushed some improvements to the triangle correction function in the PR and now SLIM unwraps that mesh when unwrapping from the 3D viewport, but fails to unwrap when unwrapping from the UV editor.
Didn’t have time to check what’s the reason of this inconsistency yet.
The build has been updated with the latest changes (same link as before):
Hi guys. Unfortunately I am not able to reproduce the issue with pins. Probably it’s only visible in a specific situation. Could you provide a minimal blend file allowing to reproduce the issue?
Thanks!
Ok, nevermind. I think I figured it out - it looks like the issue is present only when the number of iterations is set to 1. It will debug the issue and let you know soon.
[EDIT]: Build with pins fixed can be downloaded here: Blender Builds - blender.org
@glukoz ill try to do some testing during the week.
Is there any particular situation that need more testing than other?
Thank you. I cannot think about any specific situation. Only a general idea applies: the more complex mesh, the more it’s worth testing I guess. Also remember to try it with pins 
Hi, i have been testing a bit more using the build above it work beatifully most of the time, the main issue i found was with knowing in the uv editor, when was SLIM working and when it was just stop, didn’t get any crash but several times meshes collapsed when i was trying to force weird position others simply by scaling some pinned point (see NB1 bellow)
PIned feedback.MP4 - Google Drive (Couldn’t upload this video here, sorry)
In this Drive link are the blend files with the meshes to test i used.
https://drive.google.com/drive/folders/1qLZXVYHKzbFcf6f6f8h8AcXVwhfZwJxt
NB1: This is something that i saw several times, the simulation simply colapses into the corner
NB2: In the video mentioned the bug happen if there are inverted normals, after keep testing other meshes i find out that the bug its just in the group field, add a randon name of no group there and it glitches SLIM
NB3: This was an unexpected result, in this example in particular slim with vertex pinned and live unwrap in the uv editor work as expected, the normal unwrap with slim didn’t
I have tested the new SLIM Unwrap on a wide range of meshes, and it seems to work really well in all cases I tried so far! Any news on when it will be merged? Really looking forward to this one
This implementation still needs some polishing (as indicated by great feedback by @NahuelBelich - see above). I am currently working on issues pointed by him.
just test it todays build that Brecht push to buildbot.
It does work much more stable than the last one, i wasn’t able to make SLIM collapse the uv 
Thank you for feedback and testing.
For others info: the latest SLIM build can be download from here: Blender Builds - blender.org
I’ve been getting a weird bug recently where it turns just about any boundary into a circle and tries to fit that. These are flat objects that unwrap just fine with the other methods. It didn’t happen at first, which is weird. Can anyone else confirm? Or am I missing a setting?
Here’s the file:
https://www.dropbox.com/scl/fi/2f3m6xoojvx3p9ktyabma/slim_bug.blend?rlkey=cyx8qiw2ko4kjncqgdf47af80&dl=0
interesting it can be reproduced only by this part of the hood
Moving those vertex in that part seems to fixed it, but it doesn’t work if that part still attach to the en tire hood, ¿maybe an issue related to streached faces?
i can confirm there is an issue solving some parts, don’t know why, maybe it would be a good idea to fill in a bug report in the tracker
as far as i know, that circles are the first step in the solving work for Minimum Stretch , for some reason cant keep solving and stops there.
Ok, it looks like it can be generalized to all meshes with holes. The more complex the hole, the worse the result. I’ve reported this as a bug and proposed the “Fill Holes” option available in the other unwrap methods be added to Minimum Stretch as well:
#129925 - Minimum Stretch unwrap fails on meshes with holes - blender - Blender Projects
Good day everybody
I am on the search for a solution for a problem introduced by the new unwrapping - but only UI/UX side of things!
First of all - thank you for working hard to make the UV unwrapping better!
Sadly i have one annoying complaint about the small change in relation to the UI side of things, as it breaks the fast workflow with shortcuts.
Its the addition of this sub menu here:
In the old Blender versions, i could unwrap by hitting “u” twice, as there was just a single “unwrap” context menu.
I could also unwrap follow active quads by pressing “u” → “f” → “o”.
This workflow is now slowed down, as for a simple unwrap i have to press now “u” “u” “a”, as there is now this submenu i have to get into.
For the follow active quads “u” “u” “f” “o”.
This sounds like a minor change, but it really adds up when you work 160 hours a month with trim sheets and have to unwrap a lot of things all the time.
Would it be possible to rethink that change in the UI/UX?
For example only move the new unwrap related operators in a sub menu - (angle based/conformal/minimum stretch).
The follow active quads and co could remain in the top level.
If that’s not possible, would it be okay to somehow get rid of the double tapping of “u” to get to the submenu?
Then that would reinstate the old quick shortcut workflow.
Thank you for your work, again - this is just a small but very much annoying nitpick from me.
Cheers- Lino
I also noticed a considerable slow down in the unwrapping workflow. I dont feel the submenu worth a slow down of a number of quite used shortcuts, at least for me and my team at work.
Without necessarly changing the UI again, the renstoration of the old shortcuts would allow me to not use the right hand for “u” “u” “a” , the use of double “u” is just faster for a process that requests its use a lot.
Goes without saying I think the same for the new “u” → “u” → “f” → “o”. Working in midpoly all the time, trim sheets are our daily bread and for how little and extra click looks, it translates to thousands more clicks in the span of a week and makes the workflow a notch more tedious.
Thank you for your feedback.
The given change was introduced to make the UI consistent among different places in Blender.
Of course I see no problem in reverting it back but it is a UV module owner to make the final decision (i.e. deciding what is the priority here: UI consistency vs workflow speed).
Thank you for the quick reply glukoz, much appreciated!
Who is the owner of this module? I need to poke him to make him aware of the UX issue 
