…so one doesn’t necessarily need a ColorIn or ColorMap .
@tonfilm proposed in the chat to also try the Color attribute with ComputeFloat4, unfortunately this doesn’t work. The other suggestion was to use compose ComputeColor instead but this results in an IComputeNode input pin.
@lecloneur and me have been porting shaders to stride. In contrast to the standard effects we decided to make the Color inputs of type compute. This allows to do some stuff that otherwise isn’t possible. On the other hand the patching workflow can be “bumpy” when you only want to input a simple colors but always have to add a ColorIn.
So dear devvvvs could you please add this feature :) Or if it is possible for an external party to add it, point me in the right direction, so I can try and make a pull request?
the only reason these inputs are still Color and not compute is exactly the lack of better support for choosing colors. we talked about it when working on the shaders and came to the conclusion we’ll not have a quick solution for this so left those inputs non-compute for the time being. but agreed, this feature is desired.
While the TFX concept started in 2011 the oldest shader we found (using the wayback machine) and ported to VL is dated back to 2008, this library somehow represent 15 years of work done by more than 45 different vvvv contributors.
A little effort on your side would be greatly appreciated to make the TextureFX 3.0 community project a real game changer for VL.
The only thing that would be great is assigning GPU<Vector4> outputs to GPU<RGBA> inputs (and the other way around) since they are the same in the shader. But I guess this won’t be possible because .NET doesn’t let you do that. So I’d add simple conversion nodes (ColToV4, V4ToCol) in both directions so that this would be possible in the patch if needed.