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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 < >> [email protected]> >>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> [email protected] >>>>>>>> 508-274-8700 >>>>>>>> _______________________________________________ >>>>>>>> Bf-committers mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> With best regards, Sergey Sharybin >>>>>>> _______________________________________________ >>>>>>> Bf-committers mailing list >>>>>>> [email protected] >>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>> >>>>>> _______________________________________________ >>>>>> Bf-committers mailing list >>>>>> [email protected] >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> With best regards, Sergey Sharybin >>>>> _______________________________________________ >>>>> Bf-committers mailing list >>>>> [email protected] >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> [email protected] >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> >>> >>> >>> -- >>> With best regards, Sergey Sharybin >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
