Thanks for this! In the pr's current state, it changes the behavior of colormode quite a bit. I think the existing colormode options should select a single color source, as the do in main. And a new value should be added to the enum that will use all color values available and multiply them (IIUC that's the option you want to expose here).

In the pr's current state, it changes the behavior of colormode quite a bit. I think the existing colormode options should select a single color source, as the do in main

Uh, I don't quite understand, but the current color mode does have only one color source, which is consistent with the original behavior. The only difference from before is that when the color mode is not explicitly set (i.e. when using the default auto), Mesh rendering will integrate all colors.
If not, it may be a bug in the logic of the code. 🤔

It looks like when e.g. color_mode is "vertex", the colormap is used if it is present. oh right, I think I see it now.

I think it would be helpful to do a full triage over the different ColorMode options in meshshader.py, and set use_vertex_color and use_colormap only if they're actually contributing to the final color. It may be a bit more verbose, but it makes the code easier to read.

[...] when using the default auto

My initial preference was to maintain the behavior of 'auto' (which selects one color source) and add a new option 'all' that combines them, but I'm also open to change the behavior of auto, but then we need to update its docs (in the above enum).

My initial preference was to maintain the behavior of 'auto' (which selects one color source) and add a new option 'all' that combines them, but I'm also open to change the behavior of auto, but then we need to update its docs (in the above enum).

From my usage perspective, the explicit "color_mode" configuration for mesh rendering appears counterintuitive. Based on typical workflow patterns:

1. Most users will naturally expect all color sources to be active by default when working with materials. Requiring explicit "color_mode" configuration to enable standard color behavior seems unnecessarily complex.

2. Texture Slot Paradigm: The "diffuse_map" operates consistently with other texture slots in the material system. Users instinctively:

   • Add textures to slots when needing specific effects
   • Remove textures from material when not required

   This aligns with standard material editing practices across 3D applications.

3. The base color property is universally recognized as a core material attribute, and user usually don't think of disabling it, but rather modifying its RGB value, for example, changing it to white (1, 1, 1).

I feel that color_mode may become a hidden feature, and most users may not pay attention to this attribute unless specific users are aware of color_mode and may use it in certain limited situations.

I understand that some groups of users expect the behavior that you describe. But I also believe there are also users, especially in interactive settings (data explorations) who may have vertex colors and want to switch between a uniform color, vertex colors etc. at runtime.

Anyway, with the current implementation we have the default that you want, but also the option to support the special cases I care about 😄

Are the CI errors related to the recent changes in pylinalg?

Are the CI errors related to the recent changes in pylinalg?

Yes.. looks like we need to support 3D and higher ndim arrays as well. I will add it to the test suite and release a patch.

Are the CI errors related to the recent changes in pylinalg?

Yes.. looks like we need to support 3D and higher ndim arrays as well. I will add it to the test suite and release a patch.

Done. :) See pygfx/pylinalg#105.

I also created pygfx/pylinalg#106 to prevent this from happening again.