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

Francesc Juhe fjuhec at gmail.com
Sat Aug 22 12:09:57 CEST 2015


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



More information about the Bf-committers mailing list