[Bf-cycles] Cycles standalone and OSL

[Lukas Tönne]

Hi John,

Great to see Cycles being used outside of Blender context, really promising.

Thomas Dinges and i have been discussing the issue of OSL scripts and
parameters a while ago.

Cycles handles OSL script nodes roughly like so:

1) Internal node instance of "OSLScriptNode" type is generated, either from
Blender DNA data (regular Blender nodes) or the XML file description
    This stores a file path to the script source (in case of DNA nodes can
also use cached .oso bytecode to avoid recompiling)

2) The script node is converted into OSL shader instances using the
filepath or bytecode
    OSL input/output parameter defaults and connections are set at this
point.
    For DNA nodes it uses links and default values from the editor.
    For XML we don't have a complete equivalent system in place yet, which
is what you experienced.

The output/output_type thing is basically a placeholder at this point,
which allows only the most basic shaders to run using only default input
param values and a single output value.

The main idea for standalone Cycles to support arbitrary OSL scripts is to
make a flexible input/output XML attribute, so you can assign connections
and values to any possible parameter. This would be based purely on
parameter names, which is the main way of identifying parameters in OSL
anyway. This means you don't have to define ALL the parameters for a script
node, and you don't have to worry about non-existent parameters either. As
long as you know what sort of input/output parameters a script has this
would be perfectly fine and sufficient to get you going.

As a feature *on top of that* we might support OSL queries via Cycles. That
would be entirely optional and wouldn't have to be connected to XML or
rendering even. All it would do is parse a given shader script and return
info about the parameters and metadata, so you don't have to link OSL
yourself if you already work with Cycles.

As for closures:
Yes, you can use the full range of closures provided by OSL directly (e.g.
diffuse() ), all of these builtin functions/closures are available.
In addition to that you can also create the equivalent Cycles nodes in the
XML. Many nodes are just thin wrappers around the basic OSL closures to
define them in the Cycles universe as nodes.

If you want to import entire existing shader networks into Cycles it's
probably best to make a script node for each of them (provided the
limitations you found are sorted out).

The only thing that should be avoided in OSL scripts for Cycles is use of
the Ci global variable, which defines the final output closure. This
variable is set by the Cycles Output node and doing this in script nodes
could mess up the expected shader:
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/shaders/node_output_surface.osl

You can construct a complex closure entirely inside your own custom script,
and then only pass this out as a single parameter and connect it to the
standard Cycles output node.

Best regards,
Lukas Tönne


On Thu, Feb 13, 2014 at 9:50 AM, John Haddon <thehaddonyoof at gmail.com>wrote:

> Hi,
>
> Thanks very much for your work towards making Cycles into a standalone
> renderer. I've made a small start on an experimental exporter for it
> in Gaffer, a procedural scene assembly tool I've been working on. So
> far it's been very straightforward, and basic mesh and camera export
> seems to be working fine.
>
> https://github.com/johnhaddon/gafferCycles
>
> I'm now looking at exporting shaders and I'm hitting a few hurdles.
> Gaffer already loads OSL shaders and can build networks from them, so
> I had hoped it would be fairly straightforward to export them to
> Cycles. Unfortunately as far as I can tell, OSL shaders aren't really
> properly supported in Cycles XML. As I understand it, the problem is
> that OSLScriptNodes start out with no input or output sockets, so the
> code to transfer parameter values from the XML to the shader has
> nothing to transfer them onto. The output socket seems to be specified
> manually with the "output" and "output_type" XML attributes, but there
> is no equivalent for input sockets.
>
> Assuming that is correct, I wonder what you think is the best approach
> to fixing this? Perhaps the OSLScriptNode could be extended with a
> load_shader() method which uses OSL::OSLQuery to build the sockets
> automatically, and then the existing parameter loading code in the XML
> loader would work? Or do you think it would be best to support
> additional arbitrary XML attributes to manually describe the sockets
> using some sort of in_* in_type_* syntax? My preference would be for
> the former, but I have no real understanding of the codebase on which
> to base my opinion.
>
> >From the examples, I'm also not clear as to how full the OSL support
> is in terms of using OSL surface shaders (rather than just pattern
> generators). Am I right in thinking that the scene_osl_stripes.xml
> example file connects an OSL pattern generator into a built-in shader
> node rather than using an OSL closure to perform the final shading? If
> so, is it possible to actually use an OSL surface shader with closures
> to do the entire render? My main interest in Cycles at present is for
> the OSL support, so before I go any further it'd be great to know if
> there are any other gotchas awaiting...
>
> Thanks once again for your work on Cycles, and for any assistance you
> might be able to offer...
>
> Cheers...
> John
> _______________________________________________
> 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/20140213/25f7de05/attachment.htm