[Bf-cycles] UV, not working well in OSL Script node

[Brecht Van Lommel]

Well actually it's not a really difficult issue in principle, more a
question of how to implement it best in Cycles. I'm thinking:

* Add all shader parameters from the OSL script node to its requested
attributes.
* It's not needed to specify if it's a uv layer, vertex color or
whatever, just the name is enough (like the Attribute node).
* Object/mesh gets attributes on sync if they are available.
* We delay compiling the shader until the object requests it, and
compile it with extra Attribute nodes for available attributes.
* The compiled shader can still be reused by other objects if they
have the same available attributes (check this with MD5 hash of
attribute names).

That's the theory at least, the delayed compiling is probably the most
difficult bit since there's some assumptions that the number of
shaders is known in advance. It's basically option 2) still, just
getting the name from the parameter name itself.

I do wonder still if from a user point of view you actually want it to
use the parameter name rather than metadata. If you're writing an OSL
shader specifically for a material then it makes sense, but if you're
writing a generic reusable node (e.g. a custom Mix node) then it's not
really what you want.

Brecht.

On Tue, Oct 9, 2012 at 1:04 PM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> Just remembered how Renderman does this and found a similar note in
> the OSL specification:
>
> "4.2.4 How shader parameters get their values
> ..
> • If the parameter matches the name and type of a per-primitive,
> per-face, or per-vertex primitive variable on the particular piece of
> geometry being shaded, the parameter’s value will be computed by
> interpolating the primitive variable for each position that must be
> shaded."
>
> So basically it's the parameter name that automatically makes it get
> the attribute. Now I'm not sure if/how they implemented that in
> practice, because unlike RSL the parameter is not marked varying, and
> so only when we have the actual object can we know which parameters
> are constants. So that means you either miss out on performance
> optimizations (constant folding, ..), or compile multiple shaders or
> the common denominator for all objects. Will ask on osl-dev about
> this.
>
> Brecht.
>
> On Tue, Oct 9, 2012 at 9:17 AM, Lukas Tönne <lukas.toenne at gmail.com> wrote:
>> Had a little discussion with Dalai about how to make sure such shaders
>> are still portable to non-cycles renderers. Apart from the brute-force
>> solution (always request UV in the OSL script node), we came up with
>> two options:
>>
>> 1) Use a generic "Vector" input, like other nodes. This has the
>> advantage of being flexible, but is not as simple as using u/v globals
>> directly.
>>
>> 2) Use shader metadata to encode cycles attribute requests:
>>
>> surface
>> example_shader_1
>>     [[ string attributes = "UV,SomeCustomAttribute" ]]
>> (
>>     output closure color fora = 0
>> )
>> {
>>     fora = color(u, v, 1.0) * emission();
>> }
>>
>> Still this second approach would only work when actually writing the
>> node *for cycles*. Using a shader from other render engines which
>> doesn't have this request feature/limitation would still not work
>> without manual fixing ...
>>
>> Maybe it should be added as an option on user level: Simple checkbox
>> list in advanced options (sidebar) to enable UV and other requests.
>> Not very elegant though.