Have a way to configure colors in a gradient per effect instance

[Seldom-SE]

Describe the solution you'd like
I don't have a particular solution in mind, but some potential solutions would be:

• Have a way to convert a vec4<f32> into a 32-bit integer color (since I can create a gradient manually with vec4<f32>s)
• Allow ColorOverLifetimeModifier to accept a color as a property
• Accept gradients as properties themselves (suggested by @djeedai)

Describe why you want that solution. Is this related to a problem?
The problem is, I would like to use the same particle effect that involves a gradient, but with arbitrary colors, but that's not possible afaict.

Describe alternatives you've considered
Create many different effect assets, each with different colors hardcoded in. This could work for my use case, but is quite jank.

Additional context
Original Discord discussion

My attempt to work around the issue:

let writer = ExprWriter::new();

// ...

let age = SetAttributeModifier::new(Attribute::AGE, writer.lit(0.).expr());
let lifetime = SetAttributeModifier::new(
    Attribute::LIFETIME,
    writer.rand(ScalarType::Float).expr(),
);

let color = SetAttributeModifier::new(
    Attribute::COLOR,
    (writer.prop("color")
        * (writer.lit(1.)
            - writer.attr(Attribute::AGE) / writer.attr(Attribute::LIFETIME))
        + writer.lit(Vec4::new(1., 0.5, 0., 0.))
            * (writer.attr(Attribute::AGE) / writer.attr(Attribute::LIFETIME)))
    .expr(),
);

effects.add(
    EffectAsset::new(1024, Spawner::rate(20.0.into()), writer.finish())
        .with_name("mining")
        .with_property("color", Vec4::ZERO.into())
        .init(age)
        .init(lifetime)
        .update(color),
)

This fails with a wgsl type error between particle.color and the expression assigning to it.

[djeedai]

As a suboptimal but simple workaround, did you try with HDR_COLOR instead @Seldom-SE? Attribute::COLOR is stored as a u32 (4 bytes) and unpacked with unpack4x8unorm() inside the vertex shader, while Attribute::HDR_COLOR is stored as a full vec4<f32> (16 bytes) and read as is without any change in the vertex shader. Obviously that's 4 times more memory, but from a purely technical perspective I think that should work.

[Seldom-SE]

Ah, I think that would help, thanks!