galloscript
commented
5 years ago Thanks for the report, I uploaded a new version 0.3.1 with the fix, also fixed Blend node that was affected by this bug and another bug in its shader. Now It should work as expected.
Previous:
Now:
If Input1 is configured to take the format "ANY," uInputFormat.y is 1 no matter what the input format really is. Based on the way Multiply uses uInputFormat.y, it seems like it ought to be the number of channels - 1 for R, 4 for RGBA, just like uInputFormat.x. Because it remains 1 no matter what, the Multiply node will attempt to convert RGBA to RGBA, destroying the existing blue and green channels in the process and potentially wiping out the image entirely if there's no red in the red channel. Other nodes experience various issues as well; this isn't an issue with Multiply, and I first experienced it when trying to convert Max to work with ANY just like Multiply does. I've done a bunch of testing, and confirmed it is definitely this number not changing with format that causes the issue.
The input combinations (R, R) and (RGBA, R) work fine, and (R, RGBA) has its own problem that makes this one a moot point - See #8. Only the combination (RGBA, RGBA) has this issue.
Shown below is the issue as it affects Multiply. Red stays red, while blue and green disappear. Red appears to function because FF0000FF0000=FF0000FFFFFF.
Here is the same exact nodes if the conversion code is commented out. (RGBA, RGBA) now works fine, at the cost of all other combinations working right.