<div dir="ltr">A fix for this issue is now in master. Please see the commit message for explanation:<div><a href="https://developer.blender.org/rBd59f53f7b7dac5eff66fcf182f2cdc7dfabd6f87">https://developer.blender.org/rBd59f53f7b7dac5eff66fcf182f2cdc7dfabd6f87</a><br>
</div><div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Lukas</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 4:03 PM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The situation is currently that the there isn't any stable API or<br>
complete file format, so integrating Cycles in another application is<br>
going to be tricky right now.<br>
<br>
About OSL parameters I agree with Lukas, I think the node inputs and<br>
outputs could be created from the XML file / API without doing an OSL<br>
query. This should fit what Blender does, and postponing that kind of<br>
work is better for multithreading or lazy loading in the future.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brecht.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Feb 13, 2014 at 1:14 PM, Lukas Tönne <<a href="mailto:lukas.toenne@gmail.com">lukas.toenne@gmail.com</a>> wrote:<br>
> Hi John,<br>
><br>
> Great to see Cycles being used outside of Blender context, really promising.<br>
><br>
> Thomas Dinges and i have been discussing the issue of OSL scripts and<br>
> parameters a while ago.<br>
><br>
> Cycles handles OSL script nodes roughly like so:<br>
><br>
> 1) Internal node instance of "OSLScriptNode" type is generated, either from<br>
> Blender DNA data (regular Blender nodes) or the XML file description<br>
> This stores a file path to the script source (in case of DNA nodes can<br>
> also use cached .oso bytecode to avoid recompiling)<br>
><br>
> 2) The script node is converted into OSL shader instances using the filepath<br>
> or bytecode<br>
> OSL input/output parameter defaults and connections are set at this<br>
> point.<br>
> For DNA nodes it uses links and default values from the editor.<br>
> For XML we don't have a complete equivalent system in place yet, which<br>
> is what you experienced.<br>
><br>
> The output/output_type thing is basically a placeholder at this point, which<br>
> allows only the most basic shaders to run using only default input param<br>
> values and a single output value.<br>
><br>
> The main idea for standalone Cycles to support arbitrary OSL scripts is to<br>
> make a flexible input/output XML attribute, so you can assign connections<br>
> and values to any possible parameter. This would be based purely on<br>
> parameter names, which is the main way of identifying parameters in OSL<br>
> anyway. This means you don't have to define ALL the parameters for a script<br>
> node, and you don't have to worry about non-existent parameters either. As<br>
> long as you know what sort of input/output parameters a script has this<br>
> would be perfectly fine and sufficient to get you going.<br>
><br>
> As a feature *on top of that* we might support OSL queries via Cycles. That<br>
> would be entirely optional and wouldn't have to be connected to XML or<br>
> rendering even. All it would do is parse a given shader script and return<br>
> info about the parameters and metadata, so you don't have to link OSL<br>
> yourself if you already work with Cycles.<br>
><br>
> As for closures:<br>
> Yes, you can use the full range of closures provided by OSL directly (e.g.<br>
> diffuse() ), all of these builtin functions/closures are available.<br>
> In addition to that you can also create the equivalent Cycles nodes in the<br>
> XML. Many nodes are just thin wrappers around the basic OSL closures to<br>
> define them in the Cycles universe as nodes.<br>
><br>
> If you want to import entire existing shader networks into Cycles it's<br>
> probably best to make a script node for each of them (provided the<br>
> limitations you found are sorted out).<br>
><br>
> The only thing that should be avoided in OSL scripts for Cycles is use of<br>
> the Ci global variable, which defines the final output closure. This<br>
> variable is set by the Cycles Output node and doing this in script nodes<br>
> could mess up the expected shader:<br>
> <a href="https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/shaders/node_output_surface.osl" target="_blank">https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/shaders/node_output_surface.osl</a><br>
><br>
> You can construct a complex closure entirely inside your own custom script,<br>
> and then only pass this out as a single parameter and connect it to the<br>
> standard Cycles output node.<br>
><br>
> Best regards,<br>
> Lukas Tönne<br>
><br>
><br>
> On Thu, Feb 13, 2014 at 9:50 AM, John Haddon <<a href="mailto:thehaddonyoof@gmail.com">thehaddonyoof@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Thanks very much for your work towards making Cycles into a standalone<br>
>> renderer. I've made a small start on an experimental exporter for it<br>
>> in Gaffer, a procedural scene assembly tool I've been working on. So<br>
>> far it's been very straightforward, and basic mesh and camera export<br>
>> seems to be working fine.<br>
>><br>
>> <a href="https://github.com/johnhaddon/gafferCycles" target="_blank">https://github.com/johnhaddon/gafferCycles</a><br>
>><br>
>> I'm now looking at exporting shaders and I'm hitting a few hurdles.<br>
>> Gaffer already loads OSL shaders and can build networks from them, so<br>
>> I had hoped it would be fairly straightforward to export them to<br>
>> Cycles. Unfortunately as far as I can tell, OSL shaders aren't really<br>
>> properly supported in Cycles XML. As I understand it, the problem is<br>
>> that OSLScriptNodes start out with no input or output sockets, so the<br>
>> code to transfer parameter values from the XML to the shader has<br>
>> nothing to transfer them onto. The output socket seems to be specified<br>
>> manually with the "output" and "output_type" XML attributes, but there<br>
>> is no equivalent for input sockets.<br>
>><br>
>> Assuming that is correct, I wonder what you think is the best approach<br>
>> to fixing this? Perhaps the OSLScriptNode could be extended with a<br>
>> load_shader() method which uses OSL::OSLQuery to build the sockets<br>
>> automatically, and then the existing parameter loading code in the XML<br>
>> loader would work? Or do you think it would be best to support<br>
>> additional arbitrary XML attributes to manually describe the sockets<br>
>> using some sort of in_* in_type_* syntax? My preference would be for<br>
>> the former, but I have no real understanding of the codebase on which<br>
>> to base my opinion.<br>
>><br>
>> >From the examples, I'm also not clear as to how full the OSL support<br>
>> is in terms of using OSL surface shaders (rather than just pattern<br>
>> generators). Am I right in thinking that the scene_osl_stripes.xml<br>
>> example file connects an OSL pattern generator into a built-in shader<br>
>> node rather than using an OSL closure to perform the final shading? If<br>
>> so, is it possible to actually use an OSL surface shader with closures<br>
>> to do the entire render? My main interest in Cycles at present is for<br>
>> the OSL support, so before I go any further it'd be great to know if<br>
>> there are any other gotchas awaiting...<br>
>><br>
>> Thanks once again for your work on Cycles, and for any assistance you<br>
>> might be able to offer...<br>
>><br>
>> Cheers...<br>
>> John<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" target="_blank">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" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><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" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br></div>