[Bf-cycles] Cycles standalone and OSL

[Lukas Tönne]

A fix for this issue is now in master. Please see the commit message for
explanation:
https://developer.blender.org/rBd59f53f7b7dac5eff66fcf182f2cdc7dfabd6f87

This does not include OSL query support yet and the way input/output
declaration is separate from input value specification is a bit awkward,
but at least this should make OSL shaders fully functional with Cycles
standalone.

Cheers,
Lukas


On Thu, Feb 13, 2014 at 4:03 PM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> 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
> >
> _______________________________________________
> 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/20140224/53a71cc4/attachment.htm