ok… so it is because of work in progress … should have read the thread
“Nodes that have a geometry socket but are not in Hans’ screenshot above, should work exactly like before.”
I love how intuitive, simple things are now, index was so needed, no more dummy workarounds, this is such a relief 
11 Likes
You can use a regular combine xyz node instead of “attribute combine xyz” and add it to the position attribute like this:
1 Like
The prototype is really fun to play with! I think this workflow is very intuitive and the fact that it’s similar to working with shader nodes is nice. Much better than what’s currently in master, I can say, even though I’ve not used geometry nodes very much. With this system, the attribute processor wouldn’t be necessary and users would be free to organize their node trees however they want without restrictions. I hope this ends up in master.
6 Likes
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?
29 Likes
the noise texture not working for the selection and needing to delete-join to emulate selection for the subdiv node were two annoyances, but overall this felt pretty good imo. Especially the “availability” of attributes in the auto complete was much better
1 Like
Now THIS is readable.
5 Likes
I’m not sure if this is what you mean by noise texture not working for selection, but make sure you up the contrast in some way, like here I do with a color ramp,or you could use a float compare node or a map range or a rgb curves node, to make sure you are getting 0’s and 1’s / true - false.
1 Like
Since quite a few nodes seem to be identical between GN node editor and shader editor, I wonder how much parity could we achieve between GN and Shader Editor. It’d be amazing if we could even reuse node groups between the two, as long as they do not contain the editor specific nodes (Geometry sockets in shader editor or BSDF sockets in GN editor).
I still can’t believe how much easier it is to use than what we got in the master. Despite being still very limited, it took me just a few minutes to create a network that adds cliffs to landscape heightmaps:
A few observations from this short test:
- We really need an ability to disable that nonsense which automatically reconnects existing node wires to next node slot when connecting a new wire over it. It’s already a big pain in the shader editor, but it’s even more damaging when trying to use geometry nodes.
- When working with complex data, the UI lags and freezes a lot, which makes sense given how much stuff needs to be calculated, but it’s still a big workflow speed bottleneck. It’d be really good if the GN node network did not get recalculated, and therefore UI not frozen, when for example just adding new nodes to the graph (or copy pasting nodes), which are not yet connected to anything. Such nodes should not have any impact on the network result, therefore it should not prompt recalculation of the result.
24 Likes
I really want to test the build for terrain creation, must to be the best
Thanks, for sharing the examples!
Note, the goal here is not to figure out if this is better than master, we know that it is. The goal is to figure out how this compares to the other proposals:
- Expandable Geometry Socket [Proposal]
- Anonymous Attributes, Attribute Sockets and Node Group Processors [Proposal]
Unfortunately, I’m still not done with the prototype for the expandable geometry socket proposal. Mainly the input/output handling is fairly tricky because it changes how the node system is evaluated quite fundamentally. Will share a build for that soon anyway, it just won’t contain everything.
21 Likes
ah well fair enough. i would have expected the conversion from float to boolean to use rounding
Updated Prototype
- Add a very basic way to visualize which input sockets are constant and which are fields
- Add a node to store a field on a geometry and output an anonymous attribute
- Rename “Attribute Fill” to “Store Persistent Attribute”
- Support selection in the point translate node
- Remove all redundant “Attribute” nodes
- Some are still in the prototype because their functionality hasn’t been replaced yet
- Update the extrude node with field inputs and selection outputs
- Support switching between two fields in the switch node
- Support fields/anonymous attribute selections in a few curve nodes
- Select by handle type node
- Set spline type node
One interesting difference between this and the geometry expander prototype is that we can use the original “Top Faces” selection even after the topology has changed, without more nodes or more interaction
Builds are here:
25 Likes
Hans, if you are still at the grindstone do you know if the expandable geometry socket prototype was successfully uploaded? I can’t find it in the builds, and it would be nice to try out over the weekend while I have time.
Yeah, it looks like the Windows build failed earlier. I triggered it again a moment ago.
3 Likes
Cheers, happy Friday
1 Like
Yes! This is so beautiful. I was really worried the old nodes would remain there, cluttering the user experience.
I know this is still a prototype, but what would go a long way would be Image Texture node, which would just take vector as a mapping input and outputting RGB and A sockets.
I am not yet sure if it’d be a better idea to have the GN version of the node, which uses Texture datablock, or the Shader Editor version, which uses Image datablock. The former would be great in that it would allow us to immediately use all the different legacy procedural textures, not just image files, but the latter would be closer to the ideal workflow, where there would be parity between GN texture nodes and Shader Editor texture nodes.
My vote tilts more towards the latter, as it would be a good direction to eventually deprecate those legacy procedurals in favor of being able to use texture node networks in places like displace modifier.
4 Likes
Remove from the add/search menu or entirely from blender ?
If the first case, it won’t break files and will lower the probability of users ranting about spending time on now obsolete nodegroups