ConceptGraph nesting / reuse

[BryceBubbles]

@HungryProton we discussed ConceptGraph nesting here: #59 (comment)

Current ideas:

1. The "Generic Input" GraphNode should return the output Spatial of a ConceptGraph:

   • Multiple instances of the same ConceptGraph (saved in it's own scene even) can have different template inspector properties set. So this would allow making unique outputs from each instance, but only in a manual way.
   • This is so simple to add, so I think it's a no-brainer.

2. New GraphNode with input slots that match what the nested graph exposes to the inspector.

   • This allows exposed properties can be manipulated from within the parent graph
   • These properties can be easily re-exposed in the parent inspector.
   • Does it also need inputs that match the ConceptGraphs input nodes?
   • How would multiple outputs be handled? Just as a single node array? What if you wanted to pipe different outputs into different nodes? Perhaps we need an Array Functions node for this?
   • Idea 1 doesn't stop this being implemented as it's a separate Input node.

3. New GraphNode that can directly load a graph and will show inspector properties, inputs, and outputs that match the graph:

   • This is just a step further than idea 2.
   • It would allow for direct modularisation of graphs as they no longer have to be coupled with scene nodes.

[HungryProton]

1. Generic Input

   • Yes this should be added to the Generic Input node.
   • A new Load from Scene node could be added If the Graph is saved in another scene, that should be easy to do and it could work with any type of nodes.

2. Creating a new GraphNode for nested ConceptGraph

   • Nesting a graph that's already present in the scene should only expose its inspector properties to the graph, inputs should probably be left as the child graph responsibility.
   • Output nodes should have a name property, so the new node can display one slot per output with a different name. Or maybe use the Spatial node name directly?
   • However, some sort of node that split arrays would be nice since there's a lot of other nodes that pass around arrays but I guess this is for another issue.

3. Nesting the template file directly

   • This one just takes a file path instead of a node path
   • All inputs should be exposed on the node as well which means creating a new tag on every input nodes so the detection can be automated.
   • It would be great to organize graphs and reuse common parts in multiple places.

You're raising a lot of great points and I think I should focus on these features before anything else, let me know what you think about this plan

[BryceBubbles]

That all sounds good to me. Just not sure about the Load from scene node. Aren't child nodes inside instanced scenes handled the same as if they were in the parent scene? Like if the CG node were the root of the instanced scene, it would be the same as directly nesting that CG node right? Otherwise, do you just mean we need a way to return a named child from within an input if it's not root? Like a `Get Node` node :)

…

On Tue, 26 May 2020, 9:18 PM HungryProton, ***@***.***> wrote: 1. *Generic Input* - Yes this should be added to the Generic Input node. - A new Load from Scene node could be added If the Graph is saved in another scene, that should be easy to do and it could work with any type of nodes. 2. *Creating a new GraphNode for nested ConceptGraph* - Nesting a graph that's already present in the scene should only expose its inspector properties to the graph, inputs should probably be left as the child graph responsibility. - Output nodes should have a name property, so the new node can display one slot per output with a different name. Or maybe use the Spatial node name directly? - However, some sort of node that split arrays would be nice since there's a lot of other nodes that pass around arrays but I guess this is for another issue. 3. *Nesting the template file directly* - This one just takes a file path instead of a node path - All inputs should be exposed on the node as well which means creating a new tag on every input nodes so the detection can be automated. - It would be great to organize graphs and reuse common parts in multiple places. You're raising a lot of great points and I think I should focus on these features before anything else, let me know what you think about this plan — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA43GOYFGPVECST6FRKWV33RTOCOVANCNFSM4NJ7IJTA> .

[HungryProton]

I was thinking about a scene that would not be part of the scene tree (so the graph would have to load and instantiate it from its file path)
But sure it's also perfectly possible to bring it in the scene tree manually and treat it like any other regular node

[BryceBubbles]

Ah yup got it. That's a 4th option :)

[fire]

We're doing a Google summer of code on this for "nested nodes" and "grouping nodes" in Godot Engine.

https://discord.gg/bKpWTuV

I wish to invite anyone interested to suggest how we can do nested nodes and expand nodes, before the PR is complete.