Here my two cents on the whole “Fields” vs “Expandable Geometry Sockets” debate and feedback on the prototypes:
Even before the prototypes, I liked the Fields approach better, mostly because I found it much easier to build a mental model of the whole concept, making it easier to predict how nodes will behave, especially in edge cases. Also the fields approach seems to encourage abstraction more, making it easier to reuse node groups in different situations.
As a test, I recreated a delaunay triangulation node group that I had lying around using fields and expandable geometry sockets.
The algorithm uses the “Convex Hull” node at its core. The principle is explained for example here: Delaunay triangulation - Wikipedia
It also uses a helper “Project to Plane” node group, which returns for a given vector the nearest point to it on a plane with a given normal going through the origin.
For comparison, here are both node groups using fields, expandable geometry sockets and normal geometry nodes.
Fields:
Delaunay Triangulation (Updated for new prototype)
Project to Plane
Expandable Geometry Sockets
Delaunay Triangulation
Project to Plane
[Same as with fields]
Normal Geometry Nodes:
Delaunay Triangulation
Project to Plane
So after trying both prototypes, I still like the fields approach better. The expandable geometry sockets setup is barely any more compact than the original one. To be fair, it would probably be more compact in a final version because the position and normal could be expanded on any geometry output and not need a “Expand Geometry” node. Also the “Attribute Fill” and “Delete Geometry” nodes would likely be combined later.
Additionally I think the whole attributes as lists concept is harder to keep in mind when building networks. I made the mistake of connecting attribute lists to inputs after geometry changes multiple times.
Also note, that the “Project to Plane” node has to be used twice in the expandable geometry sockets and normal geometry nodes setups but only once in the fields setup, because the field can be reused on different geometry. So theoretically, the “Project to Plane” would not even need to be in a node group in order to avoid node duplication. In this case it does make sense sense anyway but in general it means that fields have the potential to be more compact in some situations without the use of node groups.
Here some opinions, what I think should be included in the final version of the fields approach:
- Socket inspection should make clear in which domain a field could be evaluated.
- Using socket inspection on the field input of a node that evaluates the field, should make it clear in what domain the field is evaluated.
- Maybe even sockets that evaluate fields, such as the “Selection” input of the “Delete Geometry” node, should have a different shape. For example just a bigger circle?