Eyeon Talk:Script/Reference/Applications/Fuse/Classes/ColorMatrix
From VFXPedia
The help topics for RotR through RotateWeighted are missing. I need to figure out how to rotate a color matrix, but I don't know what the arguments are. Along those lines, is there any built in help for fuses that might provide some hints? Ah, ok, so RotR et al take a degree input rotation, but adding additional arguments I don't quite understand. Rotate seems to want 3 inputs for the axis vector? And one for the rotation in degrees. Ok, I might be able to figure this out. -Chad 10:22, 20 October 2009 (EDT)
I'm getting funny results from RotR and RotG. They rotate in the wrong direction. Is that a southern hemisphere thing? RotB rotates as expected. --Chad 16:34, 13 November 2009 (EST)
- It depends on what direction you consider all the axes, as to whether it's wrong or not. If you imagine an RGB cube in 3-space, where black is at 0,0,0 and white is at 1,1,1 but where R=1 is to the right of R=0, G=1 is above G=0 and B=1 is behind B=0 (like the 3D histogram shows if you put black at the bottom/left/front), then the rotations are quite normal (at least consistent). That is, if you consider positive B as moving away from the viewer, then the rotations are correct. If you consider positive B as moving closer to the viewer (much like positive Z in Fusion's 3D environment), then the rotations around R and G would seem wrong. So, looking at the front of the RGB cube, +R is right, +G is up. Looking at the top of the cube, +R is right, +B is up. Looking at the right side of the cube, +B is right, +G is up. Looking at it that way, +rotation is always anti-clockwise (or counter-clockwise if you prefer to call it that) --Stuart 16:05, 17 November 2009 (EST)
- Ok, just making sure that the behaviour was expected. I was trying to make rotations like Fusion does the in the 3D space, where positive rotation moves the "jack tip" away from the previous axis, so X rotates "away" from Y, Y away from Z, Z away from X. Just changing my code so that the rotation amount for RotR and RotG was negative makes it work just fine, so I'm not worried, I just wanted to verify if this was/wasn't going to change in the future because it isn't/is expected. Your explanation makes sense, but yes, it's just a matter of what someone intuitively expect to happen. I'll be sure to add a tip when the docs for those are published. --Chad 10:45, 18 November 2009 (EST)
- Not sure if "expected" is the correct way to describe it. The fuse class and its functions are directly exposed versions of the internal C++ class. That class was originally written about 8 years ago (it's not something new just for fuses), and is used by various tools. Although the rotation behaviour is wrong given the right-hand rule (its behaviour might be considered a left-hand rule of sorts, since one axis, B, is flipped), its behaviour is expected in that the various tools that use it, are written to expect that behaviour. Its behaviour might change sometime in the distant future, but it's pretty unlikely. --Stuart 01:47, 19 November 2009 (EST)
- I meant "expected" in that it matches the SDK, yes. I probably could have searched for it, but didn't. I mostly wanted to know if it would change, but also thought it was worth mentioning for the docs. --Chad 11:54, 20 November 2009 (EST)
- Not sure if "expected" is the correct way to describe it. The fuse class and its functions are directly exposed versions of the internal C++ class. That class was originally written about 8 years ago (it's not something new just for fuses), and is used by various tools. Although the rotation behaviour is wrong given the right-hand rule (its behaviour might be considered a left-hand rule of sorts, since one axis, B, is flipped), its behaviour is expected in that the various tools that use it, are written to expect that behaviour. Its behaviour might change sometime in the distant future, but it's pretty unlikely. --Stuart 01:47, 19 November 2009 (EST)
- Ok, just making sure that the behaviour was expected. I was trying to make rotations like Fusion does the in the 3D space, where positive rotation moves the "jack tip" away from the previous axis, so X rotates "away" from Y, Y away from Z, Z away from X. Just changing my code so that the rotation amount for RotR and RotG was negative makes it work just fine, so I'm not worried, I just wanted to verify if this was/wasn't going to change in the future because it isn't/is expected. Your explanation makes sense, but yes, it's just a matter of what someone intuitively expect to happen. I'll be sure to add a tip when the docs for those are published. --Chad 10:45, 18 November 2009 (EST)
