Workbench shading Material and Texture color options are insufficient

I have some issues with how the Solid/Workbench shading color options work.

mat

My problem with the Material color option:
It does not show the material’s color. It colors things by a few parameters defined in (or rather associated with) a material, but it does not show the material’s actual color.
It’s like the Object color option, except the viewport display colors are defined per-material rather than per-object.
While there is definitely usage for that, I am much more often interested in displaying materials’ actual color. I want to see my materials with flat lighting or studio lighting, and as far as I know there is no simple way to do this.

This also relates to the Texture color option:
The Texture color option actually uses the material’s base color – that is, only if an image texture is plugged into it. If you go that far, why only image textures? Why not procedural textures as well?
I work a lot on game environments in Blender, and during the design process I like to mix image textures, procedural textures and vertex colors to try and define the look.

In my opinion, it should work this way:

  • The Material color options uses the material’s actual base color, roughness and metallic values. If an image texture is plugged in, then that texture is displayed. If a procedural texture is plugged in, that’s what’s displayed.
  • Then there’s some other option called “Material Viewport” or something, which acts as the Material option does now – it uses the Viewport Display properties of the Material.

To me, this makes more sense and is more useful.

Does anyone share my issues or otherwise agree? Disagree?

Actually I realized I didn’t quite understand how the Texture color option works.

The Texture color option shows the image texture which was the last-assigned in the shader editor or the image texture plugged into the base color, kinda.

  • Selecting the texture node and then linking an image (the same image) to the texture node again will display that image.
  • If the texture node is plugged into base color, selecting it will display it.
  • If the texture node is not plugged into base color, selecting it will not display it.

Why not just display whatever is plugged into base color? Why all this weird logic?

The texture color mode displays in viewport the selected “Image texture” node in the material.
You may want to see different textures for debugging porpouses.
Procedural textures would be nice to see, probably in the future :slight_smile: lets hope.

Ah, now I see the actual usefulness of this. Of course, I forgot about textures outside of base color. It’s indeed helpful to isolate your material’s base color, normal map, roughness, whatever.

But the behavior is still weird, as I demonstrated in my post and video above.
If your image texture is plugged into your material, it will display it as long as it’s selected, which somewhat makes sense.
If your image texture isn’t plugged into your material, it still will display it, as long as you also reassign an image to it. It’s very odd to me.
Maybe I’ll make a bug report for that.

But I still take issue with the design in general and think it there’s a better way for it to work.

There should be a mode for displaying whatever your material is in Workbench. The base color, roughness, all that, as I initially proposed.
Then, if you want to isolate an individual texture or something, there would be an option in the node’s context menu (and a hotkey) which would act as the opposite of muting nodes, much like a “Solo” option in audio editing software. This would isolate and display only that node, whatever it may be. (Is this what Toggle Node Preview is supposed to be? It doesn’t appear to do anything for me)

That, to me, seems like a better solution.

The how do you display other type of textures without create a weird workflow?

In any case could be good a “pin” option in nodes to pin the texture that you want to see.

I have just proposed something directly above your post which I think should address that issue, which is similar to the idea of “pinning” a node.