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

[Dalai Felinto]

Hi Brecht,

> • 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."

See if I got it right:

*) The user would explicitly have u,v as input parameters on the Node script.
*) This would generate an input socket automatically.
*) if nothing is plugged in, the active UV layer is passed along as UV.

I thought the globals were protected names but either way. This seems
like a good solution if that's what you had in mind.

Thanks,
Dalai

2012/10/9 Brecht Van Lommel <brechtvanlommel at pandora.be>:
> 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.
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles