Geometry Nodes

Note that UI is only superficial change and do not matter that much compared to workflow

for example, it’s not like they would do a hard turn on the whole attribute workflow right before the release right? oh wait :sleeping:

You cannot separate fields from attributes that way.
Fields are just like machines, ready to be fed with attributes. What fields produce also get stored into attributes.

Think about fields as attribute processors.

A Field is not bound to a specific geometry. You can run the same field on any geometry which does have attributes needed by the field. This makes fields a powerful tool which could be shared and reused.

The debate is mostly about how attributes could be accessed or stored.
Having single Get/Set nodes for attributes or having many different Get/Set nodes.

Hey Folks

About the removal of create/get/set typed attribute node,
currently replaced by entries in the geonode-modifier interface in 3.0 alpha


We just had a talk with Dalai in the blender chat.

It seems that this decision is mainly done to guarantee systematic share-ability of nodegroups.
This design is explained by an insistence on the fact that data-block should be always re-usable.
In 2.93, for example, it was possible to create nodegroups that were not shareable, the status quo is that this is an important problem to be resolved, and create/get/set named attribute nodes are problematic from this point-of-view, thus explaining the removal.

This subject will be addressed officially tomorrow soon in a new topic (with a poll it seems),
in the meanwhile, Dalai would like to know what kind of limitation this system is creating, if some of you have examples it would be welcome.

10 Likes

A simple test with compact dashed line
Screenshot_2

9 Likes

Much better. Not only the dashes, but the green geometry line. I wonder if there could be such an option to choose any length of dashes in an overlay panel.

2 Likes

I understand that ‘geometry’ data and ‘fields’ data are different types of data, but I’m still confused as to why it’s necessary to conspicuously display it between every connected node via noodle dashes.

I’d rather my attention be drawn to a noodle when I connect two incompatible nodes together – like in the shader editor – and not between two nodes that are working as intended.

I feel that changing the noodle’s appearance in this case is like looking for a solution without a problem. I think the diamond shaped input and output indicators work just fine. What do we gain by adding an additional indicator to the noodle? What inconvenience is alleviated? The only answer I’ve been given is that they’re two types of data. My question is, “So what?”

11 Likes

The fields are a concept that I think will take a bit for people to wrap their mind around.

If I understand everything correctly, the fields aren’t transferring any value. They’re transferring an instruction, they’re more like a string of an expression.
The target node is actually getting and executing that instruction to create the value, and it’s important to know that, since that will determine the state of that attribute.

It’s good that the field lines are unique to the eye so we can follow the field flow properly, and the fact that they are dashed also communicates that the value isn’t travelling there, it’s only a message to get the value.

6 Likes

Ah, the fact that dashes are used makes more sense all of the sudden.

They definitely need to be easier to focus on and more continuous though. I like some of the mockups here with higher frequency dashes.

I understand the meaning of the dashes and I think on some level they’ve given me an intuitive feeling for which parts I can reuse. Personally not bothered by the style of them.

Want to say that I’ve absolutely loved working with fields. I can’t imagine having made this nodegroup in 2.93, typing out attributes all the time.

Still hoping for a way to set curve primitives Twist Method to Z-Up :slight_smile: I don’t know how else I’ll control the tilt when I add an option for “flat” strands.

28 Likes

Nice 3d scan you did :wink:

Veeery nice. Can you post a screenshot of the whole node tree?
It’s not even necessary to be able to read the text on the nodes (so noone steals your intellectual property, in case this is a problem for you in this case). I just want to get an impression of how the node setup looks and feels.

1 Like

Well I have to say I never was one for organising my nodes well, so I don’t know if this is any reflection on the state of things :sweat_smile:

The red frame isn’t used / may replace the stuff underneath it when we can set Tilt. There are only a couple of nodegroups.


And the parameters. Would be nice if the boolean output was a checkbox and not a 0-1 spinner.
image

8 Likes

Very nice (and rather clean nonetheless).

Now image you want to output several “fields” you used to control the look of your baskets for shading. E.g. you want to use the thickness to control the roughness and the twist to control the bump intensity:

You’d have to pull cables all across the node tree to plug them into the Group Output node to name them and make the attributes available to a shader network which will not make the tree any more readable or less confusing. The earlier (i.e. the more to the left) in the tree you define these fields, the further you would have to pull this connection.
Alternatively you could duplicate the Group Output node, move it closer to where it is needed and in the end use CTRL+H to hide all the other inputs to avoid making the tree unreadable again (because by default the Group Outputs show all connections)

Wouldn’t it be much nicer if there was a “Set Attribute” node? It has only a single input and can be placed anywhere. You could set the name, type and attribute domain and voila it’s accessible in shading (and anywhere else in the GN tree, can be saved to Alembic or USD etc.)
Its name will of course show up in the modifier interface just like now. So you never lose sight of all attributes that are output.

I also see there are a lot of cables coming from the Group Input, going across half of the tree to where they are actually used. Now imagine a “Get Attribute” node very similar to the “Set Attribute” node, that is even simpler: It only has a name input, the rest (type and attribute domain) are already defined in the Group Input.
These could also be placed right where they’re needed avoiding cables going across other cables and nodes).

All of the currently available workflows don’t need to be changed or removed. These two node would only be an addition and noone would be forced to use them.

P.S.: All the names don’t need to be typed in by hand but are of course accessible by a list / search that pops up once you click into the name fields. This would be even better than in Houdini :wink:

4 Likes

Hey I have discovered a bug with the Prim Objects in Geo Nodes Fields with the bridge Attribute to ShaderNodes. Is this a bug or a missing Feature?
https://developer.blender.org/T92044

If there was Get Attribute I don’t know if I’d have used it. If I use an attribute late in the process, I have no idea how I’ll easily find where I defined and modified it. I haven’t come from other software so I’m kind of OK working within whatever limits there are.

The only thing I didn’t like about long noodles is that they disappear when your view isn’t near the start or end point. But routing a long noodle around the outside using a couple of reroutes, I would have no issue doing. I did the duplicate group input thing also which was OK, except if I want to see how an input is being used, I have to find all of the group inputs first.

It just looks to me like you skipped the step of assigning a material to the grid.

By the way: In another node-based 3D software there is the option to show “dependency links” kind of like an optional overlay. You can set it to “hide”, “for selected nodes” and “for all nodes” which helps a lot to never get lost while at the same time not permanently cluttering the node trees with wires.

1 Like

Ohhh lol. How stupid. Sorry :rofl:

Well I do wonder if new geometry should default to the first material on the object, since that’s what we’re used to in other instances.

Lovely woven baskets. I’d love to see you fiddle the input properties a bit, if you find the time to record a little demo.

1 Like