[Bf-cycles] osl node

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Oct 29 13:48:28 CET 2012


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. 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).

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.

If you agree I'd like to change this still. 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.


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.

Brecht.

On Mon, Oct 29, 2012 at 10:32 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
> Hi Brecht,
>
> Have you defined your osl plans for this week? As far as feature goes
> I think the main problem now is to handle metadatas and create buttons
> (instead of only sockets).
>
> With help from Lukas I started giving some thoughts on that, but I'm
> not happy with the current direction I'm heading to (and basically I'm
> fighting too much with what may be PropertyGroup limitations). Maybe
> it's worth waiting for pynodes to land in trunk for that. Would like
> to hear your thoughts on it.
>
> The idea so far is/was to parse the metadata info, and create buttons
> when necessary (e.g. when UItype == enum or texture we don't want an
> input socket, but a button instead). And of course, to support UImin,
> UImax, label, ...
>
> The NodeShaderScript already supports IDProperty and this would be the
> best place to store the buttons/other params data. But we need a way
> to store a generic bpy.prop in a bpy.types.PropertyGroup to be defined
> later (i.e. so we can create the prop itself once we parse the
> individual buttons.
>
> This (non committed) patch should illustrate this better (see the
> NodeButtonItem class declaration)
> http://www.pasteall.org/36697/diff
>
> Thanks,
> Dalai
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles


More information about the Bf-cycles mailing list