[Bf-cycles] Cycles standalone and OSL

[Brecht Van Lommel]

Hi,

The situation is currently that the there isn't any stable API or
complete file format, so integrating Cycles in another application is
going to be tricky right now.

About OSL parameters I agree with Lukas, I think the node inputs and
outputs could be created from the XML file / API without doing an OSL
query. This should fit what Blender does, and postponing that kind of
work is better for multithreading or lazy loading in the future.

Brecht.


On Thu, Feb 13, 2014 at 1:14 PM, Lukas Tönne <lukas.toenne at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>