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

[Dalai Felinto]

Hi Brecht,

> u and v are built-in variables, parametric coordinates for the
primitive that is being shaded. They have nothing to do with UV
texture coordinate maps and should not be used for UV maps.

I think I got confused by their image.osl example:
http://www.pasteall.org/36091/c

But if as you say, u and v are not to be touched, I think it's ok to
use the "Texture Coordinate" Node as we have.

Thanks,
Dalai

2012/10/9 Dalai Felinto <dfelinto at gmail.com>:
> 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