You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jedypod, @nick-shaw :
While implementing the Python version, I just noticed a difference between the Pure Nuke Implementation and Nuke Blink Node for colours that are all negatives:
It has something to do with the toe node that is disabled according to shd_rolloff, the Blink Node seems to match my loose Python pot so far.
The text was updated successfully, but these errors were encountered:
Good catch @KelSolaar. It seems that when all three channels are negative, the Blink result is r=g=b=max(rgb), whereas with pure Nuke the lower two are compressed toward the max value. The latter seems the more desirable result, but the Blink one will probably be what happens with all the others. I'll investigate.
It appears that because when all three channels are negative, max(rgb) is negative, the ach_shd calculation fails because (1.0-ach)<(1.0-shd_rolloff) is false if ach is negative. Therefore instead of a passthru, the roll-off calculation is used which includes a division by shd_rolloff and thus produces an inf if shd_rolloff is zero.
At least that seems to me to be what is happening.
When bypassing the shadow roll-off calculation in Blink, the results still don't match. This turns out to be because Nuke's divide merge mode is not a simple mathematical divide. It seems to be a pass-thru if the denominator is negative.
@jedypod, @nick-shaw :
While implementing the Python version, I just noticed a difference between the Pure Nuke Implementation and Nuke Blink Node for colours that are all negatives:
It has something to do with the
toe
node that is disabled according toshd_rolloff
, the Blink Node seems to match my loose Python pot so far.The text was updated successfully, but these errors were encountered: