1. Topics
  2. OCIOv2 with OSL native support, part II

OCIOv2 with OSL native support, part II

Larry Gritz
 

Hi, Patrick. Answers inline.


On Aug 15, 2021, at 7:13 PM, Patrick Hodoul <patrick.hodoul@...> wrote:

Finally, a prototype of the OpenColorIO library can generate a complete OSL shader from any color transformation (not yet implemented for everything but very close).

Neato!

 
1.     After some tries, I finally selected the color4 and the vector4 types. These types are not by default supported by the other types (like color and vector for example) imposing me to create several helper methods.
a.     Why there are two categories of types (ex: vector vs. vector4 – or – color vs. color4)?

vector and color are built-in types for 3-vector and 3-color.

Aesthetically, I never liked having types in a shading language for vector4 (what are they for?) and color4 (it's 4 values, yes, but they shouldn't act like an array, because it's not really 4 spectral bands; conceptually it's a color and separately a float for alpha).

But my plans were thwarted by other languages (and eventually MaterialX) using these types liberally, despite my protest. Shader writers seem to like and expect them, despite my conviction that they are sloppy ideas.

We have headers that implement them in terms of structs and some operator overloading. It mostly works fine, though there are some edge cases that are awkward with them not being 1st class built-in types, and of course most OSL standard library functions don't have overloads for them.

Now I've fully relented, especially with MaterialX in the fray. It's in the plan to make built-in types to replace these cobbled-together structs. I just need to get the time to implement it all.


b.     Is there any pro or cons using vector4, color4?

In general, it should work. There may be some things that are a little awkward, but I'm not sure that you'll bump into them for what you're doing. It will be smoother and more efficient (and richer library support) when they become built-in types. For what you're doing, probably the biggest problem you'll run into is simply the need to implement overloads of some of the standard library functions.


d.     For now, the shader parameters are color types. Could the shader have in and out parameters be color4? Any pros/cons using color4 in ‘public’ interface of a shader?

I think it's fine. Underneath, a struct { color rgb; float a; } just turns into two variables: `color4 foo` just becomes (hidden) `color foo.rgb` and `float foo.a`, and OSL knows that when you talk about `foo`, it really means to do the connection or whatever with both constituent parts.


2.     There is no const keyword support. That’s clearly not problematic but I’m curious to know why.

Hmmm... Input shader and function parameters are already implicitly const, you can't write to them. Output shader and function parameters must be marked with the `output` keyword, so you know they are not const. So the only other way I can imagine const being used is to mark individual local variables, so that you can't change their value after initial assignment?

I guess the historical reason is that the two languages I wrote before, RSL and GSL, did not have a const keyword, and I don't recall any shader writers asking for it, so I just never put it in OSL, either.



3.     For types like vector, the language authorizes several accesses (i.e. val[0] or val.x). Once again, nothing problematic here but I’m curious about pros & cons. Is there any pitfalls (performance, etc.) to use one or the other?

Underneath, they are exactly the same thing, compile to the same instructions.

I originally did not put both in OSL (a language should strive to avoid having two different ways to say the same thing). The array notation is more flexible because you can reference single components (C[0] for the x), as well as iterate over components or choose a component programmatically (`C[i]`), which is hard to do with only the .x/.y/.z notation.

But in practice, other languages have .x/.y/.z, and many shader writers liked it, so I eventually added it. I guess a little non-orthogonality of notation sometimes is better than endlessly fielding "why isn't this in the language" questions.


Lastly, the OSL translation was tested using master. Which OSL version should I use to correctly highlight the OSL syntax (and backward compatibility) used by the translation result i.e., OSL_1, OS_1_11, etc.?

Current master is in-progress "1.12". There aren't really any major language syntax changes between the supported 1.11 releases and the in-progress 1.12 yet. I don't know exactly when we'll get to adding the new built-in types, if that will be 1.12 or wait until a later version.

But I can very close to promise that there won't be any non-back-compatible changes in the forseeable future. We'll add features but we won't break old OSL code. I don't think we've broken back compatibility of shader source code yet in the history of OSL.

-- lg


--
Larry Gritz
Patrick Hodoul <patrick.hodoul@...>
 

Hi OSL experts,

 

Finally, a prototype of the OpenColorIO library can generate a complete OSL shader from any color transformation (not yet implemented for everything but very close). Doing that exercise I faced several challenges on which I was able to find a solution. But I would like to have your feedback on several questions/solutions to help me improving the generated OSL code.

 

As there are many questions/comments, please keep the question number to answer so, it helps everyone to follow the discussion. If some questions need much more time, I will be at the next OSL TSC.

 

1.     After some tries, I finally selected the color4 and the vector4 types. These types are not by default supported by the other types (like color and vector for example) imposing me to create several helper methods.

a.     Why there are two categories of types (ex: vector vs. vector4 – or – color vs. color4)?

b.     Is there any pro or cons using vector4, color4?

c.     Any other known pending questions, concerns, etc. on that topic?

d.     For now, the shader parameters are color types. Could the shader have in and out parameters be color4? Any pros/cons using color4 in ‘public’ interface of a shader?

2.     There is no const keyword support. That’s clearly not problematic but I’m curious to know why.

3.     For types like vector, the language authorizes several accesses (i.e. val[0] or val.x). Once again, nothing problematic here but I’m curious about pros & cons. Is there any pitfalls (performance, etc.) to use one or the other?

 

Lastly, the OSL translation was tested using master. Which OSL version should I use to correctly highlight the OSL syntax (and backward compatibility) used by the translation result i.e., OSL_1, OS_1_11, etc.?

--
Patrick
1 - 2 of 2