Multiple object editing + multiple UV channels = mess

Let’s say you want to unwrap your scene for lightmapping.

It’s very nice that we can now edit and unwrap multiple objects at a time.

However, when you want more than one channel, you have to manually go though every object in the scene and make absolutely sure it has a second UV channel with a specific name, or else the UV editor WILL SILENTLY DESTROY YOUR DEFAULT UV MAP.

I don’t have to tell you how bad a UI design this is.

Instead, when editing multiple objects with multiple UV maps, on first running an operator that does anything to the UVs, the UV editor should automatically create the second UV channel being edited to match the active object, for all selected objects.

I’m not a huge fan of doing things automatically, but it’s better by far than possibly letting the user unwittingly destroy hours of tedious packing work.

(Incidentally, there’s no way to add or remove a UV channel from multiple objects either, so that would be nice to add as well.)

3 Likes

I assure you that I mean no offence, but on account of your English, I can’t understand what your objection is. Could you try rephrasing that more clearly?

Now, I am not sure to have made a correct interpretation of what you wrote.

What does that means ?

Currently, what is edited in UVEditor is active UVmap channel for all objects selected.
If you change active UVmap in UVmap channels list for any object of selection, you change what is displayed in UVEditor.
Currently, when a second UVmap is added to a mesh; this second UVmap is a copy of first UVmap.
If you enable Magic UV addon, you can copy/paste UVs from one channel to another one.

So, at what step a second UV channel would be created to match what ?
How user have any control if that is automatically happening, each time, he enters edit mode or switch to UV Editing Workspace ?
Are you sure what you are requesting is not covered by Magic UV addon that will be bundled with official release of Blender ?

Let’s say your scene is:

  1. Cube (active)
    • UvMap
    • LightMap
  2. Sphere
    • UvMap
  3. Cylinder
    • UvMap

You select all three, open the UV editor, and you start editing (move a vertex or something, not just open the editor) Cube->Lightmap.

At this point, Blender automatically adds the missing channels to the other objects and you get this:

  1. Cube (active)
    • UvMap
    • LightMap
  2. Sphere
    • UvMap
    • LightMap
  3. Cylinder
    • UvMap
    • LightMap

At least that’s how I’d like it to work.

OK. So, imagine that you made a character with an UVmap for hair textures and his clothes are separated objects.
You select all meshes(head+clothes). Enter edit mode to unwrap UVs.
All clothes will automatically have useless UVmap channels added to them if head was selected as active object.

Each time, user will want to cut an asset into pieces and for a reason want to dedicate a new UVmap to special effect (a texture influencing particles, modifiers or just material effect).
There will be a potential addition of lots of unwanted UVmap channels.

I understand the need to quickly add an UVmap channel with a meaningful name to objects of selection and use it.
But there is no reason to make that automatic.
That could be an operator “Add Blank UVmap to Selection”.

It is probably too late for 2.80.
Really, that would be same kind of annoyance to make naming and amount of UVmaps automatically updated according to active object.
User will have to think to what active object to select before switching to UV Editing workspace if he don’t want to add useless UVmaps and cancel entering in Edit mode a lot.

Currently, user can edit at same time, 2 UV maps that have different names.
That ability would probably be lost to make your proposal valid.
Current method has its advantage. It is the less ambiguous.
Multi-object editing is confusing because it goes against our habits. There is an obvious lack in the workflow.
Your complain about destruction of UVmaps is relative to a first experience.
But that is the kind of mistake that you do once and don’t reproduce.

Now, that you know that you have to precise valid channel on all meshes before starting unwrapping, you will do it.
That is not ideal. That is painful. But that is less painful that making all users that did not have same workflow as yours confused about naming and arrangement of their UV maps.

Somebody will probably make an addon to fill that lack. Operators for UV Editing will probably be added in 2.81. UDIM is a target for 2.81.

Adding a new channel would only happen if:

  1. The user enters multi-object edit mode
  2. Selects that channel as the active channel on the active object
  3. Makes an actual edit to the data while in multi object edit mode. Just opening it wouldn’t do anything.

All three of these conditions have to be met. The potential for adding too many channels is low.

And even if sometimes an unnecessary channel is accidentally added, channels can be easily removed, so this is much, much better than the current state where the default channel is silently destroyed.

We are talking about hours of lost work that you probably won’t immediately notice, won’t be able to undo, and will be unrecoverable unless you happen to have a convenient backup. Having to remove an accidental channel here and there is nothing compared to that.

It has nothing to do with a first experience, I’ve been using Blender for many years. When you want to unwrap a full scene with 50 objects in it, the potential for forgetting a channel on an object somewhere is just too high.

Relying on addons to fix the problem is just asinine. The design should be usable from the start.

Besides, what is the use-case for editing two channels with different names? Can you name one? I sure can’t.

1 Like

I agree. But they can’t. It is too late for that. That is not the only aspect of 2.8 that is under this situation.
If they fixed everything aspect of workflow that have holes. They would have to postpone 2.80 release, two or three years more.

It does not matter. Multi-object Editing is a new experience for any user.

All three of these conditions have to be met. The potential for adding too many channels is low.

And even if sometimes an unnecessary channel is accidentally added, channels can be easily removed, so this is much, much better than the current state where the default channel is silently destroyed

That is not just a question of lost data. That is a question of understandable workflow and probably a technical question.

If you start to automatically add named channels with the idea to make multi-object editing coherent for those ones, user needs other tools to synchronize active UVmaps of all objects of selection.

If you want to initiate such creation on first edit operator, Blender will have to cycle through all objects of selection, each time, you change selection of active object or active channel.
It may have performance impact on this first editing operator.

Developers are lacking of time to make another choice. And it is probably not the most efficient one.

UV coordinates of one UVmap may be used by several textures used by same or different materials.
You can simply use multi-editing to display UVs of an object with such global UVmap as a reference to edit an UVmap with a specific purpose for another object.
Without increasing number of textures to load, you could add a little detail for one object into unused space of specular map of another object.
Because of multi-object editing, there is no more ability to use UVmap of one object just as a reference.
Both UVmaps are now forced to be under edit mode.

An imaginary deadline is no excuse for shitty UI design. They aren’t actually under any kind of contract to deliver 2.8 on any particular date. If they don’t fix it from the start, it will linger for years and you know it. This thing needs fixing. It’s bad.

As an aside, IMHO 2.8 is nowhere near ready to release. The release in several weeks they’re talking about is madness and will impact Blender very negatively if they do it.

The current workflow is certainly not understandable. It’s utter nonsense.

No, they just need to pick a name.

It’s a rubbish argument to waste hours of the user’s time to avoid wasting miliseconds of computer time.

You can just duplicate the object for your reference and then do whatever you want with it. This is a non-issue.

Look, I do not care if the problem is solved in the particular way I suggested. All I care about is that Blender should never let the user destroy valuable data in such a sneaky, silent and underhanded way. If you have a better solution, I’d love to hear it.

i had not notice this, yes this could be an issue for multi edit, an option like copy to selected its kinda needed(use same as selected) with this multi editing to synchronize where are we working.
Probably this is so new in blender that no one thoght that could be usefull, if its not fixed for 2.80 surely something its going to came up to 2.81
imagen

1 Like

It happend the same with 2.5 and everything had gone well, people suporting blender knows the blender development cycles, press may cringe about it but that was usually the way it always have been and that didn’t stop blender’s grow.
2.8xxx its going to be an on going development and this “releases” are more checkpoints to set the floor for the next step rather a ground breaking release, this way of developing software was the way blender worked at least the last fifteen years and the crazy thing is that other softwares around jumped in the same style of progressive development cycles, so its not going to be that harmful.

I agree. As NahuelBelich said, they already did that, once.
And they probably redo it this time. There pressure by sponsors and users on them to release 2.80, this year is still present.
They postponed Dynamic Overrides for that goal.
IMO, that was a big mistake because it impacts use of collections and make them less understandable.
They did not complete Vertex Color Alpha workflow.
They did not deliver baking a good UI workflow.
Multi-object editing is limited to few modes.
So, I really think they will try to release 2.80 before Siggraph without trying to make it better.

But how blender can know that user is destroying the data and not just editing it ?
When you enter dyntopo mode, there is a warning saying that you will destroy UV, Vertex colors and custom data.
There could be same kind of warning.
That does not change the fact that is responsibility of user to know what he is editing.

Not focusing on name of UVmap is the less binding workflow.
You can create an UVmap from different manners.
You can change your mind and delete an UVmap with default name and keep on mesh an UVmap with an unusable name.
They could have an automatic name from Blender. They could have a different automatic name from an addon.
Your proposal in this case of 2 different names with only one UVmap channel is to create an unnecessary UVmap channel to allow multi-object editing.

The problem,here, is that corresponds to set active second slot on all objects.
If you have some objects with 3 slots, other with only 2, that does not necessary mean that is what you want.
Objects with UVmaps named A,B,C some with A,B, others with B,C and user wants to edit B.

To sum-up, just the name or just the index, it is not a sufficient condition.
An operator to synchronize active slot according name or index would facilitate the workflow.
That could be inside a little triangle menu under +/- buttons. That could be inside Right Click menu. But that could not be Copy Selected (too ambiguous, do you copy slot index, rename, select according name, transfer UV data on same slot ?)

But if we impose an automatic addition of slots, I am sure that newbies will create lots of them and complain about that like people may complain about fake user.

Setting aside as to whether this will be fixed by 2.80 or 2.81, perhaps the thing to do would be, whenever it’s relevant, a warning “This operation would destroy old UVs.”, a list of all objects that would be affected this way, and three options:
“Cancel”, “Create new UVs and Proceed” and “Overwrite old UVs and Proceed”
(Maybe a slightly less wordy version could be found)

This way it would be entirely transparent either way.

2 Likes