8a1a0b0fd2
* materials: introduce mutable spec constants Rationale & design of this feature has been discussed internally. The current implementation uses a `FixedCapacityVector` to store the new program handles, but I wouldn't object to replacing it with a hasmap as discussed offline. I have compiled but not tested this yet on Android, so I'm not certain that the API bindings are correctly wired up. * materials: mutable spec constant feedback * materials: address mutable spec constant comments
45 lines
1.1 KiB
Plaintext
45 lines
1.1 KiB
Plaintext
material {
|
|
name : BakedColorWithMutableConstants,
|
|
requires : [
|
|
color
|
|
],
|
|
constants : [
|
|
{
|
|
name: swizzle,
|
|
type: bool,
|
|
mutable: true,
|
|
default: true,
|
|
},
|
|
{
|
|
name: darken,
|
|
type: bool,
|
|
mutable: true,
|
|
},
|
|
{
|
|
// In generated shader sources, we first specify immutable
|
|
// specialization constants, then mutable specialization constants.
|
|
// By including this dummy constant, we offset the ID of the first
|
|
// mutable constant by one. This is done here purely for testing
|
|
// purposes.
|
|
name: dummy,
|
|
type: bool,
|
|
}
|
|
],
|
|
shadingModel : unlit,
|
|
culling : none,
|
|
}
|
|
|
|
fragment {
|
|
void material(inout MaterialInputs material) {
|
|
prepareMaterial(material);
|
|
if (materialConstants_swizzle) {
|
|
material.baseColor = getColor().gbra;
|
|
} else {
|
|
material.baseColor = getColor();
|
|
}
|
|
if (materialConstants_darken) {
|
|
material.baseColor.rgb *= 0.5;
|
|
}
|
|
}
|
|
}
|