Closed siliconvoodoo closed 1 year ago
DXC won't build. Must do some casts. On it now.
I found a local hack to empirically test the viability of the change.
By changing AuxGeomObject.azsl's pixel shader to:
[[range(4,8)]]
option int o_clr = 5;
PSOutput MainPS()
{
PSOutput OUT;
OUT.m_color = ObjectSrg::m_color;
if (o_clr == 5)
OUT.m_color = float4(1,0,1,1);
else if (o_clr == 6)
OUT.m_color = float4(1,1,0,1);
else if (o_clr == 7)
OUT.m_color = float4(1,0,0,1);
return OUT;
}
and adding
shaderOptionAndValues.push_back(
RPI::ShaderOption(Name("o_clr"), Name("6")));
in FixedShapeProcessor.cpp line 1515. and
console->PerformCommand(AZStd::string::format("r_forceRootShaderVariantUsage %s", "true").c_str());
In ProceduralSkinnedMeshComponent.cpp
We get
I verified that setting 7 gets red, setting nothing gets majenta. And that using azslc 1.8.12 (prior to fix) even when the option is set to "6" we get blue, which is the object color.
Which proves the problem existed, and the fix was necessary.
report github.com/o3de/o3de-azslc/issues/75
This adds the min by using a id (name) reference to the first enumerator name, in case of enums, or it emits a full switch in case the enum is complicated. In case of integer range, it reproduces the value by adding the min as an integrer literal value from the range attribute. I noted that there is no intelligence in reproduction of the underlying type, it's always uint, this will probably be an issue for negative range int options. Need to open a second issue after a bit of investigation about this.
The test suite has a new test to check this new emission pattern. the test suite tests green on windows.
tests not done: in runtime (output colors according to option retrieved from constant buffer key (must use root variant))