<p dir="ltr">Hi,</p>
<p dir="ltr">On Mar 13, 2014 11:29 PM, "Naman Gupta" <<a href="mailto:naman22forever@gmail.com">naman22forever@gmail.com</a>> wrote:<br>
> 1). metadata:- A possible way to do it would be to define our own keyword say "meta". that works like this <br>
> <br>
> int value = 4 meta range 0 10 tip "value betwwe 0-10",<br>
><br>
> something of that sort. but i'm not sure if acceptable since it would violate OSL coding standard. </p>
<p dir="ltr">This is already a metadata feature in OSL with [[ ... ]] syntax, see the OSL specification. But we don't use the data at the moment.</p>
<p dir="ltr">> 2). as for the texture. I think OSL already supports it without having to define another node altho that can also workout. <br>
> <a href="https://www.youtube.com/watch?v=V5N2rnFtSlw">https://www.youtube.com/watch?v=V5N2rnFtSlw</a><br>
> can't really figure out what is exactly needed in this. </p>
<p dir="ltr">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.</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> 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. <br>
> Would like to know if i'm heading right.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> Oh and one thing. I was able to build Blender with OSL under Release mode. Debug mode somehow crashes everytime. <br>
><br>
> --Naman<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Fri, Mar 7, 2014 at 11:50 PM, Brecht Van Lommel <<a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Fri, Mar 7, 2014 at 9:23 AM, Naman Gupta <<a href="mailto:naman22forever@gmail.com">naman22forever@gmail.com</a>> wrote:<br>
>> > I'm Naman, final year undergrad majoring in Computer Science studying at<br>
>> > MIET, Meerut, India.<br>
>> > I'm interested in working for blender this summer. I'd like to work on OSL<br>
>> > support . What I can makeout from the idea page is that, blender doesn't<br>
>> > have all the features of OSL. like metadata, a proper way to load tex coord?<br>
>> > and improved performance?<br>
>> ><br>
>> > These are the links I have read so far<br>
>> > <a href="http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/OSL">http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/OSL</a><br>
>> > <a href="https://raw.github.com/imageworks/OpenShadingLanguage/master/src/doc/osl-languagespec.pdf">https://raw.github.com/imageworks/OpenShadingLanguage/master/src/doc/osl-languagespec.pdf</a><br>
>> ><br>
>> > I have successfully compiled the source code with OSL (win7, vs2008). :D<br>
>> > I'd like to know who be the right guy(IRC handle?) to discuss it.<br>
>> > Also, are there any other material that I have to go through?<br>
>><br>
>> There's a few people on IRC that know about OSL integration, me<br>
>> (brecht), DingTo, lukas_t and dfelinto. You can ask here on the<br>
>> mailing list as well if you can find the right people online.<br>
>><br>
>> I think you found the most important links. The other relevant things are:<br>
>> * Cycles developer docs:<br>
>> <a href="http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles">http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles</a><br>
>> * Rest of the Cycles manual.<br>
>> * To see what people are doing with OSL now you can read the OSL forum<br>
>> on <a href="http://blenderartists.org/">http://blenderartists.org/</a><br>
>> * <a href="http://www.openshading.com/">http://www.openshading.com/</a><br>
>><br>
>> In general it helps if you are familiar with rendering algorithms as<br>
>> you can find in e.g. the PBRT book, though it's not that much needed<br>
>> for OSL.<br>
>><br>
>> As for the contents of the project, the general goal would be to<br>
>> improve OSL integration to be more useful.<br>
>><br>
>> * The metadata support would to make it possible to define<br>
>> input/output socket entirely from the metadata in the OSL shader<br>
>> (min/max, tooltips, strings as filepaths, etc.).<br>
>> * The texture loading problem is that Cycles will only load e.g. UV<br>
>> maps if they are needed by the nodes. However OSL shaders have no way<br>
>> to specify in advance that they will use such an attribute, so they<br>
>> can only use it if some other builtin node already asked for it to be<br>
>> loaded. I'm not sure what the best solution would be, but this should<br>
>> be solved somehow.<br>
>> * When using OSL performance is currently slower than when it's off,<br>
>> ideally it would become roughly equal. Getting it equal may be aiming<br>
>> a too high, but we can probably do better than we do now.<br>
>><br>
>> Maybe other people reading this can suggest things, or you can read<br>
>> the blenderartists forum to find issues that users are running into<br>
>> and think of solutions for them. The 3 things mentioned are not<br>
>> necessarily the most important ones, just some things that I could<br>
>> think of off the top of my head.<br>
>><br>
>> Brecht.<br>
>> _______________________________________________<br>
>> Bf-cycles mailing list<br>
>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles">http://lists.blender.org/mailman/listinfo/bf-cycles</a></p>