SLIM UV Unwrapping

[Bobo_The_Imp]

@brecht

“Importance”

This sounds fine to me, but either way I think changing the name to something other than vertex group would be a good idea because I feel without a tooltip I wasn’t sure what it did. I like the idea of being able to use an attribute, this feels like the most mature choice for the software, but vertex group for now is sufficient until we get attribute painting working on stuff other than colors.

As for the issue of how to bring up the options before unwrapping, using blenders conventions there are a couple ways to deal with this.

1:
In all honesty I’m a fan of the idea of putting changes into the UV editor, perhaps in the N panel like Dangry suggested.

This method would keep settings in the UV Editor preferably, or perhaps Scene. Changes in settings are linked to the operator in the 3D viewport. If you change it to slim from Angle based in the 3D viewport, the UV editors N panel does so as well and vice-versa. But this allows people to set settings in the UV editor, so when unwrap is ran from the 3D viewport it would be using those settings.

I like this method best because there is zero starting an unwrap you wouldn’t want. This makes even existing things like “margin” or “use subdivision surface” or “fill hole” etc, to not need a secondary unwrap. As well, there is no extra clicking associated with “unwrap”, it just unwraps. You could even make the UV editing workspace have the N panel open by default for discoverability.

Finally, it lays a groundwork to add new panels in the UV editor in the first place. Right now the UV editor is pretty baren and almost doesn’t feel like it deserved the split from the image editor back in the day. There is a pretty sizeable backlog of delicious confirmed tasks Daniel Bysted left for developers to tackle whenever, and some of them could potentially use panels.

Sorry I suppose this all might be off topic from SLIM but it seems like as good a time as any to bring it up.

2:

Just like batch rename we have a little pop up window before unwrapping. It’s not the best because it needs more clicks and people are already worried about that

@Dangry

no more unnecessary button clicks for basic operations please

Maybe another operator underneath unwrap like “unwrap advanced” could be implemented and just brings up the popup. Personally I don’t like this method as much.

3:

@brecht

For that probably the best solution is to implement a mechanism where if the operation is slow, a progress bar start, but you can still change the settings. And then as soon as you change the setting it will cancel the previous operation and run again. That was planned for the packing operator, but no one got to implementing it.

This is sort of alright, it would feel cleaner if we didn’t need to go through that in the first place though. As well, sometimes the unwrapping process on really complicated meshes basically takes up all the CPU and you can’t even interact with blender until the operation is finished.

@brecht

a progress bar start

No matter what happens, a progress bar that you are able to hit exit on to stop the operation would be extremely welcome!

[Hadriscus]

@brecht

For that probably the best solution is to implement a mechanism where if the operation is slow, a progress bar start, but you can still change the settings. And then as soon as you change the setting it will cancel the previous operation and run again. That was planned for the packing operator, but no one got to implementing it.

That would be so useful for a number of different operations too, I’m thinking of data transfer most notably. But data transfer has its own menu where you can specify what to transfer before running the operator, and I think the unwrap operator could work the same way, by offering a choice even before running.

[SpookyDoom]

@brecht

The other is that you may want to to remember the settings for a particular mesh or image, if you want to come back to unwrapping them without having to manually restore the settings. This has not been asked for in this topic, so perhaps it’s not that important. I don’t think this has to be as confusing as you think it would be, but there are pros and cons to every design choice.

I think this approach is much more relevant if Blender is being used in a very single-object centric way like Substance Painter for example. In that case it would really be benefitial to store things like per-object texel density settings.
In my opinion though, the unwrap algorithm itself is not really so important, as to be stored per object. I absolutely agree with Dangry here. It’s not expected to be this way in any generalized 3D app and in most of my cases a preset would be much better than storing tool settings on a mesh. Discoverability really is a general problem in Blender but something that is only a problem on the first try fo something as common and frequently used as UV unwrapping. After that as a user I want rapid iterations and consistency.

Storing texel density on a mesh sounds actually like a great idea but UV unwrap tool settings should in my experience rather remain scene memory/attributes.

[Dangry]

@brecht

One is that an operation may be slow, and you want to be able to change settings without having to wait for it to complete each time. For that probably the best solution is to implement a mechanism where if the operation is slow, a progress bar start, but you can still change the settings. And then as soon as you change the setting it will cancel the previous operation and run again. That was planned for the packing operator, but no one got to implementing it.

Wow! It would be absolute fantastic if this was to be implemented! Would solve so many of the problems with how the current operators works!

[NahuelBelich]

Nice to see this feature being work, i tested it a bit and found one of those weird situations.

This simply doesn’t unwrap

But, grave this non manifold edge loop and move it far away or smooth it or deleted and it works.

SLIM DOESNT WORK .blend in the link

SLIM DOESNT WORK .blend

[Frozen_Death_Knight]

Tried the build while at work and I was very happy with the results from SLIM unwrapping. Problem areas such as faces and hands were significantly better to unwrap and the iterative unwrapping algorithm helped a lot with getting the results I wanted. Only noticed that tight areas such as fingers could make the UVs overlap, but better that than them being too small which can be a lot harder to fix. Pinning also helped a lot with controlling the final results as well. Would be nice if unwrapping in general was a bit smarter so that UVs were oriented around a specific edge (i.e. center edge loop) so there was less need to re-orient everything such as face UVs.

I think the defaults should be set to 20 Iterations since it gives a pretty good end result in most cases I tried it on.

Also, I noticed that sometimes SLIM unwrapping ignores pins and decides to shrink the UVs.

Before:

After:

[Nicolas_Bourgeais]

I don’t think the pins work.

Do you think SLIM could be a kind of relax filter in the UV window?

[NahuelBelich]

I play a bit more with this file and i realized that the situation its even weirder, it just requires to move two vertex a bit on the corner to work in this model

[NunoConceicao]

Its great that we r seeing some work done on the unwrapping algo!
What would be even greater is to see in this improvement the possibility to unwrap with symmetry on the UV if we r modeling with symmetry/mirror modifier.

[RonanDucluzeau]

@brecht

One is that an operation may be slow, and you want to be able to change settings without having to wait for it to complete each time. For that probably the best solution is to implement a mechanism where if the operation is slow, a progress bar start, but you can still change the settings.

I am not fan of wasting energy for unnecessary computations.

@Dangry

For instance of you do hard surface stuff 95% of the time Angle is enough and Conformal is only need in some very rare cases. When you do organic SLIM is usually the only method needed.

Indeed, unless if he is a newbie, user knows what method he wants before launching unwrap operator.
So, that is not crucial to have Unwrapping method as a redo setting.

That would make more sense to have a different item per method, in Unwrap menu ; the same way as we have different extrusion methods in Extrude menu.
That would probably incite users to create shortcuts, using user preferences for each method.

That way, if a user unwraps using SLIM method ; presence of a weight group, with a specific name like SLIMAI or SAI for SLIM Area Importance (short with no confusion possible), could be automatically detected and used.
(I prefer to use vertex group, because weight paint mode has a custom color gradient and overlays for values. It was thought as a normalized float attribute painting mode. It should evolve as an attribute painting mode.)

The user directly does what he wants. That can not be faster.

[brecht]

Separate entries in the Unwrap entries makes sense to me. We need good names for that, and SLIM is not clear. Maybe it’s better to also rename it in the operator properties, as we did at some point for ABF and LSCM.

Fundamentally the difference is that Angle Based preserves angles, that is local shape. While SLIM has a balance between preserving angles and allocating area proportionally.

It’s difficult to be brief and clear at the same time, any input on this? Ideas:

For Angle Based:

• Angle Based Unwrap
• Angle Preserving Unwrap
• Unwrap by Angles

For SLIM:

• Distortion Based Unwrap
• Stretch Based Unwrap
• Distortion Minimizing Unwrap
• Stretch Minimizing Unwrap
• Area Preserving Unwrap
• Unwrap by Distortion
• Unwrap by Stretch
• Unwrap by Angles and Area
• Unwrap Balanced

[inomakani]

I like the idea of focusing on “preserving”, perhaps. That could imply something like

• “Angle Preserving Unwrap” for angle-based
• “Shape Preserving Unwrap” for SLIM

I know it is not technically accurate, especially for SLIM, but there is something to be said for having a unified way of talking about these things.

[nickberckley]

While its less obvious, angle based and SLIM are a) easier to remember, b) already widely in use.

Renaming SLIM to something else will make it hard to find documentation or tutorials about that, as other softwares and papers dont share Blender names.

[brecht]

I’m not aware of other software that implements SLIM and calls it that, do you know of any?

Avoiding cryptic abbreviations like that is part of the Blender user interface guidelines,

[nickberckley]

I havent done UVs in other softwares I dont know but couple prominent UV addons use SLIM and call it that

[brecht]

I searched a bit but could not find those add-ons.

[nickberckley]

I was thinking about Packmaster, but turns out their article I’ve read was proposal and not actually implemented, you’re right

[Frozen_Death_Knight]

@brecht

Unwrap by Angles

@brecht

Unwrap by Distortion

These are the best to me. “Unwrap” should always be the first part of the name to better find it on a list of various options. They are also better aligned with other naming standards such as the Smooth by Angle modifier.

[Doowah]

Unwrap by Sharp
Unwrap by Smooth

in all fairness make absolute sense in terms of English terms compared to what was written about (angles, and distortion). “Distortion” by itself is backwards, and is everything an artist is trying to avoid. So do not use that as a label. Whereas “Smooth” immediately pictures an organic object or surface.

[Baardaap]

@Doowah

Unwrap by Sharp
Unwrap by Smooth

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.