[Merged by Bors] - Add support for vertex colors

[HackerFoo]

Objective

Add support for vertex colors

Solution

This change is modeled after how vertex tangents are handled, so the shader is conditionally compiled with vertex color support if the mesh has the corresponding attribute set.

Vertex colors are multiplied by the base color. I'm not sure if this is the best for all cases, but may be useful for modifying vertex colors without creating a new mesh.

I chose VertexFormat::Float32x4, but I'd prefer 16-bit floats if/when support is added.

Changelog

Added

• Vertex colors can be specified using the Mesh::ATTRIBUTE_COLOR mesh attribute.

[HackerFoo]

I shifted the locations to match the ids given in the MeshVertexAttributes in bevy_render/src/mesh/mesh/mod.rs.

[superdump]

It defaults to white, as I recall, to allow default to be identity for a material with a texture. That said, I think it's good to comment as it could easily be a source of confusion otherwise.

[HackerFoo]

Lines 37 - 40 are really there just to explain why the base_color should probably be white when using vertex colors. It seemed like a good way to document this.

[superdump]

I agree, it is. And it's an additional flexibility to be able to tint things, if nothing else. :)

[CptPotato]

Would u32 (8 bit per channel) be sufficient for vertex colors?

I personally don't think using values greater that 1.0 are very useful, because when multiplying it with the base color it could potentially "break" the PBR visuals (more light gets reflected than received). There might be some unusual use cases, though.

On the other hand, the precision of 8bit would not be that great, but since vertex attributes get interpolated I don't think it would be very visible. (edit: u64 would be another option, which would still be significantly smaller than a full vec4<f32> while being very accurate).

---

As a side note, would it be possible for users to adjust the shader so that the vertex colors are used differently? i.e. using them as light factor or emissive multiplier. In that case I could see some uses for f16/f32.

[HackerFoo]

I'm using linear float colors because it matches the base color format and the format used in the shader, and to avoid color matching problems. At least the way I use vertex colors, they aren't interpolated because all vertices of a triangle share the same color.

16 bit normalized linear color (as VertexFormat::Unorm16x4) might be good enough. Floats give greater precision near zero and generally match the logarithmic perception of light better than fixed precision numbers. So I think 16 bit floats would be ideal.

[CptPotato]

SRGB encoded integers would provide the same "perceptive" distribution of values and shouldn't cause matching issues like the one you've linked. In that case u16 would also be much more precise than linear f16 in the [0; 1] range.

But I do get your point. I'm not trying to block this PR or force you to change the implementation, just trying to provide some thought on possible alternatives.
As you already mentioned, f16 (once it's available) would be a good compromise for "general purpose" vertex colors ("unlimited" range, no conversion required in the shader, relatively small and precise enough).

[superdump]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-compiles
• check-doc
• check-markdown-links
• check-missing-examples-in-docs
• check-unused-dependencies
• ci
• markdownlint
• miri
• run-examples

[SalfordShane]

@HackerFoo Cheers for pushing this, it's a huge help.

A couple of thoughts:

• At the moment, the vertex_colors.rs example is using materials.add(Color::rgb(1., 1., 1.).into()) to set the default material colour which each vertex colour will be multiplied by.
• It makes sense, therefor, for users to simply default this to 1.0, 1.0, 1.0 most of the time, however, this produces an RGBA colour with an alpha of 1.0 by default
• When the alpha is set to 1.0, alpha blending is disabled in the StandardMaterial being used in the example.
• As a result, when changing the code in the example to use rgba values for the vertex colours, the transparency isn't working, which feels somewhat incongruous with the current expectations of how the default material colour multiplication works.

As a result, you end up having to do something like this for the material creation:

// The vertex colour channels will be multiplied by 1.0 (so will remain the same) but we explicitly enable AlphaMode blending
let mut material: StandardMaterial = Color::rgba(1., 1., 1., 1.).into();
material.alpha_mode = AlphaMode::Blend;

commands.spawn_bundle(PbrBundle {
        // ... mesh data
        material: materials.add(material),
        // ... defaults and transforms
});

There's probably no way around this for now and it's a relatively simple fix, but should we update the docs / example to mention this? It feels like a bit of a pitfall which took me a good chunk of time to debug tonight.