Currently, most of the $detailblendmode options work with the UnlitGeneric shader except for one serious problem: $detailblendfactor is permanently stuck at 0 regardless of what's programmed into the VMT.
The issue stems from the fact that UnlitGeneric and VertexLitGeneric both rely on the same helper code to set $detailblendfactor:
|
pContextData->m_SemiStaticCmdsOut.SetPixelShaderConstant_W( 4, info.m_nSelfIllumTint, fBlendFactor ); |
As you can see above, $selfillumtint and $detailblendfactor share the same register, with the first three channels being utilized by $selfillumtint and the final channel being utilized by $detailblendfactor. This is a problem because $selfillumtint is hardcoded to -1 in the UnlitGeneric shader, which in turn causes the write for BOTH components of the register's channels to be skipped
It looks to me like full funtionality of $detailblendmode in UnlitGeneric can be restored by simply guarding against this -1 condition and instead writing white to the $selfillumtint channels rather than the current behavior of discarding everything. The shader never actually accesses those channels, so it seems completely safe to do so:
if ( info.m_nSelfIllumTint != -1 )
{
pContextData->m_SemiStaticCmdsOut.SetPixelShaderConstant_W( 4, info.m_nSelfIllumTint, fBlendFac
}
else
{
pContextData->m_SemiStaticCmdsOut.SetPixelShaderConstant4( 4, 1.0f, 1.0f, 1.0f, fBlendFactor );
}
This fix would be extremely nice to have for usecases like mine (drawing abstract 3D visualizations from VScript). Visualizations like these can greatly benefit from utilizing smooth two-texture blend effects, but currently that's impossible without the extremely undesirable world lighting that VertexLitGeneric imposes.
Currently, most of the
$detailblendmodeoptions work with the UnlitGeneric shader except for one serious problem:$detailblendfactoris permanently stuck at0regardless of what's programmed into the VMT.The issue stems from the fact that
UnlitGenericandVertexLitGenericboth rely on the same helper code to set$detailblendfactor:source-sdk-2013/src/materialsystem/stdshaders/vertexlitgeneric_dx9_helper.cpp
Line 1214 in 88fa198
As you can see above,
$selfillumtintand$detailblendfactorshare the same register, with the first three channels being utilized by$selfillumtintand the final channel being utilized by$detailblendfactor. This is a problem because$selfillumtintis hardcoded to -1 in theUnlitGenericshader, which in turn causes the write for BOTH components of the register's channels to be skippedIt looks to me like full funtionality of
$detailblendmodeinUnlitGenericcan be restored by simply guarding against this-1condition and instead writing white to the$selfillumtintchannels rather than the current behavior of discarding everything. The shader never actually accesses those channels, so it seems completely safe to do so:This fix would be extremely nice to have for usecases like mine (drawing abstract 3D visualizations from VScript). Visualizations like these can greatly benefit from utilizing smooth two-texture blend effects, but currently that's impossible without the extremely undesirable world lighting that
VertexLitGenericimposes.