[Bf-cycles] Script node updating from OSL defaults

[Dan Eicher]

On Fri, Jan 11, 2013 at 6:08 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> On Fri, Jan 11, 2013 at 1:36 PM, Matt Ebb <matt at mke3.net> wrote:
> > If it's possible to figure out programmatically what parameters are in
> their
> > default settings and what have been modified, then upon updating a node
> type
> > definition you could leave any modified parameters as-is and update
> > parameters that were previously at the default, to the new default.
> Houdini
> > acts like this, and it works pretty well.
>
> This behavior breaks backwards compatibility though? Imagine if we did
> this for all properties in Blender, change them to the new default
> unless they have been modified. I think it would break many files. I
> don't know how you would deal with that in Houdini, maybe changing
> defaults doesn't happen much once a feature has been implemented?
>
> Brecht


When I was asking Lukas about this on the IRC I didn't know that's how the
sockets worked -- if you change the value manually and do an update it gets
reset to the new default (in my OSL comp node at least since I implemented
it to reset from the file even if the socket exists).  I was thinking that
the default value was separate from the actual value so one could do a
'reset to default' operation on them.

So, yeah, probably not what people would expect and will break node trees
unless they used another node as input.

On mine I think I'll add an optional parameter (which defaults to off) to
the update function to reset the defaults for rapid prototyping with the
intention of revisiting this issue once it's fully working.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130111/4eabd5a0/attachment.htm