This is the same fix that the GammaOperation uses.
Two alternative solutions:
- Clamp r, g and b to make sure they are >= 0.
- Check r * gain + lift > 0.0f instead of just r > 0.0f.
I'm not sure which solution is best.
Differential D6696
Fix T68076: Color Correction node generates NaN Authored by Jacques Lucke (JacquesLucke) on Jan 28 2020, 11:42 AM.
Details This is the same fix that the GammaOperation uses. Two alternative solutions:
I'm not sure which solution is best.
Diff Detail
Event TimelineComment Actions If it's any help, Cycles has a safe_powf function in util_math.h. Maybe this could be used Blender side too. ccl_device float compatible_powf(float x, float y)
{
#ifdef __KERNEL_GPU__
if (y == 0.0f) /* x^0 -> 1, including 0^0 */
return 1.0f;
/* GPU pow doesn't accept negative x, do manual checks here */
if (x < 0.0f) {
if (fmodf(-y, 2.0f) == 0.0f)
return powf(-x, y);
else
return -powf(-x, y);
}
else if (x == 0.0f)
return 0.0f;
#endif
return powf(x, y);
}
ccl_device float safe_powf(float a, float b)
{
if (UNLIKELY(a < 0.0f && b != float_to_int(b)))
return 0.0f;
return compatible_powf(a, b);
}Comment Actions @Charlie Jolly (charlie) thanks for the info. Not sure if that is necessary here. Allowing powf(negative_number, integer) in the context of the color correction node does not seem to be correct. Comment Actions I'm not sure what the best solution is. Using this operation on negative values doesn't make much sense to me, so leaving them untouched entirely seems reasonable. |