We noticed an issue with the MaterialX OpenPBR Surface node definition:
|
<ln name="transmission_color_ln" type="vector3"> |
If one of the components of transmission_color_vector is <= 0, then the result of the natural logarithm (ln) function is mathematically undefined:
<ln name="transmission_color_ln" type="vector3">
<input name="in" type="vector3" nodename="transmission_color_vector" />
</ln>
You might want to prevent such a case by using:
<max name="safe_input" type="vector3">
<input name="in1" type="vector3" nodename="transmission_color_vector" />
<input name="in2" type="vector3" value="0.0001, 0.0001, 0.0001" />
</max>
<ln name="transmission_color_ln" type="vector3">
<input name="in" type="vector3" nodename="safe_input" />
</ln>
A condition could do, too. It might also be okay as is if you want to rely on the renderer to handle NaN/Inf on a per sample basis.
We noticed an issue with the MaterialX OpenPBR Surface node definition:
OpenPBR/reference/open_pbr_surface.mtlx
Line 221 in b212785
If one of the components of transmission_color_vector is <= 0, then the result of the natural logarithm (ln) function is mathematically undefined:
You might want to prevent such a case by using:
A condition could do, too. It might also be okay as is if you want to rely on the renderer to handle NaN/Inf on a per sample basis.