Custom shapes for shading ?

[nyue]

I am an OSL newbie, I come from old-skool RSL, be gentle :-)

I am pondering pursuing some OSL extension and would like to know if the following thinking sits well with the design architecture of OSL

There are additional shapes [polyhedrons etc] plus other types (especially those containing splines) that I'd like to fill with color in a shader.

I'd like to do so as an OSL extension (so I can tinker with both OSL and OSL's SDK [c/c++])

I am thinking my code may be use this way in a shader

shader mytriangle(point p0 = point(0,0,0),point p1 = point(0,0,1),point p2 = point(0,1,1),
output color shape_color = color(0,0,0))
{
// Some color stuff
color my_creative_color = triangle_shader(p0,p1,p2);

// More color stuff
color some_other_color = ....;

shape_color = my_creative_color + some_other_color;

}

When writing the C++ code for triangle_shader, what can we expect to be given or have access to (in addition to the parameters we pass in) that may allow one to test inside/outside of a given shape ?

Are there specific docs or specific sections of docs I should target my reading ?

Kind regards

[etheory]

OSL doesn't support user extensions. You would need to write your code purely from existing OSL primitives.
One way you could do the above is to use the inbuild .csv file reader to read in the vertices, then write code to check for triangle inclusion.

But there is no way right now to add custom C++ functions, because OSL is meant to be universal, and sharable, and custom calls would break this design principle.

[nyue]

Thank you Luke.

[lgritz]

I'm afraid I'm the one who was responsible for adding "DSO shadeops" to RSL. It seemed like a good idea at the time because it solved 2 problems:

1. All of the important renderer implementations were closed source, so if you wished for an RSL function that didn't exist and couldn't be implemented in RSL itself (like reading from a file other than a texture, or communicating over a socket), you were out of luck. DSO shadeops were a back door that effectively let you do that.
2. Because DSO shadeops were implemented in C/C++, they could do some things very fast that would have been slow in the interpreted execution of the RSL shaders.

But they came with some big down-sides, too, as a consequence of the inside of a DSO shadeop being a total black box to the renderer. Two especially serious problems were:

• Shaders using DSO shadeops couldn't run on a GPU, since somewhere in the middle they were calling arbitrary x86 code from a user's DSO.
• The renderer could only call it, but had no way to reason about what it was soing, what the side effects might be, or how to optimize the innards.

Despite some very clever individual tricks we had done with DSO shadeops, 10 years later when we were designing OSL, I had long since come to the conclusion that DSO shadeops had been a tactical win but a strategic mistake, and vowed to omit them from OSL.

Recalling the two good things about DSO shadeops I mentioned earlier, I think neither of them really have merit now, for the following reasons:

1'. OSL is open source, so anyone can propose a new built-in function, ideally by implementing it themselves and submitting a PR, and thus make it part of OSL. No such mechanism existed for extending PRMan's implementation of RSL, for example. So my philosophy was: if people discover compelling missing functionality, let's just add it to the language for everyone instead of forcing them to write plugins because they couldn't modify the language.
2'. There isn't a credible performance advantage to introducing precompiled functions because OSL shaders aren't interpreted, they JIT down to machine code (and do some really clever runtime optimization).