Simplify nodes

* @testure * They would both have individual ID's in the blend data. Something like:

mycustomnode.output[0] or mycustomnode.output[1]

If that's what you mean?

Or if you mean how would you differentiate when assigning, then take a closer look at the pop up menu in the 'after' image. It lists in order, all downstream nodes, and then if that node has multiple outputs, then a second level would pop up where each output would be ordered and named (just the same if you were looking at output sockets).

* @testure * it's similar to how houdini passes attributes and groups along it's node tree's (but a bit more intuitive)

* @3d illusions * It just means that if you want to get something from the first node in a tree, you don't need to make a seperate wire to it, because all the ouputs for all nodes in that branch would persist all the way to the end of the branch. Some value getting used/modified along the way, some just passing through.

* @3d illusions * forgive me if this is naive because I have only used Houdini a few times- but I was under the impression that houdini didn't pass anything from node to node. Each node is a new evaulation based on the previous state (similar to Substance Designer). The 'attributes' aren't passed, they are written to the mesh at that specific point, and wrangled at a future state. The nodes just control logic flow. I don't see the parallel for how this would work in Blender's node editor, where each node evaluates the incoming data (not the state) and outputs a result.

* @testure * Yes the values are stored in as point,vert,prim or detail. But what I'm trying to get across is all data from downstream nodes is readily available to all upstream nodes in that branch without the need for lots of wires.

* @testure * I'm obviously not explaining this very well, so here's an image of the concept in Houdini.

Take a look at the tree, I have two group nodes in one branch. Now take a look at the last node of the branch's info window. You'll see that both the groups are available to the last node.

And if you take a look at the top right, you'll notice the dropdown box for the blast node properties. Both of the groups are available to be selected here without the need to wire each group directly into the blast node individually.....they just pass through the tree. The only time I would need to wire multiple versions into a node further down the tree would be if I'd modified the value of group 1 for example, and wanted to use the modified version and the original version of group 1 in another node. In this case I'd wire the original group directly to the new node, and get the modified version of group 1 from the original wire that's passed through the entire branch. Even in this case, the blast node would only have one input, a merge node would be used to join both branches into one before plugging into the blast node.

This should make it easier to understand:

3d-illusions.co.uk/crap/houdini%20example.jpg

In Blender we'd need the blast node to have two input sockets called group 1 and group 2, which results in messy wiring, but also restricts how many inputs can be accepted. In the houdini example above, I could plug in unlimited group nodes downsteam, and I could connect them all to the same blast node (the group dropdown in the top right can have unlimited comma seperated groups). Imagine how useful that would be for an rgb mix node, or an alpha over node....you could layer any number of images with one input (providing they're downstream and in the same branch).

* @3d illusions * Right, I guess that's my point- Houdini can get away with all of that because it's done on the CPU and has access to everything at any given point in time. In Blender almost all nodes are handled on the GPU to take advantage of superior multiprocessing. On the GPU there's no concept of taking information at arbitrary points in the stream, you take specific input data, process it, and then output the result.

That's what makes GPU processing so fast- you have a lot of cores able to make a lot of assumptions without caring too much about what else is going on. A GPU-based process has no concept of the 'overall state' like Houdini has, which is why I'm not seeing how something like this could be implemented without redesigning it (and taking a significant performance hit in the process). Overall I get what you're suggesting, and agree with the spirit of the proposal- but it's not as simple as that.

* @testure * I think you're misunderstanding what i'm suggesting here.

Under the hood, everything would work identically. The data would be in the same place, and the nodes would process the data in the same way. The only difference is how the connections between nodes are created and represented in the user interface.

The only difference under the hood that I can think of, is that each node would need to store a list of the other node's id's that are downstream in the same branch (to populate the choose node menu shown in my image).

On a side note, many of the nodes are handled by the GPU with open cl in Houdini too.

* @3d illusions * the links would still all be stored in bpy.context.scene.node_tree.links , so the user could easily switch between the existing wire mode and my suggested simplified mode.

Me personally, once I've set up the connections, I'm usually only bothered about seeing an overview of the data flow, and generally know exactly what's happening by looking at that. Constrastingly, a huge jungle of wires make it near impossible to see whats flowing where.

* @momotron2000 * wouldn't really have the same outcome.

* @3d illusions * true I reread the post again sorreh my dear friend