I think that to properly do what @Orestiskon wants, we’d need loops. And we’ve already broken new ground with loops with the introduction of RayCast node, which does something along those lines.
Mismatch between the amount of items in the fields could be solved by simply falling back to some default, zero value for the entities of the shorter field when the iteration continues till the last item of the longer field. Users could then handle that by checking if the value is default/zero using some boolean math, and decide what to do in such case.
That is generating mesh topology. Iteration, lists, adding entries, … those are not the right concepts to think about for fields.
There’s a bunch of different ways this could be done, perhaps with a dedicated connect node that has some control over which vertices to connect based on a field or using loops. Personally I would not expect decisions or much discussion from the geometry nodes team on that topic right now, since it seems orthogonal to the work that is happening on fields.
Hi Brecht, I appreciate your thoughts on the matter. We see proposals and design changes come up when it becomes apparent that the system has inherit design limitations, so I’m trying to help by creating simple examples that show problems ahead of time.
In my experience, as a user there are two ways of working
See what tools you have and think of ideas to do with those tools.
Think what you want to achieve and follow the most logical path on achieving it.
The first works well for doodling things, but not so well for directing things according to a specific brief of a production.
The problem now is as the user is on the path to create something, they stumble upon limitations that are created by design, likely in order to be more user friendly. By trying to be too user friendly, oftentimes it ends up being way harder than it should.
If this kind of feedback isn’t what the dev team wants, it would be nice to let us know what kind of feedback we should provide to help them do their best work.
Feedback is fine. I don’t think it’s about limitations in the design to be more user friendly. It’s just important to get the concepts clear, and not think of fields as something they are not and can’t be for there to be a coherent design. And instead think of a different node or concept that can be added to make this user friendly.
In edit mode, we have a “select linked” option that lets us select connected mesh points. Is this planned to be implemented somehow in geometry nodes? It is an essential part of any mesh editing, procedural or not.
Hello! Forgive me if this is the wrong place to ask this, but I tried to open the “Geometry Nodes Fields doughnut by Pablo Vazquez” in both Blender 3.0 alpha and the “temp-geometry-nodes-fields (Sept 8)” but both builds show a couple of nodes as “undefined.”
There’s a build blender-3.0.0-alpha+temp-geometry-nodes-fields-prototype. 62d485e47029, build date 18/8/2021 that has the Nodes.
I could not open the file in the build, but you could recreate the tree.
The Store Named Attribute node is planned but not yet developed. I think currently we can connect it to the output node and make it a named attribute in the modifier, though this is probably not what you want. I think we need to wait for that Store Named Attribute node.
As for Attribute Capture, this node is useful for making a field to be evaluated into an anonymous attribute, use cases are like for example you have a default cube with a subsurf node. You make a selection that is based on before the subsurf, and you want to use that selection after the subdivision. Then you can use this capture node before the subsurf node，It will evaluate the selection field into an anonymous attribute so that it can get converted correctly after the topology change.
That is a very clever usage of the attribute capture. In general I do find it a confusing node and am very much missing named attributes. The fields prototype was so nice as it was a mix of the new fields nodes and the named attributes from 2.93.
Are there any plans to bring back named attributes at all?
Yes, currently there is already a way to do it, just connect fields to the group output and you can write its name in the modifier. The Store Named Attribute node is also now being developed: https://developer.blender.org/D12685
Thanks. I have already been playing with the new group output feature with cycles, which is very cool. I was referring more to a replacement for the attribute fill node, which looks to be the store named attribute node that you linked to.
Still confused as to how you will be able to get access to these stored name attributes within the same group?
I was doing really well with the Attributes version (figured it out with almost no lessons), but I am having a very difficult time with the new Fields. Can someone point me to documentation or a good tutorial?
