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

Francesc Juhe fjuhec at gmail.com
Sat Aug 22 18:15:19 CEST 2015 

Node Editor uses NodeTree.get_from_context() to get the node tree.

snode_set_context could call NodeTree.get_tree_enum_types() to populate the Enum that is to be used later in get_from_context to get the correct NodeTree. I believe it could work.

I think I will give it a try :D

Thanks, talking to you have helped a lot.

Cheers,
Francesc

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

> This is indeed better approach than having custom properties in a space.
> Helps keeping track on internal consistency and such.
> 
> It's still needs some work tho, because node editor needs to know where to
> get node tree from, but this issue already exists and needs to be addressed
> in one way or another.
> 
> On Sat, Aug 22, 2015 at 12:09 PM, Francesc Juhe <fjuhec at gmail.com> wrote:
> 
>> Hi again,
>> 
>> Sorry to be annoying but I have been thinking on another approach that
>> does not involve turning Spaces to ID or adding custom properties.
>> 
>> What if the NodeTree itself had a classmethod that returned a Enum like
>> list of items to be used to select the source type? Depending on how it’s
>> implemented it could even be used on internal Shader and Texture NodeTrees
>> too and replace SpaceNodeEditor shader_type and texture_type with a single
>> Enum property usable by all NodeTrees, internal or custom.
>> 
>> Does this make any sense?
>> 
>> Cheers,
>> 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
>> 
>> _______________________________________________
>> 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

More information about the Bf-committers mailing list