[Bf-cycles] Improving OSL support

Brecht Van Lommel brechtvanlommel at pandora.be
Fri Mar 14 01:31:59 CET 2014


On Mar 13, 2014 11:29 PM, "Naman Gupta" <naman22forever at gmail.com> wrote:
> 1). metadata:- A possible way to do it would be to define our own keyword
say  "meta". that works like this
>    int value =  4  meta range 0 10 tip "value betwwe 0-10",
>  something of that sort. but i'm not sure if acceptable since it would
violate OSL coding standard.

This is already a metadata feature in OSL with [[ ... ]] syntax, see the
OSL specification. But we don't use the data at the moment.

> 2). as for the texture. I think OSL already supports it without having to
define another node altho that can also workout.
>      https://www.youtube.com/watch?v=V5N2rnFtSlw
>   can't really figure out what is exactly needed in this.

This is about attributes being available. Like UV coordinates or vertex
colors. In your example you didn't use those so you didn't see the problem.
The attributes are currently only available if another node requests them.

> 3). Performance improvement:- I think that's the thing we should be
focusing on. A possible way to do that would be to allow OSL to use GPU
along with CPU. it could be achieved using CUDA/OpenCL/OpenGL calls.

GPU support for OSL would be great but I don't think it's possible as a
summer of code project. It's too much work.

What I was thinking of is simpler: faster handling of ShaderData end
closures copying, faster image texture lookup, faster attribute lookup, and
just generally comparing performance with the other shading system and
finding solutions for differences in performance.

> Apart from these issues I can't really find any other feature that needs
to be added to OSL. If there is please do let me know.
> Would like to know if i'm heading right.

A few other things would be support for enums, better support for strings /
file paths, support for image datablocks, support for curve mappings and
color ramps. Better reporting of error messages and print statements in
scripts, an option to print OSL and OpenImageIO statistics, or viewport
auto update as you type. Support for shading in trace() function.

A big feature would be the ability to implement own closures in OSL, but
this is probably too complex and is more work in OSL than in Cycles.

> Oh and one thing. I was able to build Blender with OSL under Release
mode. Debug mode somehow crashes everytime.
> --Naman
> On Fri, Mar 7, 2014 at 11:50 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:
>> Hi,
>> On Fri, Mar 7, 2014 at 9:23 AM, Naman Gupta <naman22forever at gmail.com>
>> > I'm Naman, final year undergrad majoring in Computer Science studying
>> > MIET, Meerut, India.
>> > I'm interested in working for blender this summer. I'd like to work on
>> > support . What I can makeout from the idea page is that, blender
>> > have all the features of OSL. like metadata, a proper way to load tex
>> > and improved performance?
>> >
>> > These are the links I have read so far
>> >
>> >
>> >
>> >   I have successfully compiled the source code with OSL (win7,
vs2008). :D
>> >   I'd like to know who be the right guy(IRC handle?) to discuss it.
>> >   Also, are there any other material that I have to go through?
>> There's a few people on IRC that know about OSL integration, me
>> (brecht), DingTo, lukas_t and dfelinto. You can ask here on the
>> mailing list as well if you can find the right people online.
>> I think you found the most important links. The other relevant things
>> * Cycles developer docs:
>> http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles
>> * Rest of the Cycles manual.
>> * To see what people are doing with OSL now you can read the OSL forum
>> on http://blenderartists.org/
>> * http://www.openshading.com/
>> In general it helps if you are familiar with rendering algorithms as
>> you can find in e.g. the PBRT book, though it's not that much needed
>> for OSL.
>> As for the contents of the project, the general goal would be to
>> improve OSL integration to be more useful.
>> * The metadata support would to make it possible to define
>> input/output socket entirely from the metadata in the OSL shader
>> (min/max, tooltips, strings as filepaths, etc.).
>> * The texture loading problem is that Cycles will only load e.g. UV
>> maps if they are needed by the nodes. However OSL shaders have no way
>> to specify in advance that they will use such an attribute, so they
>> can only use it if some other builtin node already asked for it to be
>> loaded. I'm not sure what the best solution would be, but this should
>> be solved somehow.
>> * When using OSL performance is currently slower than when it's off,
>> ideally it would become roughly equal. Getting it equal may be aiming
>> a too high, but we can probably do better than we do now.
>> Maybe other people reading this can suggest things, or you can read
>> the blenderartists forum to find issues that users are running into
>> and think of solutions for them. The 3 things mentioned are not
>> necessarily the most important ones, just some things that I could
>> think of off the top of my head.
>> Brecht.
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20140314/832cd1b5/attachment.htm 

More information about the Bf-cycles mailing list