There is an improved UV unwrapping method under review, and it would be great to get some user testing. The main advantage of this method is that it can better preserve area, instead of mainly caring about preserving angles like the existing Angle Based method. It can be tested by using Unwrap and selecting “SLIM” in the Adjust Last Operation panel.
Test various different meshes, with varying complexity, poor topology, thin triangles, … to find potential bugs.
Test if pinning and live unwrapping works well. Unlike Conformal and Angle Based, SLIM is iterative and does not converge to the solution immediately. How is the user interface for this?
Test unwrapping with a weight painted map. Did you find this feature useful? How is the user interface?
The first thing that comes to mind at the moment is something not 100% related to SLIM but just UV’s in general, so perhaps this isn’t the best place to comment about this, nonetheless here I go.
Right now we can’t set what type of unwrap method we are using before the actual unwrapping happens. Because of this, on times we don’t want to use Angle based there is always a superfluous unwrap that has to be done so we can get the menu to pop up. This is only an issue when it’s a high poly mesh when unwrapping could take more than 30 seconds, but thus far we have been living with this. But with SLIM, since there is a vertex group field, it gets a little bit silly. If we want SLIM, we must unwrap it in angle based, switch it to SLIM and do another unwrap, only to finally have the vertex field available to us. That’s 2 unneeded unwraps; for particularly high poly meshes that could take over 4 minutes.
I know this is sort of a UI/general UV workspace issue, but I think it’s worth mentioning. As well as you might see from the GIF I think there might be a bug with typing the vertex group into the field. I have to press enter twice sometimes because it doesn’t do the vertex field at first.
Another thing, and you gotta forgive my ingorance since I’m not an animator, but I’m not sure what the use of the vertex group field is. Right now it seems to unwrap the specific vertex group, which is fine, but it also seems to get rid of everything else? It might be better if there is a toggle to allow keeping the other islands. Also the same thing can be acheived by just hitting select in the vertex group from the properties panel and then unwrapping. Maybe there is a more direct use case I’m missing because I don’t animate really.
Less stretching, really good! @Bobo_The_Imp Vertex group is meant to be used as a way to tell the unwrap algorithm where you need more detail (less stretching).
Here I have a vertex group around the cellos F holes you can see at the beginning of the GIF. I think when using SLIM with the vertex group it is trying to preserve the shape a little too hard, it creates pretty bizarre results.
Reduced the size of the vertex group, still very aggressive though. Reducing the factor to 0.5 is also pretty strong. One of those things that might mostly be useful around 0.2 or so. Pretty case by case though I would imagine.
Also I initially thought it was preserving the shape, but perhaps it is relaxing that area?
We should give the vertex group a better name and description to explain what it is. Something with “Importance”, “Balance” “Detail”, …? Suggestions welcome.
Perhaps we should not use vertex groups for this, but instead an attribute with a particular name, like we have UV seams. The operator popup could have a button to add it. But then painting is not as easy until we support attribute painting besides colors.
Even if it’s still a vertex group, a standard name that is filled in by default could help.
This is an issue. There’s a few things that could be done:
Change SLIM to be the default unwrapper assuming it’s better most of the time, so you don’t have to switch.
Assign a default vertex group (or attribute name), so this doesn’t have to be filled in.
Remember UV unwrapping settings per mesh instead of per scene? And then when this is uninitiazed, show a modal popup before unwrapping? And have the settings available permanently somewhere in the UI.
Also I feel like vertex groups works perfectly fine for now, no need to over-complicate stuff. Perhaps in the future once its easier to use generic attributes it could easily be added, but for now I feel like it should not block such a important feature for the uv editor, since its already working fine as it is.
Will the minimize stretch operation using the slim algorithm return? It was super useful! In previous builds it gave very good results, whereas the current minimize stretch in Blender usually destroys the unwrap or gives super bad results in most cases.
SLIM is not better, just another tool in the toolbox when unwraping organic stuff, angle or conformal is far superior in hard surface. Changing the default to SLIM does in my option not make sense, especially since it more performance heavy and can easily crash or freeze Blender with heavy meshes.
This could make sense, as long as it does not take to long to implement.
While the current situation not optimal, changing the unwrap operation to an popup is not an solution, it would then require at least 3 clicks to unwrap something, and remember that is a operation you use all the time!
In almost all other softwares I know uv unwrapping is just one click and its done. Its the same problem with packing, something thats one click in other softwares is at least 2 in Blender.
I would either try to solve that problem, or do nothing at all, no more unnecessary button clicks for basic operations please. Blender is already known for having a uniquely slow and clunky uv editor and I feel like this should be thought of more carefully before deciding a solution.
A solution could be: to have a UV N panel with settings and operation that are commonly used, this is more similar to how most other industrial standard software works. Theirs some UV addons for Blender that already have solved this problem to take inspiration from
For packing and unwrapping, if the settings are stored permanently somewhere then you could avoid having any modal dialog. The main reason to have a dialog would be discoverability. Someone might not now to looking in e.g. the mesh properties to find these. But I guess if all the settings are available through the Adjust Last Operation panel, it’s only those that want to avoid slow operations would need to care, and so that’s a bit more advanced and less discoverability is ok.
It’s not that obvious where to store these settings. For packing, arguably they should be stored per image datablock. Particularly the margin is in some way related to the image resolution, and a single mesh might be packed to different images with different settings. However you can unwrap without having any image datablock assigned.
The simpler solution is store everything on the mesh. An issue there is that you might have multiple objects in edit mode at the same time. And if they have different packing settings, that’s not going to work. Perhaps this is more a theoretical issue, and in practice it would be fine to just take settings from the active object, and then after running the unwrap/pack operator write them out to all the objects.
I think its over-complicating things by storing stuff per mesh, for no reason at all. Its not an solution to a real problem and would make the workflow worse in my opinion.
Most time in my experience you only use one uv unwrap method for 95-100% of your project time.
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.
For packing however its a completely different story and you usually change the packing settings a lot, however I dont see the benefit at all here neither since you usually pack with sometimes hundreds of different objects at the same time, why save settings per mesh then? It would just be confusing if you repack some stuff but all your settings randomly changed because you switched mesh.
Discoverbility its an issue everywhere in Blender and should be addressed, but dont make Blender slower for professionals when you can find most stuff within minutes of one google search. Therese better ways to do it.
I think Blender should take some inspiration from how uv-toolkit and zen uv stores there settings and shows all the operations to make it more discoveriable, I think it has solved it in a pretty elegant way while still making it faster and way more discoveriable then defualt Blender.
So what is the implication of this? That the current mechanism which remembers the settings in the scene is good enough? Because in a single a .blend you likely have mostly one type of object, and the same settings are likely to work for all of them? And if you do go back and forth between different object types, remembering the settings per object is not important?
From looking at the Zen UV UI, it is storing the packing settings somewhere right? So where is this? One the scene, image, mesh, UV editor, … ?
No, its not the best, but the solution will need to be carefully considered so it does not make it worse instead.
I think it worked fine before Blender 3.6, but now when uv packing and soon uv unwraping will be way slower, in therms of performance for some of the new operations. Its more important to consider how the settings could be change while still making it fast to use and good performance when using the operation.
No, this has not been an real problem in my experience working in Blender for AAA games.
Doing it per object is not a good idea when you usually work with hundreds of objects in edit mode at the same time when doing UVs. If you every switch the active mesh, I dont soddenly want to have all my setting randomly changed. Same if I switch the image dat block, which I do very often to check between the multiable uv-cheacker textuers or materials.
If there an special mesh than need extra attention I usually do it individually, change the settings once, unwrap and pin it once, and go one with my life.
If there was theoretically a situation as you describe where you have many meshes that all require very specific settings and also need constant iteration. I still think the zen uv way of doing would be better, since it would be possible to make your own presets settings that you can reuse in the future.
Its does not really storing it anywhere, at least not for the user If I switch mesh or workspace or image, it does not matter. The settings are the same as when it was last change and will be updated again when the user chooses to changed the settings.
I guess technically In phyton it probable stored as properties in the scene, but the user never needs to think about it.
Edit:
So I guess Scene would be the answered, sorry I should have been more clear.
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.
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 agree that first unwrapping with angle based and changing to SLIM from redo panel is not good, and on some dense meshes will cause slowing down or freezing. I think its important to have all three unwrapping types exposed as different operators, so that not only you can avoid that, but assign shortcuts and add to quick favourites if you want.
They can be same operator internally, but exposed to user as three options in Unwrap menu with different properties.
In industry standard DCC software. UV unwrap settings are set by the user from (last used case.) But initially set by the developer upon first launch (use) when fresh installed.
If SLIM is a good free unwrap algorithm that could be added. I would say go the Maya way with approaching UV operations in Blender, since they are identical. If the user initiates the “Unwrap” just let the little left pop-up run the (last used) algorithm the user had used. If the user selects “Angle” instead of “SLIM” the unwrap command on whatever is selected should run 1 more time (with as many iterations already set.)
I don’t want to steer too far off topic, but I think any Blender developer who has a difference of perspective about removing UV sync, and just unitize the UV space for all objects into a state of unified UV editing. Should themselves try and be the artist and UV a collection of objects and store them into a single 0-1 sheet.
We the community can provide a .blender scene that needs to be UV and set some rules & constraints that they must complete to industry standard. So having them to try doing it themselves will have a better grasp of the workflow problem we are speaking openly about. I’m finding it quite common that people with talent are not practicing what they do, and spend too much time speculating outcomes without proper testing. I think this is why sculpting in Blender became so profound, because Pablo wasn’t just a programmer, but also an artist who understood the requirements of what we all needed to be proficient.
@brecht I don’t know if you are looking into working in the UV improvements from this thread. But if you were so to do. Would you mind considering this approach to reconsidering the UV needs of all artists to Blenders current implementation to furthering its future improvements & updates, if all else, a re-write?
