Atm, the “Attribute Separate” node follows old behavior. It does not return Anonymous Attributes.
Some thoughts … I fear this would be some typing too
In Geometry Nodes we keep track of side effects by chaining Geometry connections. No matter what, we need to build up our node tree by chaining side effects in a reasonable order.
Anonymous Attributes give more freedom than plain Attribute Nodes. We do not need to keep track of return values. Returned Attribute values are also retun-slots of Nodes. Node flows more accurately describe whats going on.
Plain GN does mix return values of Attributes with input slots (string names) of Attribute Nodes. Within a node tree with output values we have to keep track of Attribute outputs within Node Inputs. Resulting in a node flow which keeps track of “GN side effects” in a linear way. Node tree might do formally correct steps, but on a user level I get impression like I have my nose in assembler code. I have to go through step by step to get an idea of whats going on. Instead having a node graph which reveals by itself.
I hope no one throws tomatoes at me, but for me it feels odd and counter-intuitive.
I believe, a node tree with Anonymous Attributes likely is less verbose and easier to gasp than plain GN node tree. Imo, this is a big plus. With Anonymous Attributes we would still have to deal with side effects. We have to chain side effects in a reasonable way to get desired result.
Thinking about the fields approach …
I guess, it rather resembles a functional approach. It liberates us from keeping track of side effects. Without the need to burden ourselves with side effects, we could chain fields (functions) in a flexible way. Finally we apply our field to an attribute, and perform a side effect.
yeah and is there a performance penalty of keeping all those intermediate attributes all along the tree ? or is it more costly to delete them when they’re not needed ? because if I’m not mistaken right now they live indefinitely, right ? Ideally as a user I shouldn’t have to worry about garbage collection and as I understand it the anonymous attributes proposal requires the user to explicitly “save” attributes.
Good point.
There could be large objects. Without GN I already had enough opportunities to freeze blender.
But a GN modifier which defines 10 vector attributes. That is much more data which has to be stored in the memory. How could it work for massive “monster” objects, which already claim large parts of memory for themselves?
And now, after you mentioned manual “Garbage Collection” … brrrrrh!
Maybe, Anonymous Attributes could save memory space and scale better for dense monster objects?
Perhaps fields are the most memory-friendly solution for massive monster objects.
I had the same thought today as well, while making a “map range” node with attributes as input.
Do i use the attribute delete node to clear any temporary attributes?
Should i “recycle” old attributes after they did their job instead of creating new, better named ones to save a slot? What happens if one of my temporary attributes already happens to be a in use when my node group uses/ overwrites it?
I’m a big fan of the concept behind anonymous attributes as this would make things simpler; even with the increase in complexity they might bring.
Hi all! Jacques and I have finished up a basic prototype of this proposal, the first of two prototypes. The prototype isn’t meant to be a complete implementation, and in order to get it done quicker we made some compromises, hacked a bit, and didn’t complete some of the features. But generally it should work well at giving an idea of how this would work in a more complete version.
Here is a screenshot of how selections work with this patch-- much more intuitive I think! Fabian’s extrude patch is already there as well, as an example of a mesh node that takes a selection input.
This is really amazing. I am hoping I will see an option to sample image texture soon. Right now, there’s still just the old attribute texture sample node that outputs the good old clunky geometry monolith.
I just tried, but i got stuck because the switch node seem to convert the field back to a single value, i suppose there’s quite a few nodes that don’t support the fields yet and we need to hunt for them once the proposal is accepted?
Then the problem is, how can we check if we are working with a field or a single value?
perhaps the viewer node could connect to any inputs value, so we could check the value from an input directly in the spreadsheet? so that would mean that the spreadsheet would not be exclusive for geometry but could read any values
just thinking out loud
BTW fantastic work, i never though it would be made so fast
Socket inspection can help figuring out if something is a field. Just hover over a socket that has been computed before. Afaik the switch node is the only node without a geometry socket that does not work with fields right now. All the other available math nodes should work.
Nodes that have a geometry socket but are not in Hans’ screenshot above, should work exactly like before.
Viewer node support for fields (as described in the proposal) has not been implemented yet.
I mean it’s no so hard to do something with it, noise texture is awesome by itself, can’t wait to see this in daily alpha, but what I’m really missing in attribute system is integer attribute. AN have it, SV have it, even text experimental build have it for letters order ([+10] to logic [-10] to workarounds), kind of don’t understand, why GN don’t have it for instances/points? Is it to heavy for CPU? Without it it’s hard to tell which system is better, because even current’t one would not require so many workarounds with this attribute.
Big thank you for all devs for making blender more capable every day.
There’s a few things i do not understand in this new system
How to create a attribute with random values, random float does not work well with field, it still randomize a constant value which is counter intuitive perhaps?
→ with the new index input
How to “grab” an attribute from the geometry, i did this mockup while geonode was still a proto, an attribute get would be needed for this proposal so the fields can be joined/grabbed from the geometry easily
Unless something changed, id is not integer like in animation nodes. I mean integer attribute containing list of instances in certain order which could be use as any other attribute. Just as text_id if I remember correctly from text experimental build for instances. For example when you creating mesh line, first point would be 0 second point would be one, third point would be 2 and so on. I know that we can use point separate and then make attribute math operations , but this is work around exactly because we don’t have access, to integer. Line is simple example, but it goes deeper with number of dimensions. You can see it in your spreadsheet screen to the left from rotation, but you can’t do math operations on it unless I missed something.
The attribute node is to use the values of an already existing attribute, that’s why it is in the input category. It does what you want in the second capture if I understood it correctly (i.e. “grab” the attribute from the geometry).
For the random float, you can connect an index node to the seed to get different values.
Regarding “filling an attribute” I don’t think that’s the intended workflow in this proposal. Instead, you create the field that you need and then flug it where you need it, like this:
gotcha thanks for this index tips,
it seem indeed very logical and behave like H t
about the “attribute get”:
so this input attribute node is getting an attribute from a geometry?
and how do it know from which geometry to get the info?
let say if you have two geometries with the same attribute name…
Here’s a mock up on how i expected to “get” an attribute field
Edit:
You’re right the attribute input is automatically getting an attribute field value from a geometry (main one it seem) witouth even being connected to anything
my brain is bleeding at that fact,
i don’t understand how such system can work if we work with multiple geometry in one nodetree
precising from which geometry we want our attribute from like the mockup above seem to me like a necessity