[Bf-cycles] osl node

[Dalai Felinto]

Hi,

> For me still the update mechanism isn't working the way it should.
> Currently it will auto compile nodes on file load, which in my opinion
> it should never do. We discussed this at blender conference, my
> understanding was that the conclusion was that this should be done
> either manually or auto update when working in the text editor.

You mean auto-update the text inside Text Editor, auto-update the .oso, or both?
With .oso the live-update we have for python ui scripts is not
convenient/useful at all imo.
That's why I thought auto-update would only make sense for external files.

> Doing this without any user action will lead to unintentional changes and
> possible loss of data, since sockets can get add/removed and links
> disconnected, and there's no good user feedback when that happens (and
> a user who wants to change something else in a .blend file shouldn't
> have to worry about it).

> We can give some indication in the node / text editor UI when things are out of sync,
> and have an auto update option for the text editor, but further I'd
> like to keep this compile something that is always controlled by the
> user, even if there are some cases where auto compile would
> convenient.

I don't see the big down-side/potential problem here. If the new .oso
fails to compile we are not replacing the node. If the new .oso is
valid and we changed something, only then things change in the file. I
fail to see how this would happen by chance. That said, I agree that
you want auto-update only once in awhile. So maybe it shouldn't be
hidden in the side menu of the node editor.

So +1 to communicate better that the node is out-of-sync.

What if the auto-update is be per-session. So every time you re-open a
file, if you want to do osl editing you click the node to auto-update,
which is re-set to False when you close it. That has the downside of
not allowing you to edit a .oso from a linked in file, but that is
blender-fine (as in, not fine, but consistent with the rest of
blender).

(also, the auto-update as it is now probably can be implemented later
as an "Auto-Update External OSL" addon, so I think any solution is
fine for me)

> Further the check_oso stuff in scene update, we can write those
> temporary to file until we can load the bytecode directly, but this
> should be done on render, and to some temporary directory.

I thought so, but in cycles you can be continuously rendering during
the whole section. Thus I thought 'load time' may be more fit. If
someone decides to clean up the .oso folder while the file is open I
think it's ok if things crash. But checking if the .oso are around is
cheap, so anyway is fine.

Also I: the folder with the .oso should be different than the current one imho
Also II: I kind of gave up on patching osl to support .oso stream
myself, but feel free to go for it.

> If you agree I'd like to change this still.

Feel free to change anything. I'm more concerned about the user
experience than the technical decisions we take to get there.

> As for the UI buttons for things that are not sockets, I'm not sure
> what the best way to do this is. I don't think RNA / bpy.props is
> going to work well here, they work on the level of data types and not
> a specific instance of a data type. Any node in a node group or
> material is just a specific instance of a shader script node, it's not
> a new data type. I think regular ID properties would be more suited
> here, though they don't support enums.

Thanks,
Dalai