Incorrect OSL type handling

[LewisO]

As you can see from the attachment, in which I defined a vector, and the UI panel is vector, however the input pin is float.

[ricky_otoy]

As you can see from the attachment, in which I defined a vector, and the UI panel is vector, however the input pin is float.

incorrect_type.png

Hi LewisO, as far as I know this is how it works in standalone - standalone also creates one pin which you can plug in a float input node which has XYZ.
If you want separate control pins I would suggest splitting into 3 float controls and combine as a vector afterwards.

Example:

Code: Select all

shader Example
(
    float R = 0.0,
    float G = 0.0,
    float B = 0.0,

    output color result = color(0.0, 0.0, 0.0)
)
{
    vector color_vector = vector(R, G, B);
    result = color(color_vector);
}

or

Code: Select all

shader FloatsToColor
(
    float R = 0 [[string label = "Red value", string help = "Value stored in the red channel of the output color."]],
    float G = 0 [[string label = "Green value", string help = "Value stored in the green channel of the output color."]],
    float B = 0 [[string label = "Blue value", string help = "Value stored in the blue channel of the output color."]],
    output color out = 0)
{
    out = color(R, G, B);
}

But obviously adapt to what you need.

[LewisO]

As you can see from the attachment, in which I defined a vector, and the UI panel is vector, however the input pin is float.

incorrect_type.png

Hi LewisO, as far as I know this is how it works in standalone - standalone also creates one pin which you can plug in a float input node which has XYZ.
If you want separate control pins I would suggest splitting into 3 float controls and combine as a vector afterwards.

Example:

Code: Select all

shader Example
(
    float R = 0.0,
    float G = 0.0,
    float B = 0.0,

    output color result = color(0.0, 0.0, 0.0)
)
{
    vector color_vector = vector(R, G, B);
    result = color(color_vector);
}

or

Code: Select all

shader FloatsToColor
(
    float R = 0 [[string label = "Red value", string help = "Value stored in the red channel of the output color."]],
    float G = 0 [[string label = "Green value", string help = "Value stored in the green channel of the output color."]],
    float B = 0 [[string label = "Blue value", string help = "Value stored in the blue channel of the output color."]],
    output color out = 0)
{
    out = color(R, G, B);
}

But obviously adapt to what you need.

I noticed that and imh it's fundamentally wrongly designed since day 1 in standalone, or there should at least be some fix in the plugin ports (Houdini in this case). There are two "float" for pins, one is a single float input, and the 3 floats (theoretically a vector, or color without alpha, and they should be mutually compatible nonetheless, but unfortunately not the case in Octane) which is also named "float". How can a user know what the pin really expects? and there are no existing nodes to convert color back to vector/independent 3 elements, some essential nodes are missing afaik
Also I think it's worth mentioning that the compositing AOV network nodes should have their independent builder, it's very confusing to mix all nodes together when searching for certain nodes while many of them share very similar names but not compatible to each other

[jobigoud]

There is a difference between Octane type system and OSL type system. And there is a difference between the argument type and the UI widget generated.
An OSL color is an Octane texture which is value varying over the surface of the object. A varying value can't simply be converted to a uniform one you would have to pick an arbitrary location to sample it.
The user should know what the shader expects from the UI widget generated by the argument type and/or metadata.

Check this doc: https://docs.otoy.com/osl/input%20types/