[Bf-cycles] osl node

[Brecht Van Lommel]

Hi,

We discussed this on IRC, for me still it's important to never modify
blender data without a user action in blender. I think a reasonable
solution is:

* For internal: not really any problem here, we could perhaps have an
option to recompile bytecode stored in node automatically as you type,
but manual compile button is ok.
* For external: cycles on rendering will use the latest version of the
file on disk. However to add new sockets/options to the UI, the user
still needs to press an "Update UI" button on the node, and we can
communicate this when the node is outdated. For writing shaders this
will still work nicely, as the UI does not need to be updated to work
with the latest version.

Regarding the check_oso stuff, we agree this is only a temporary
solution, and that we really should be passing the .oso data directly
to OSL. However until the library is updated to support this, we can
dump this to disk in a temporary folder on render.

Brecht.

On Mon, Oct 29, 2012 at 6:12 PM, Dalai Felinto <dfelinto at gmail.com> wrote:
> 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
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles