Or about a large number of nodes in “NodeGroup” that need to be connected, I don’t know if Blender developers will solve this problem in a short period of time.
However, I see that some people in the community seem to object to “Array Nodes”, so I wonder if we should change the direction, such as modifying UI. I call it “Input Panel”, so the request for this feature is here: Input Panel — Right-Click Select (blender.community)
First of all, to solve my current problem, I’d like to discuss the possibility of using bpy scripts to arrange a large number of sockets in Group input, such as selecting 10 of the following sockets out of 100 sockets, and then quickly moving to the top.
I don’t know if other developers are working on the “connection” and “arrangement” of a large number of sockets, which is an urgent need for me. If other developers are not going to do it, I hope I can solve it myself in a simple way like BPY. I don’t like Blender source code.
However, if you want to make a “Input Panel” and add a “collapse” function like VScode to a node, it doesn’t seem that simple, because there doesn’t seem to be a “collapsible socket” API that can be used on the node.
In order to become a real Blender developer, I think I need to have a detailed understanding of the source structure of Blender in order to achieve the functions I want. I need more details about the source code or existing API. Where can I find these?
If you start doing everything at once, most likely you will get something like this
And because of this, you need to think over the design first.
If it’s something small, like a new geometry processing node, a code suggestion will suffice.
If it’s something big, like a hair system (like T95933), then you need a design.
As an example, look at the recently launched Bevel 2.0 Project T98674 .
Also, if you are a beginner programmer or you have no experience in this, I suggest starting something else first. I started learning blender code myself at the beginning of the year. And I don’t think I can do that (even though I want to)
How to solve the problem of a large number of sockets.
In addition to “Array nodes” and “input panel”, I also thought of a method of “global variables in geometric data”.
For example, in attribute fields such as grid points, lines and surfaces, storing an attribute, even if it stores only one number, still consumes a lot of memory at each point.
Adding a “global attribute field” to geometric data may make the node more concise.
If a node group has only morph modifiers, global variables are not so difficult.
But considering the problem of “splitting and merging geometric data” and the case of “global variables in the instance”
This simpler effect requires more complex code, which I think is more complex than “Array nodes”.
As a function requestor, I think senior developers should not be willing to do such a complicated task.
So I should still try to make the above-mentioned “Array nodes” function request myself.
In terms of use-case, on how to organize better the node trees, or how to work with the node tree, is a good idea.
However the real conflict occurs, on how the nodes are connected, and how the values are transferred.
By default now, as it is well known, we have connections performed as one-to-one relationship, which makes things very deterministic and explicit, you know what you want to connect and when to connect it.
On the contrary, having array-connections in terms of flow-based-programming concepts, is like creating a data structure, and use one connection as a placeholder of a batch of connections. Which the real essence of a data structure, is to consider that is a batch collection of variables.
The real problem here what I am afraid here is maintenability. There is no way of knowing if the array properties in a node change, what happens to the other end of the connection. Since there are no logic mechanisms on-top of the node tree (like having a meta-node-tree), even a simple reordering of the fields, will lead to hard crashes.
Another problem is that if two data structures are identical by more of 70% it will make it very tempting to generalize and reuse them, and turn logic trees to much more complex to understand. However this is not exactly a practical problem.
However I am interested to see if anyone has an input on this. If there is a concept of data structures in tree nodes, or how about anything similar is used in other environments, such as Unreal nodes.
So far, I don’t think the “Array nodes” and “Input Panel” I designed are the best solutions for dealing with a large number of sockets, so I hope someone will come up with better ideas here or rightclickselect.
I am not only a novice Blender source code, but also do not know C++,
I only Python, C# and other simple languages, I think I need a longer time to learn C++.
I want to first learn to use C++ to make a Geometry node, if someone wants to write code similar to “Array nodes” in advance, I can also contribute more ideas for free.
I have proposed on my own particle system study a new worflow based on “Brick imput” lije this :
Basicly you add imput from a menu in the brick, and you reduce the output → Imput socket…
Blender have too node ! For nothing… some node can be regrouped in one Node and activate or desactivate some part of them nodes.
Having python code interplay with nodes, strikes a good balance between node-tree simplicity and complex implementations. Because many implementation details can be encapsulated inside a python script, while the node tree can retain a “higher order” of organization in design terms.
Such as for example if you have some very simple node such as a sigmoid function (you might wonder why you should need it - but let’s say you do for this case). The code is so short and simple that looks great in Python. However if you try to express it in nodes, you can feel the heat, is too much of a hassle to do so many manual operations by hand, while on the contrary just typing it feels like flying.
import math
def sigmoid(x):
sig = 1 / (1 + math.exp(-x))
return sig
Though the whole point is to strike a balance between, good encapsulation of functions, and good connectivity of nodes. Rather than having god-functions or god-node-trees both of these extreme cases are either bad.
This is a actually a good use-case I can suggest, I have not though of any other examples yet. I just learnt today that Unreal Blueprints has indeed data structures, so we have to roll with this paradigm to know where it goes.
Nop basicly in particle node is all the same everywhere in blender… you pick a node and you create a chain length with a lot of nodes ! Now here is a brick system… One function > Attributs > COMPILE —> “CAN BE CNNECTED TO ANOTHER BRICKS” for create a complex simulation, Like Tyflow (3DS) simply. A lot of node, destroy the visual space in blender, is not a good point for the future… But with this sytem of “Brick” yes is it
