[Bf-cycles] Status Open Shading Language
eocean at fohr.com
Sun Jun 3 21:51:35 CEST 2012
This is an effort I will likely be able to support, specifically on Mac OS X.
+1 for your plan.
Some of the SVM nodes you mentioned could be implemented in OSL itself, rather than as new OSL closure types.
Also, the OSL/OIIO developers are very helpful, though I haven't seen many requests from the Blender/Cycles people. I would strongly recommend we take advantage of those resources.
On Jun 3, 2012, at 9:42 AM, Thomas Dinges wrote:
> Hi everyone,
> here some information about the current status of the Open Shading
> Language (OSL) backend in Cycles.
> I did some fixes in the OSL backend yesterday to bring it up to speed in
> terms of our procedural textures and I found it quite interesting.
> 1) What is OSL?
> OSL is a shading language which affected Cycles quite a lot (see things
> like Closures, Ray Visibility...) , it's one of the 2 shader backends
> The other shader backend we are using atm is SVM (Shader Virtual
> Machine) and this is running on CPU and GPU.
> OSL on the other hand is only running on the CPU, porting that to the
> GPU would be a major task and this is nothing that will happen in the
> near future.
> OSL website: http://opensource.imageworks.com/?p=osl
> Code Repository: https://github.com/imageworks/OpenShadingLanguage/
> 2) Status of OSL in Cycles
> Each shader and each node has to be implemented in both shader backends,
> SVM and OSL. The nodes which have been added over the last couple of
> months were only done for SVM, not for OSL. So a lot of Nodes need to be
> written in OSL still to have this working and on par with SVM. To name a
> few: Color Ramp, Light Fallof, Object Info Node... Also existing code
> needs to be double checked.
> 3) Benefits of OSL
> OSL code is highly optimized and large shader networks probably aare
> executed a bit faster on the CPU. Also it will be interesting when we
> will be able to write our own custom OSL shader (with some kind of OSL
> script node, where we can put in custom shader code).
> OSL was and still is one of the major pros in Cycles, I was already
> impressed when hearing about it the first time. OSL is already used in
> the industry, mainly by Sony Pictures Imageworks, who use OSL in
> combination with the Arnold Renderer for film productions. It's
> definitely a direction we should proceed, and having a OSL renderer
> available in Open Source might also attract more user and devs.
> 4) Proposal
> I realize this is not an immediate and urgent task but I want to propose
> the following integration process for OSL in Cycles:
> a) Build a stable library of OSL (OSL 1.1 at this time) for Linux (then
> Windows, Mac) which works with our other libraries.
> b) Fix possible issues and get Cycles to compile with the OSL libs.
> c) Port over remaining nodes/shaders to OSL and check existing OSL code.
> d) Write support for custom OSL shaders, by adding a OSL node or
> something similar.
> It would be good to at least have "a" and "b" done, and keep it working
> on "b" level. Any other work then can be done step by step and when
> resources are available.
> I would like to hear your opinion (especially yours Brecht) on that,
> could that work?
> I guess I can do some more work and fixes, but until now I was not able
> to build the OSL libraries myself, so it's a bit guessing if the code
> works or not.
> Best regards,
> Thomas Dinges
> Blender Developer, Artist and Musician
> Bf-cycles mailing list
> Bf-cycles at blender.org
More information about the Bf-cycles