“Readability” in this case doesn’t mean “readability by you” - it has to be readable by other people. That’s one typical problem in development teams, where things have to make sense for everyone even remotely likely to open up a scene you created, either for debugging, or simply because you’re not there this day, or other reasons. I would argue it is of the greatest importance.
By the way any chance you mean Buf ?
I love this behavior and I think it should be taken into consideration for many nodes, if not for all of them!
I leave this mockup in which I try to solve a couple of visual problems of the nodes in general.
First the problem that appears with the nodes of many inputs, as it happens with the Principled Shader, which generates a globe.
Second when zooming out, the name of the node is difficult to read and there is no substitute icon. I think it is better not to add icons to nodes but I think it is convenient to keep the font size even if the node moves away.
I start from a screenshot of Pablo’s designs.
I think they could work both horizontally and vertically with some adaptation.
After reading some comments here I think there is a fundamental thing about Geometry Nodes that is not being understood, and I’ll relate this to the “Separate XYZ” thing.
Geometry Nodes so far is giving you/us the BASICS, the most fundamental nodes, in fact I would be happy if we would simply get a postion node, a rotation node and a scale node.
The idea behind all this is to be able to generate more high level nodes afterwards.
That Transform nodes with the float option, that can be generated with current nodes, and if could be named Advanced Transform or something like that, you should not think about these “high level nodes” as a node group like in shaders right now, you should think about them as just that, nodes to be used, so far I’m not even sure those nodes can be created, but loosing time in basic nodes with such functions that we will be asble to recreate in the future is a non-sense.
The fact here is that we need the most basic / low level nodes to be able to have those high level nodes in the future, we are not in the “hardcoded nodes” anymore, we are in the “proceduralism era” , and that means that nodes are created with nods that are created with nodes, like in other very well known procedural packages, and what we have here right now it’s just the foundations to be able to to that 
In the end artists have to be able to use high level nodes (simple ones) but you will be able to enter into those high level nodes to modify them if you need to, because they are not hardcoded, but node-coded.
Proceduralism =/= Hard Coding
To add to that, there is probably some performance gain to be had by having some functions hardcoded instead of leaving the compiler generate said code. I don’t really know if the impact is measurable though.
@wevon I like those ideas. Why not label connected sockets as well ? Maybe just on mouseover ? How do you deal with nodes with a lot sockets too ? Is there a lower limit for the node’s width ?
I also dig the constant text size, but what about complex node trees ? are they not going to overlap from a distance ? I suppose there could be a threshold view distance, from which labels could be resized
I think you have not missed anything Hadriscus, good battery of questions. 
Why not label connected sockets as well ?
->An intermediate option would be fine although it would not keep the scale of the text.
Maybe just on mouseover ?
->Too.
How do you deal with nodes with a lot sockets too ?
->With many sockets the spike can be extended horizontally and the circles can contract a bit, always maintaining a spacing between the inputs and outputs.
Is there a lower limit for the node’s width ?
->In principle no, but in any case you could start by grouping the variables of the same type by substituting circles for pills, and when hovering over it expand.
I also dig the constant text size, but what about complex node trees ? are they not going to overlap from a distance ?
->The ideal would be to substitute the text for icons, but as can be seen in the sculpture branch, icons slow down development as they require more consensus and the collaboration of third parties.
I suppose there could be a threshold view distance, from which labels could be resized
->Good option, the initials could also be left, or the nodes collide, we have to study it more.
If I see that the idea is not crazy and generally has a good acceptance, more work can be done.
This has been one of my main concerns since the beginning of the particle nodes project, however @jacqueslucke and the team have that in mind constantly, and I try to test for performance at every small step.
@jacqueslucke did an amazing job with the evaluation system AFAIK and performance is nearly similar to what it would be with a C++ hardcoded node, that’s why the idea is to have the foundations for low-level access and generate bigger nodes for high level usage
Genius, I wished ‘attr’ would be considered as matrix too
Am i the only one thinking that this is a bit of a wasted opportunity?
I agree with you very much, but I don’t think they will do that. They pay more attention to the ease of operation of the artist rather than performance. (Colors, vectors, and attributes need to be distinguished in order to be easy to read. In this case, for artists, the underlying nodes are completely unreadable.
Personally, I like the underlying node very much, because it can avoid some logical confusion, and it can also encapsulate some of its own nodes. With the bottom node, we can generate all the high-level nodes ourselves, with high flexibility and strong scalability. This is very important in an open community. At the same time I am looking forward to the script node. (Personally, I hope it is c/c+±like) I think it will be indispensable in particles and animation modules. For performance problems, it is also the optimal solution.
no.
Happy to see the first go at geometry nodes. In my experience thus far, everything makes sense. Waiting for more modifiers to make it over and for lists and list comprehensions.
Do you mean “list comprehensions” as in filtering attributes ?
What I’m saying is not a “hope”, but something they said many times, it’s the plan, and some things related have been discussed in the particle nodes thread and in Blender chat.
It’s just that the “container” node is not ready yet
Yes, the typical if/else, picking nth element, slicing/combining lists, etc.
Also I am imagining that the first go would be object-level operations only? It would be useful to know whether edit-level operations could make it or whether the system would be designed in a such a way that python addons could be introduced.
Sorcar has developed a really nice node system and not sure if it would be possible to eventually port some things over? Especially edit-level operations.
Hi guys
Is it possible to use an attribute from geometry nodes as a factor for mixing two materials?
I’m trying to join two geometry and have a different material configuration from each one, how to do that?
if we can output a vertex color that would be possible, hope we will be able to do that
Regarding the visualization of the nodes, I have improved what is exposed here and made the proposal in RightClickSeleck to get a general opinion.
There are still things to define, but it is something more concrete.
After seeing a mockup of Ton showing a cloud of nodes in 3D, I tried to give a flat solution to the complexity of the connections between nodes.
I have left the proposal in RightClickSelect, and although it seems a bit crazy, because it seems taken from a video game (Portal), I think could be a solution to simplify node trees.
Personally, at the moment, I don’t understand where this scaling and rotation parameter comes from. Seriously, can someone explain to me what kind of abstract parameter is used here?
Is this something like transforming an object? But why is it not then taken from Object Info node > Location, Rotation, Scale?
Vertex Group, I understand, they can be found in Objekst Date Properties, but it still looks not intuitive, and again you need to enter it manually or copy / paste it manually.
If I understand the nodes correctly, then I can suggest something like an Attribute Extractor from Mesh, which will extract from an object: Vertex Group, Vertex Color, Marked Edges etc. And use them in other nodes like: Point Distribution, Edge Split, Bevel etc.
I know this is not a topic for suggestions, but then it just gets lost. Sorry.
And another question, will there be analogs of modifiers inside the nodes, like Bevel, Array, Mirror etc.?
Those nodes create the attributes
