Fields and Anonymous Attributes [Proposal]

[LeonardSiebeneicher]

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.

[Hadriscus]

@LeonardSiebeneicher

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.

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.

[LeonardSiebeneicher]

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.

[LGR]

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.

[LudvikKoutny]

@Hadriscus

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.

Wow, that sounds scary. I’d hope we are moving away from the terrible “fake user” workflow, not towards it

I am getting increasingly worried that Dalai’s proposal may end up chosen over this, superior one

[HooglyBoogly]

Prototype!

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.

I wouldn’t recommend opening existing files with this branch, since we didn’t spend any time working on versioning yet.

Here are the supported nodes at this point. There may be more in the future, but probably not all of the nodes for the prototype.

Example File

If you want a place to start, I’ve posted a demo file with a few simple examples like the above here: https://developer.blender.org/T89958#1201302

Download

Blender Builds - blender.org

The macOS build seems to be failing at the moment, I restarted the build

[Rusculleda]

Quick silly improvised test. Really loving it so far!!! So intuitive!!

Edit: Couldn’t help but try it a little bit more. It feels so flexible and straight forward! Great job!

[LudvikKoutny]

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.

[Aeraglyx]

Feels really good, I love it! Here’s a little test. And awesome to have a Noise Texture in GN now!

[BD3D]

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?

https://pasteall.org/blend/558975f10bc049f393809359aae788b5

This “Bug” i encountered above raise a question:

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

[jacqueslucke]

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.

[BD3D]

@jacqueslucke

Socket inspection can help figuring out if something is a field. Just hover over a socket that has been computed before

Ah indeed this new feature. this cause crashes in the file above btw

Viewer node support for fields (as described in the proposal) has not been implemented yet.

Nice to see it’s in the plan

[Joze]

I agree about it being intuitive, I love the shader workflow so I did not have to think too hard to get things to work

[genesis2303]

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.

[JskJ]

Will it be possible to have a toggle to see builtin attributes values in the spreadsheet?
right now everything is hidden from user

Perhaps attribute in the spreadsheet that are read-only and not accessible directly could have a .active = False in their GUI?

[BD3D]

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

Why there’s no fill property when creating an attribute, it seem weird to start from an empty attr

→ attribute input is doing it automatically when connected

[Rusculleda]

Not completely sure if I understand what you mean but there’s an ID property and an index input in this build.

[genesis2303]

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.

[Rusculleda]

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:

[BD3D]

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