Your opinion on TextureFX Color inputs (poll)

wip
1

Hello,

@lecloneur (and me) have been working on porting a multitute of TextureFX to vvvv gamma / Stride. (Quite a journey so far with some “detours”). I’ll make a more detailed post once we release the stuff.

For now I want to ask you for your opinion on an “issue”:

We decided to use ComputeFloat4 as type for color inputs ( as opposed to “normal” Float4 annotated with [Color]). This allows to do some stuff that isn’t currently possible with the “standad” shaders that come with VL.Stride – there you can only input a single color while with the compute input it is possible to input a ColorMap.
Stupid example:

image
image1016×1254 108 KB

The drawback is everytime one wants to input just a single color a ColorIn node is needed which makes patching a bit less inconvenient.
image

To alleviate this the devvvvs have been asked to add a feature to be able to annotate ComputeFloat4 with [Color] too, so one can directly connect a color IOBox.
From their answer I gathered that this won’t happen any time soon.*

Now we have to decide if we keep ComputeFloat4 with the characteristics outlined above or go back to “normal” color inputs for now.

What would you prefer? Please take a few seconds and answer the following poll (or if you have some thoughts on this reply in this thread):

Thanks.

* Actually there is a bit of “conflicting” info here. While @joreg said (emphasis mine):

@tonfilm said in the chat (also emphasis mine):

1 Like
2

Something worth mentioning is if Color are of type ComputeFloat4 some “never been done before with TFX” stuff will be possible :

image
image1125×1276 128 KB

Any TFX can be used to directly mix textures which allow lots of interesting things to happen.

The drawback as mentioned by @bjoern is that an extra node is necessary when a simple Color input is needed and obviously this is very often the case. It feels very tedious when you want to patch TFX in a very fluid manner as it adds constantly more clicks and nodes searching in the process.

We are in between this two. But again, this could be solved by the devs god hands on stride’s source.

3

You could make 2 nodes, one each signature. The one that has a color input does the color in behind the scenes Could make them generic then?
But, does this same issue also exist with other forms of source like colored and grayscale textures? Hmm, a lot of duplication there potentially

4

We ported more than 200 shader files to the TFX3.0. While this is a solution indeed I’d prefer if we don’t go that route.

Nah Mean ! Ahah :

image
image2338×1729 241 KB

2 Likes
5

No doubt, haha! Another way to alter only the 200+ nodes would be making helper node/operation that has a typeswitch inside under each pin with that directing the traffic that way.
So back to @bjoern’s question. I don’t understand @tonfilm’s answer well enough to speculate if its a good work around or not, so if I had to pick I’d go with <GpuFloat4> because this is an edge case. Is the 'color node’s only job is to convert things from GPUShader values to Textures?

6

You can create them as ComputeFloat4 which is the right shader type, and add the Color attribute for possible future improvements and to mark this pin as color.

for now, you would need a ColorIn to connect a color IOBox and get the sRGB to linear conversion and a Vector4 box would work now as direct input.

If you want to look into the code somewhere here:

and here: