Geometry Nodes

Okay, It’s not that low level nodes can’t exist. And low level nodes already exist in geometry nodes, those are the attribute math nodes. It’s that attributes cannot be separated from geometry cleanly, thus certain constraints are enforced by design. I shall try to explain it:

This is a spreadsheet that represents the incoming vertices in a geometry set (the socket called geometry)… It only contains a position attribute (vec3) and a custom integer attribute called “myAttribute1”. There are 3 vertices in this model. The constraints of the geometry set is that each column (container of attributes) there must not be any blank spaces, they are a continuous array of data attached to each point/face/etc. (THIS IS A VERY IMPORTANT CONSTRAINT WE WILL COME BACK TO LATER)


If we wanted to perform math on one of these then we would do this with an attribute math node, and we would tell the math node to perform this operation with the name of an attribute to search for as it’s input.

Let’s look at another socket’s contents…


Alright, it also has a position attribute but an “myAttribute2” attribute… But it has 4 points instead of 3, this has a different topology…

If we could seperate the attribute from the second container and add it into the contents of the first one:


That doesn’t make much sense, not only has the topology changed but the entire visual context of the geometry has changed as well with the position. We cannot default out the remaining blank space, that would be appending a new vertex along with the data… Such a splice would be unreasonable! If the topology of the geometry was identical such a copy would be possible but it rarely ever is and a data transfer should be smarter than that.

But wait, then how do we merge geometry (with a join node) without causing this issue? Well notice what happens:


We have created a new geometry set which combines the attributes from both, the interpretation of the data (what vertex attribute data is associated with) is preserved and defaulted out fields which were not occupied in order to satisfy the continuous data constraint. The resulting merge operation of vertices but not stray attributes therefore makes perfect sense and doesn’t result in a corrupted result.

Hopefully this explains why attributes are bucketed together to keep this constraint in-sync. It should not be up to the user to enforce these requirements or else risk broken geometry. And once the spreadsheet viewer becomes a thing, working with attributes will likely become second nature.

5 Likes

I work with grasshopper (rhino’s geometry nodes) and cycles materials nodes rather often. I’ve watched quite a few videos on geometry nodes, yet I find the attribute element quite abstract to wrap my head around. So far, from reading the conversation, it seems it can be:

  • a value (or a map of values)
  • a vector
  • a colour.

Examples are scale, location, size, vertex maps, etc. And they can be all mixed and matched.

I imagine most of the underlying geometry is handled by bmesh, but is an attribute most things in
obj.data (if obj=bpy.data.objects['Cube']) and some in obj
like obj.scale and obj.vertex_groups?

Could there be nodes that introduce attribute types with a dropdown menu and autocomplete. e.g.:

  • an attribute that shows value type of data items from object
  • an attribute that shows vector type of data items from object
  • an attribute that shows colour type of data items from object

It would be much easier to discover the types of attributes one may be looking for if there are lists of possibilities.

6 Likes

Ok, this kind of explains one part of the question, but I agree with @dimitar that it´s still rather complex to understand in all cases, for example, how do the “data transfer” modifier work? it’s transferring attributes from one to another based in some conditions, could that be possible?

Anyways, I’m not arguing too much about the error with using as an input another geometry, that will trigger an error because of ther reason you exposed unless there is something like the “data transfer”, the question is, can the “Attribute Compare” node be recreated with low level nodes right now?

And why is it not created with nodes inside the container nodes instead of being a hard-coded black box?

BTW @Kenzie thanks for the explanation, very informative and the concept it’s a bit more clear in my mind now :slight_smile:

3 Likes

Hopefully a design is decided upon that allows the users to create their own attribute manipulation nodes out of lower level building blocks in a safe environment. I believe the dev team is already aware of this and has acknowledged planning on it when we previously brought it up.

1 Like

Then that’s the key of all this, that what it’s being done right now is going towards the hard-coded blackbox concept, instead of following the contanier node concept, it may be just a temporary thing, but it’s what we are trying to expose here, and what we are seeing as a mistake
:slight_smile:

3 Likes

I’m learning geometry nodes and I believe there is a new concept introduced in 2.92 — active modifier state.

It broke the previous behavior where you only needed to hover over the modifier and then use hotkey to apply, duplicate or delete it. Now the hotkeys only work with selected modifier and the hover state is ignored. New change has broke a really good workflow.

Is anyone discussing it? Can anyone point me to the thread?

10 Likes

I don’t think there is a thread for this, but I totally agree with you, we lost a lot of speed without the hover functionality. @HooglyBoogly Could be considered an option in the preferences or in the properties panel to choose to have hotkeys working with active modifier or on hover?

3 Likes

I agree too, I think It was a lot faster and more functional. But, with the geometry node project need to have an active node modifier for choosing the display in the node editor. As @slowk1d said, it can be an option in the preferences.

I have a question. Are you going to carry out modeling tasks in geometry nodes or are you only going to use modifiers in this concept, because I think that if you are only going to focus on modifiers perhaps the name of modifiers nodes is more accurate. If on the contrary you are going to carry out modeling tasks, it would make more sense to use geometry nodes.

1 Like

I think we’re looking at the word ‘Attribute’ through a looking glass and it’s gotten bigger than it really is. Attributes are just named characteristics associated with Blender geometry - things we have been using for years.

Consider the vertices of a mesh. Their positions in space are just attributes of these vertices - no more, no less.

Running with @Kenzie’s spreadsheet analogy (thanks for that!), we can take three columns, merge a spanner header cell above them and write in it the label position. Position is an intrinsic vertex attribute. It is hard to think about vertices without also thinking about where they are. We don’t attach intrinsic attributes to geometry: in the geometry node world, such attributes are already built in the geometry.

We may tack on another single column and label it weight because it pleases us to associate zero-to-one weighting values with our vertices. Intrinsic? I hesitate. I can think of vertices with or without weight. On the other hand, I can reach around/behind/beyond the geometry node world, go into Blender’s property panel and assign a Vertex Group, and that vertex group comes across to the node world as an intrinsic attribute.

Soon, ditto, Vertex Colors (but not yet). We may tack on four more columns to the right of weight, and write in this spanning header the label: colorwithalpha, referring to the vertex colors that we are also pleased to associate with vertices.

We may tack on yet another column and call it Foobar - it associates True/False boolean flags with each of the vertices. What the H, E, Double-toothpicks is Foobar?

I’m a lousy programmer and tend to write non-descriptive names. Presumably I’m thinking of a boolean mask attribute to group the geometry’s vertices one way or the other. In any case, Foobar is an extrinsic attribute. It didn’t come, predefined, into the node world with geometry. I made it up on-the-fly by tacking on another column, or - in the node world - writing it into an Attribute -X- node as an attribute operand.

What is a geometry set? To continue with @Kenzie’s example, it’s pretty much the entire spreadsheet that contains these attribute columns - no more, no less. The depth of the spreadsheet - the number of rows it has - is intrinsic to the geometry set. A mesh only has so many vertices; that count directly translates to the number of rows in the spreadsheet.

That a spreadsheet page of attributes has a specific number of rows is the reason we just can’t pick up an attribute column in one spreadsheet page and put it down in a spread sheet page of another geometry set. What are you going to do about the row mismatch? That question must be addressed by whatever the ‘pick-up-and-put-down’ process is: what I called an ‘attribute transform node’ in my upstream post. That process may decide to interpolate 27 rows from one geometry set to the 1,357 rows of the other geometry set. Or maybe fill in default values instead. In any case, we just can’t pickup an attribute from one geometry set and paste it into another without some idea about what to do with the mismatch.

Some of you may have caught my ‘pretty much’ weasel words when making an analogy between a spreadsheet page and a geometry set. What am I hiding? I confess. Meshes are more than just vertices. Edges connect vertices and winding loops of edges define faces. So the geometry set is actually a workbook of spreadsheet pages. For meshes, there are vertex, edge, and face spreadsheet pages. Geonode docuentation calls these spreadsheet pages domains. So, without the weasel words, a geometry set is a workbook with a number of domains, spreadsheet pages, each that have grouped columns of attributes that directly map, row-by-row and one-to-one, to the items comprising the domain, be they vertices, edges, faces, point cloud radii, or voxel density.

As you have probably gathered, attributes reflect a particular data arrangement, or types. Foobar: a list of True/False booleans. weight: a floating point in the range [0 - 1]. position a vector of three floats. colorwithalpha a vector of four floats.

As you have probably also gathered, geometry sets also have types, reflected by the number of spreadsheet pages - domains - that they have, alternatively, the Blender object they represent. Pointcloud geometry sets don’t have edges and faces, so its workbook doesn’t have those sheets, but it does have (sampling) radius as an intrinsic - and color too, so those sheets are part of its workbook.

I feel there are two broad sources of pain with Geometry Nodes, one representational and one operational:

  1. Representational: The node tree graph is struggling to represent interrelationships among things at different scale. Attribute nodes operate on ‘spreadsheet columns’ but transformational nodes like Point Distribute reads and translate entire workbooks. Yet someone who has just fallen into this rabbit hole beholds a node tree, sees attribute nodes and transformation nodes represented more or less with the same graphics, and that gives a false sense of equivalency. How to represent interactions among attributes - columns - on the vertex spreadsheet and face spreadsheet? How vertex, edge, face domains decorate attributes is not clear yet.
  2. Operational: What I called ‘scopes’ in my last post - the region in a geometry node graph where one geometry set prevails - does not have many ways to convey geometric data to other geometry sets that need to operate on that data. Face normal attributes in a mesh geometry set may, from time to time, need to orient instanced point clouds in a distant scope - that transfer node does not exist yet. Do I open up a ‘drill-down’ graph - a node workspace within a node workspace - to construct that transfer node from math primitives? I don’t know yet.

Neither of these are well settled yet and erect brick walls. How this settles - and whether it settles sensibly or not - is a matter of concern. I strongly agree with @JuanGea that these issues have to settle in a good way, and that a rushed official release of Geometry Nodes - prematurely to make a big YouTube splash, perhaps - would probably not be a good thing.

10 Likes

I vote @grosgood as the QA for the geo nodes documentation page. :man_student:

8 Likes

Missing Object input to distribute one to many
изображение

1 Like

Also there is no group input or output in Add menu. So if I deleted one, i will lose it and force to make empty tree and copy group input from it.

Also face instance will be cool too. It allows to rotate faces instead of final geometry, that can be very complex

Not sure what you mean here…

Also face instance will be cool too. It allows to rotate faces instead of final geometry

What gives the instance it’s orientation is a rotation or normal/tangent attribute. So we could have a feature on point distribute (or another node) to get the centroid of each face along with it’s orientation so we can further work with it as points and use the point instance node again.

I have already found the way to rotate vertices and instances: adding rotation attribute.

Great summary, and yes I agree with how you’ve described attributes. Yet in other node-based apps, even though there is the option to mix and do math ops between different sets of data, it should still be easy for any user without coding background to understand how to operate nodes.

In this sense, keeping “attributes” that define values, vectors, colours, sets, etc should be kept separate, preferably with separate attribute type nodes for each with a drop-down menu that shows all the possible types of values, vectors, colours, sets, etc.

The other confusing thing about attributes in their current state is understanding when an attribute represents a single value or a list of values. It should be very clear to user for both.

2 Likes

Attributes in their current state should always represent a list of values, unless there is only one vertex or point that is.

In shading nodes it’s different, with the “Attribute” node, but shading nodes are evaluated completely differently anyway.

1 Like

Awww, gee… It’s my wont to figure things out by writing things down. If my notes, however “provisional and tentative” they may be, serve better than to just bemuse and confuse, then I’m glad — and relieved. Thank you.

Perhaps, when selecting a node, a table appears in the righthand sidebar listing attributes visible to the node and available in the underlying geometry set, giving their type and associated geometry set domain — but I’d settle for a simple drop-down menu.

Apropos of nothing here, I took a brief and illuminative romp through your youtube channel and took in your BCON2019 presentation. Being one to regard buildings rather as gadgets to keep rain off my bald spot and warmth in the room, I am very glad that their are architects who better such prosaic notions.

1 Like

I just wanted to echo this. There would be so much more possibilities even in these early stages if we got access to individual points’ locations, id’s etc :slight_smile: Just a simple “point info” node, alongside the “object info” one?

Being able to make these basic controller-driven effects without being limited to the weight proximity modifier, for example:

I imagine it would be very beneficial for the scattering workflow, too?

5 Likes

In the viewport, there’s a culling effect on the point for a smoother display! this is great
animation gif

But sadly:

  • once the point are instances this optimization is no longer here
  • it seem that user cannot control this culling effect ?

when working with extremely dense scattering, with a lot of instances, an optimal display solution is needed. Point density culling within the viewport might be a good idea

5 Likes