search

vvvv / VL.StandardLibs

A collection of standard libraries for vvvv including VL.Stride, VL.Skia, VL.ImGui, msgpack.org[VL]
https://visualprogramming.net
GNU Lesser General Public License v3.0
35 stars 14 forks source link

[Stride] Adds support for `ComputeColor` / `ComputeFloat4` + 'Color' attribute pins #643

Closed azeno closed 7 months ago

azeno commented 1 year ago

PR Details

Description

One can now either add the [Color] attribute to an existing ComputeFloat4 pin, or use Stride's original ComputeColor type. Both ways lead to the same result, the pin on vvvv side is of type GPU<RGBA>.

The [Default] attribute is also supported. For example to set red as the default color, one would write [Default(1, 0, 0, 1)].

Related Issue

https://discourse.vvvv.org/t/add-feature-to-annotate-computefloat4-as-color/21591/4

Types of changes

Checklist

tebjan commented 1 year ago

The fact that the types GPU<Vector4> and GPU<RGBA> aren't assignable still bugs me a little bit. How about adding something like an interface GPU<Vector4> : IGPUFloat4 and GPU<RGBA> : IGPUFloat4 somewhere in the type hierarchy? Didn't think it thru, just wanted to drop this thought here.

The goal would be that the inputs with the color intent would have this common supertype, and would accept GPU<Vector4> and GPU<RGBA> as input. The outputs can always be concrete types.

azeno commented 1 year ago

You can't really express this. You can only say GPU<T> : IGPUFloat4 but that makes no sense. My gut feeling tells me we need some conversion links here. One needs to be able to register converters and the system will apply them as a last resort on links, like it currently does for T and GPU<T>.

As long as we don't have this we should think of a good node design to achieve this. How about a node called Convert taking GPU<TIn> and returning GPU<TOut>? That way the story might be kept simple.

joreg commented 11 months ago