Image file woes: screen+blend included/ several questions

Look at the screen grab:

The image “body.png” is loaded, as you can see in the red square.
But WHY is it not in the image editor header (red circle)?
Why is it not listed in the outliner?
Why does it not appear in the dropdown list in the node?
Why is it seemingly impossible to Replace “UV Grid. 003” with “body.png”, which should be simple.
(blend file attached: try to replace images) (313.6 KB)

Blender uses a rather confusing russian doll data system, I think I’m not wrong if I say that for the selected image name (UV Grid 003) you can affect any image you want. If you select the image called Body.PNG, it will be the image associated with the image called UV Grid 003. You could have as well directly upload Body.PNG and the image would have been automatically called Body.PNG instead of UV Grid 003. Note: I usually always pack the images into the file, this way I’m sure that I don’t loose them or get confused with the folders.

1 Like

“UV Grid.003”, is the name of the image slot that “body.png” is in. The quick answer is rename “UV Grid.003” to “body.png” and bob’s your uncle.

The longer answer is “how the hell did I get here?”

Because you decided that the logical thing to do is simply replace “UV Grid.003” with “body.png”, or you saved “UV Grid.003” as “body.png”. Either way you have not changed the image slot name. And there is nothing wrong with your logic.

This is an absolutely annoying thing, I agree. I am not sure what it takes to fix it so that you can automatically rename that slot if you “replace” or “save as”. But as it is now you just have to get used to creating a new image with the name you will be using. Or as you decide to save it as another name you rename the slot to match it.

Of course as mentioned you can import the image. Then delete the old one in the Outliner.

So translated another way these as “images” is a misnomer. They are not images, they are image containers.

I wish I had better news.

1 Like

OK, that makes sense: the data structure (which I think is stupid), not the UI. :roll_eyes::roll_eyes::roll_eyes: Thanks, Richard.

Not unlike the “material slot” system, this seems very ‘programmer-y’ – like the designers decided ♪ “redirection is SO handy in C, let’s put it in this 3d animation package!!!1!”. ♫

At the least they could rename that FUNCTION, and call it something else: and somehow direct users over to the sidebar SOURCE field, which is the actual image file.

For now I’m going to conceptualize that similar to how AE can either show a Layer Name alias or the actual source file, --but in Blender, subtracting out the convenience.

Is there any situation where this extra layer of abstraction is useful?

1 Like

Indeed. The automatic thing you mentioned later is probably also confusing the issue.
They have no one but themselves to blame for their reputation as an app with a horrible UI.

1 Like

I don’t know about the abstraction part. But it is consistent structurally with the “object system”, I think is what this is called. Believe it or not, both Maya and Softimage have something similar. Houdini too.

The idea with the object system is you have containers, or buckets that hold data. And this data can be shared in multiple buckets. So a Sphere mesh is in a container called Sphere. A Camera data block is in an object called Camera, and so on. You can rename these independently. And you can share what is in the container. So Camera1 Camera2 and Camera3 could all contain the data Camera. And Camera would define all of the attributes. Whereas Camera1 would contain transforms and view port visibility.

Here is the expanded view of these objects in a default scene.


Here is using Alt D to duplicate. Alt D duplicates only the object and creates an “instance” of the data. ( I renamed the data blocks first to Camera_data etc. for illustration)


Selecting one cube:

And entering Edit mode, edits both cubes:

The material system, while similar is some ways in functionality, meaning you create slots, departs in that it is what it is. It is not a container. A blank material slot does not have a name. Multiple material slots can contain the same material, but they automatically rename.

The image idea is the same as the objects idea, but it masks itself as something else. And this is completely annoying.

Additionally it does not contain the other obvious editing capability you see in the Outliner, unless you go to the data Api View.


In this view you can see what is happening. You have an image slot and then you have the path with the file it refers to. Just like objects:

As annoying as it is how they did it with images, these other things are very fundamental to understanding how Blender works. And when you understand how it works, there is a logic and power to the system when you wrangle it to your advantage.

1 Like

This is so inconsistent. Putting aside the mixing of UI metaphors, WHY aren’t Material ‘slots’ nameable?

AFAICS, “Material Slots” are identical to LW ‘Parts’ in that they are 1) a collection/designator of FACES and 2) Faces can only be members of one ‘slot’. Since slots can change functions in different Meshes, it would make sense for them to be namable, just like image containers are renamable depending on their function.

In my case, there seemed to be some sort of weird automatic assignment or connection between what should have been a static file on disk and what I was seeing. Also I was a little baffled that my bitmap wasn’t showing up in “blender file” view in Outliner, when it seemed clear it was an asset that should be listed. “Data API” is not exactly an artist friendly designation – again, it stinks of programer-ese.

Tina Fey’s famous line, “Good thing you’re pretty” here is more like “Good think you’re free.”

1 Like

I think the reason is because it is a vertex group essentially. So it is consistent with vertex groups, shape keys, UV maps and anything that is assignable to a mesh.

These are not objects that are freely movable in the scene. They are stuck to the mesh.

So think of all data as having a level. And there are two main levels.

Data/Data Assignments

Vertex Groups, UV Maps, Shape Keys, Materials and so on are all inextricably linked to the data mesh.

Materials, like Surfaces in LightWave have the additional unique property that they are also a data block that is portable. Meaning that it exists on its own. So it is a sort of bridge across objects. But it is the only Mesh level data block that does this. The renaming of Surfaces, as far as I remember it, works basically the same as LW.

Texture slots actually work in the same way as Materials with the added feature of being able to stack textures and this is like the layers system in LightWave.

But if you are going to layer textures it is probably more advantageous to use Nodes.

The image management method and interface I feel really could use a lot of help. And I agree with you there. In fact I think a lot of things need improvement interface wise.

My focus becomes simply. Illogical or strange as it might be - just figure it out and move on… lol

So while I feel your pain, all I can do is point you in the direction of what is, and try as best as I can to also impart what logic exists behind it from my experience. And also note this is not just me thinking about it. But by experience, I mean that literally using it for a number of years and seeing from a practical level how it works and why.

This is in no way an assertion I think all of it is fully baked yet.

I disagree about several things here, but it is late so I’ll keep it short:

Since Vertex groups can be ambiguous about which Faces they describe, I disagree here: Material slots are specfic to Faces alone. IE, if a literal vertex group surrounded a Face w/a different Material. You’d have to do some fancy programming around that, to no advantage: it’s easier just to assign Materials to Faces.

Material SLOTS are bound to specific data meshes, but not Materials, that’s the advantage of Materials, there’s a common store. There’s still echoes of the old Slot numbering system in the UI, which at least assigned some label to slots-- I don’t know why they don’t take the next small step and just make Slots nameable, e.g. like “ScrewHeads” or “Brackets01”, and you could try different Materials on these parts. (I suspect that slots are STILL numbered, it’s just not visible in the Material panel but it is in the Shading window.) Naming slots would be consistent with the overall Blender data model, as we’ve discussed.

This is the first I’ve heard of stacking slots like LW-style layered Surfaces.

I know I’ve got to embrace it as is, but A) sometimes the squeaky wheel gets greased, and B) I enjoy talking about UI issues, and C) I think people are 'wayyyyy too deferential to developers. Sometimes a script will pop out of the ether too. I submit a lot of stuff to RCS for my sins. Some of my ideas were incorporated into LW too, so I live in hope.

Thanks for your help in clarifying these concepts. :+1:t3:

1 Like

I haven’t read all your posts, I would say that the Blender data system makes sense, what can be improved is the way it is managed by the interface, for example management of materials which is very disturbing at the beginning (and even later lol), I think that it’s slowly improving, for example now we are able to remove unused materials in the Material panel, yeehee… aha, I love Blender though but yes, needs to be rethought

1 Like

Cool. No problem. Regards the materials bit I am not sure I am following exactly. If you have more to add I would love to hear it.

I recall that there is a script/add-on someone made that renamed the data block when the object was renamed. I’ll see if I can find it, and if I can, I’ll test to see if it works for the image situation.

1 Like

Thanks for your comment: To me, a piece of software IS its interface, so I may be overreaching to opine on data structures. They seem to work, so :man_shrugging:t3:. At heart all 3d animation packages are databases, but how it’s presented to the user is my concern.

Blender didn’t come by its horrid UI reputation by accident: no matter the underlying elegance of its architecture (if indeed this is so), it presents a baffling face to the world. Even long-time enthusiasts take shots at it (BlenderGuru, Captain Disillusion) on this front. It’s almost perverse how the devs, IMO, keep choosing the most pessimal of solutions to issues that have been LONG solved in other software. (I will say the Sculpt module seems MUCH more well-designed than older parts of the program. Kudos to Pablo.)

Right now I just keep running into, using blender dev terminology, “papercuts”: things that aren’t show-stoppers but make me wince everytime I run into them. Some of my biggest gripes are just terminology: as discussed above, I find the choice of “material slot” to be unhelpful, it’s really a Face Group (not to be confused with Face Maps) and calling it a Face Group rather than a “slot” would describe its functionality a lot better. --Maybe it’s a language thing and works better in Dutch.

(RN the only big bugs I encounter are addon incompatibilities: eg “Stored Views” does not seem to like Texture Paint at all, I’ve had it crash back to the metal several times.)

I think everybody knows and agrees with what you say, things are slowly improving but I think there are 2 problems: Blender is always a work in progress, it would need a complete pause and rethink of the whole thing, and it would need more developers, more designers, etc…

But yes data management and UI in Blender are sometimes really strange. I can’t even say that I have a solution because I didn’t even think on how to solve all these problems and I ignore some of the inner limitations due to the architecture, language, etc.

When I began with Blender several years ago it seemed to me very un-intuitive but I thought that there might be a reason for that (which I’m not so sure anymore ah ah), I accepted it, and now I understand or at least get used to most of these things.

Dealing with materials, actions, fake users, how to duplicate, delete, wtf!!!?!!

If one day they decide to rethink the whole thing and put everything back in order, I’ll be the first one to be happy, even though it was so hard to learn lol…

I think the difference here is mainly semantic. In the fullest sense. Not in the dismissive sense that many people use the word, not knowing the research that went into that subject initially. Semantics has come to mean “oh you are just arguing terms for the same thing”. Well yes and no.

I don’t even think Material Slot is the official word for it. This is just my conceptual grasp of it. I would not call it a Group because a group implies an absolute. A vertex group is not interchangeable and you can’t plug things into it. You can however use groups to drive other data groups. But it is a one way action.

Selection Sets, Parts, Groups and so on are all of a same class of things. Those things which are assigned to the mesh and fused there forever. They can’t hold things that are mobile.

A Face Group semantically means something the same as a vertex group. You can’t put something in it. A weight map can’t hold anything. You can add and take away from groups or sets and add/change value to them but you can not put other free floating things into them. And the values are not free floating available as data sets for other sets to use.

So, in my view words have meanings and semantics matters.

I use Material Slot because it infers a container of sorts that is also assigned to/or as a group. It also helps in understanding why it works the way it does. You can change the values of a Material, but you can also move those values (as a data set) and/or copy them to more than one Material Slot.

So there are two things here. The Material, and where you assign it. In other groups or face sets, there is only one thing: the group, set ,etc. You can’t assign autonomous data sets to them or move the assigned data sets around freely, not store them, as you can with materials and Surfaces (LW).

I continue to disagree here: Faces cannot be unambigously defined by Vertex Groups, therefore they do not mean the same thing. They are both groups, yes, and thus the same class of entities, but they do not describe the same geometric entities.

There are other differences: Faces are exclusively members of one Material Slot, but (Blender) Vertex Groups may overlap. That is identical to the limitation of LW “Parts” (where it makes no real sense-- in LW “Parts” would have been FAR more useful if they could have overlapped).

Now that I’m hip to this chronic Amsterdamian illness of over-aliasing assets I’ll be on the lookout for it, and possibly less confused. But I still think they have a tin ear for nomenclature.

1 Like

Good news is, slight differences in opinion aside, the area will give you a little less trouble. And yes there is similar logic through Blender so it will be a case of getting easier from here.