Page MenuHome

Improve Cycles OSL nodes interface
Needs Triage, NormalPublicDESIGN


I have found that the interface of the OSL nodes has certain limitations. I think some of them could have a relatively easy solution. For example, change how vectors are displayed in the node. This simple change will improve the appearance of the larger nodes. Another aspect to improve is the interface for image files. Using a 'string' field allow to introducing typographical errors by the user. I think a PointerProperty to bpy.types.Image would be more convenient.
I hope these proposals make sense.

Main task list:

  • Add code to processing the parameter metadata if exist.
  • Define the correct node socket for a boolean case.
  • Expand the code to processing the boolean socket value.

Sub tasks:

  • Add the properly metadata for booleans and maybe also for labels, into the OSL shaders included with Cycles.

Revisions and Commits

Event Timeline

I think the first step to improve how some options are drawn in the interface is to add a suitable definition for each option within the OSL code.
For example, for Booleans.

int zup = 0 [[ string widget = "checkBox", string label = "Z-Up", int connectable = 0 ]],

Without this definition, it is quite difficult to deduce when an option is a Boolean or an integer.

Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Design".Wed, Jul 21, 3:25 PM
  • Vector input: it's unclear how that relates to OSL metadata. With horizontal X/Y/Z values there is not enough space in typical node sizes, and it's unclear how this is different for OSL than any other type of node.
  • Image datablocks: these have more information than just a filepath string. The image may be packed, dynamically generated, and have additional parameters such as frame number or layer/pass. How that would map to OSL parameters (or not) would need to be defined. It also relates to this discussion:
  • Boolean input: this is the easiest one, just needs minor changes to handle boolean sockets as integers in the Cycles/Eevee code

Thanks for your tips, Brecht.
Vector input: the idea is save vertical space in the node, but yes, in the 'normal' node sizes the horizontal space maybe is not enough. But the user can extend the node size easily.
Image datablock: currently I use the typicall 'template_ID' image file interface for my nodes, that is not perfect but is very clossely to the used in the Blender texture node.

After some testing, I have verified that the definition of each property added in the .osl file is processed and added in metadata format inside the .oso file

shader node_ies_light(int use_mapping = 0 [[ string label="Use Mapping", string widget="checkBox" ]],

This generates the following metadata:

param int use_mapping 0 %meta{string,label,"Use Mapping"} %meta{string,widget,"checkBox"}  %read{2,2} %write{2147483647,-1}

The next step is to add the property definition in some cases like booleans or image files.
Later, we can advise users to do the same when using their own OSL code.

I have created a first patch for review by the Blender developers.

@Brecht Van Lommel (brecht) I applied all the required changes and I added the blender_shader.cpp part that I think is necessary modify.