[Bf-committers] Why SpaceNodeEditor is a bpy_struct? Was: Why is SceneRenderLayer a bpy_struct?

Sat Aug 22 10:09:28 CEST 2015

In this particular case I need them to create a custom NodeTree that returns the appropriate tree the user wants to edit.

On Cycles there are three NodeThree types: ‘Shader’, ‘Texture’ and ‘Compositing’.
When ‘Shader’ is selected there are three shader types: ‘Object’, ‘World’ and ‘Line Style’.

Custom NodeTrees don’t seem to have this, at least not without some workaround.

1) Create as many custom NoneTrees as sources. Each NodeTree returns a single source. A NodeTree for Objects, a NodeTree for World. The main problem with that is that each NodeTree adds an icon to the header.

2) Re-use SpaceNodeEditor.shader_type to return a tree from Object or World (currently I have no use for Line Style).

3) Use an EnumProperty attached to Scene, or other, to select the source. The issue with that is that it affects all Node Editors.

I am limiting the example to Object and World sources but it’s possible an addon could add nodes to some other source (Scene, Particles, don’t know).

I know it’s a limited case scenario, external addon that wants adds NodeTrees to many places, but if there is some other way to accomplish that it would be nice to know. That would be the reason I need this.

Not trying to debate this 'ad infinitum’, just explaining and trying to understand myself the implications.

Thanks,
Francesc

On 22 Aug 2015, at 09:40, Sergey Sharybin <sergey.vfx at gmail.com> wrote:

> Interface doesn't have undo stack.
> 
> While there are cases when having custom properties in space wouldn't
> really need undo pushes, those custom properties will tart being explited
> for something which does need undo pushes.
> 
> Think instead of just adding custom properties to a space it's more
> important to understand why exactly you need them and see maybe it's
> something what is actually belong to python nodes instead.
> 
> On Sat, Aug 22, 2015 at 9:19 AM, Francesc Juhe <fjuhec at gmail.com> wrote:
> 
>> I don’t understand it completely because of my lack of knowledge about all
>> possible internal consequences.
>> 
>> Do all custom properties have undo?
>> 
>> In the case of SpaceNodeEditor, it doesn’t seem to need undo. The current
>> SpaceNodeEditor.shader_type doesn’t appear to have undo.
>> 
>> Well, it would be nice to be able to add a property that allows to do
>> things on a ‘per SpaceNodeEditor’ basis without needing to add many custom
>> NodeTrees or a property somewhere else that would affect all
>> SpaceNodeEditors.
>> 
>> Hope it’s possible someday.
>> 
>> Cheers,
>> Francesc
>> 
>> On 22 Aug 2015, at 08:48, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>> 
>>> This is important to understand a concept of what exactly ID is.
>>> 
>>> Roughly speaking, ID is an entity of scene graph which artists operates
>>> with and could be referenced from all over the place. In this regard
>> making
>>> space an ID is wrong because you never want to re-use same space from
>>> different areas of blender.
>>> 
>>> In theory it is possible to add ID properties to non-ID datablocks (for
>>> example, as it's done for sequencer strips), but adding such
>> functionality
>>> to space is quite a can of worms. For example it'll mean lifetime of that
>>> properties is unknown and undo pushes wouldn't happen for this
>> properties,
>>> making use of them rather unreliable.
>>> 
>>> On Fri, Aug 21, 2015 at 9:33 PM, Francesc Juhe <fjuhec at gmail.com> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Reading this I remembered I wanted to create my own shader types for a
>>>> custom NodeTree and found that shader type is a property of
>> SpaceNodeEditor
>>>> which is also a bpy_struct.
>>>> 
>>>> Can I propose that Space or SpaceNodeEditor are considered for a
>> promotion
>>>> to ID from bpy_struct so they can be expanded with custom properties? I
>>>> know this can be worked around by creating more custom NodeTrees but
>> it’s a
>>>> bit cumbersome.
>>>> 
>>>> Cheers,
>>>> Francesc
>>>> 
>>>> On 21 Aug 2015, at 19:17, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Not sure what's wrong with SceneRenderLayer being a struct, this
>> totally
>>>>> corresponds to what's happening in render API of Blender.
>>>>> 
>>>>> That being said, think you don't really need to extend SceneRenderLayer
>>>>> structure, but want to add some custom render passes instead. There's
>>>>> indeed no clean way to do it. Think the way to go would be to specify
>>>>> engine-specific passes via some RenderEngineType, but this wasn't
>> really
>>>>> investigated yet and needs some design proposal ad implementation.
>>>>> 
>>>>> On Fri, Aug 21, 2015 at 7:05 PM, Brian Savery <brian.savery at gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Greetings all!  I'm the developer of the RenderMan addon for blender.
>>>> Had
>>>>>> a couple questions on the api and generally was hoping to help out
>>>> where I
>>>>>> can.  But rather than dump them all in one thread figured I'd keep at
>>>> least
>>>>>> the subject lines separate.
>>>>>> 
>>>>>> Anyway so SceneRenderLayer.  Any reason that is a struct?  Reason is
>>>> that I
>>>>>> want to extend it and add our own custom pass outputs (RenderMan
>>>> supports
>>>>>> LPE outputs similar to OSL
>>>>>> 
>> https://code.google.com/p/openshadinglanguage/wiki/LightPathExpressions
>>>>>> and
>>>>>> we'd like users to be able to do more outputs).  Unfortunately
>>>>>> SceneRenderLayer is a struct and my understanding is you can't add
>>>> custom
>>>>>> properties to that?
>>>>>> 
>>>>>> The hacky solution I came up with is to keep a collection of custom
>>>> outputs
>>>>>> on the scene and correspond the outputs to each render layer by the
>>>> name.
>>>>>> Of course this has the issue that if the render layer name changes
>>>> you're
>>>>>> out of sync... But any thoughts on this would be appreciated.  Being
>>>> able
>>>>>> to extend a scene render layer seems like a good idea.
>>>>>> 
>>>>>> Thanks!
>>>>>> Brian
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> brian.savery at gmail.com
>>>>>> 508-274-8700
>>>>>> _______________________________________________
>>>>>> Bf-committers mailing list
>>>>>> Bf-committers at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> With best regards, Sergey Sharybin
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> 
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> With best regards, Sergey Sharybin
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
> 
> 
> 
> -- 
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers