Geometry Nodes

[JuanGea]

Users will also be frustrated if things are hard to understand or read.
They will also get frustrated if the nodes are too high level to provide the planned flexibility and the system don’t fit in the idea of modularity and flexibility with low level nodes, high level container nodes.

Also users will get way more frustrated when you connect things that according to their understanding should work and the don’t work, but no message, indication or anything happens, it just stays without any change.

Also users will make mistakes, because developers are unable to think about all the uses cases users will come with, it’s impossible, so a system that indicates an error is a good idea.

Based on all you mention about Attributes @Kenzie I’m starting to think that the attributed concept is too limited and a bad decision overall, it seems that it will highly limit the real flexibility of the node system, at least it seems so.

[HooglyBoogly]

@JuanGea

Also users will get way more frustrated when you connect things that according to their understanding should work and the don’t work, but no message, indication or anything happens, it just stays without any change.

Just a quick note, error messages on nodes is planned: https://developer.blender.org/T83237

[JuanGea]

Good

What do you think about the @zebus3d observation and mockup?

[Kenzie]

Attributes are absolutely not too limited as a concept for a geometry processing application. This has been literally done for decades in other software. The geometry is just a bucket of attributes each reliant on the same topology in order to make sense. You cannot separate them from the pack, they must be referenced from inside a process. The current state of the design reflects that nature.

[JuanGea]

@Kenzie

Attributes are absolutely not too limited as a concept for a geometry processing application.

That’s the thing that they are limited for geometry processing application, and as you say, it’s an old concept used for decades, if we are setting here the basis for an “everything nodes” concept with high flexibility, that concept should be as “agnostic” to the context as possible, and it seems Attributes are not that, I may be wrong, but there has been already some cases where Attributes where tied to geometry and it’s not possible to treat them outside that context.

What about particle context using attributes from geometry or viceversa?, what about volumes using geometry attributes or geometries using volume attributes? what about using other objects, or lights or entire scenes attributes? that’s what I call flexibility

Not entirely sure, but it’s what it seems to be.

[HooglyBoogly]

I think attributes are a natural extension and abstraction of vertex groups, colors, selections, etc. Of course it’s going to be frustrating for now, there is no way to transfer attributes from one geometry to another. But its really only an attribute’s connection to other data (positions, faces, edges, etc) that gives it meaning, so to break that link doesn’t make any sense to me right now.

[Kenzie]

Again, attributes are local to the geometry being worked on, they become corrupted if they are copied to another set which doesn’t match its layout. This isn’t just a limited way that other software has done it that is inconvenient to our mockups, this is a hard limitation of attaching data to geometry. Instancing and particles inheriting attributes would be a matter of barycentric interpolation (if the attribute data supported it) if you want to reproject them to another geometry set then there needs to be a controllable way to do that.

[JuanGea]

But @zebus3d AFAIK is not breaking that link AFAIK, that’s a different thing that I exposed as my understanding because of @Kenzie answer, but as I said, I may be wrong.

So far what @zebus3d did up to my understanding is to break up the big high level node into low level ones to give more flexibility and readability to the user.

[JuanGea]

Keep in mind that we may be in a situation where it’s hard to agree because we may not have a clear distinction between attributes and general variables or properties and what are the limitations and benefits of such different things are, so it will be like if I were speaking about apples and you about dogs.

A dog can bite you, and you can bite an apple, but an apple cannot bite you and better if you don’t bite a dog hehe

But this fundamental error fo understanding is something that will happen to many users, and there is a need to have such distinction clear, because when I go to a node (visual) programming interface I expect to work with variables of different types, but what I’m understanding here is that Attribute are not the same as varaibles or properties, and that’s not clear at all IMHO.

So our disagreement in how we understand all this may be in that fundamental thing.

[Kenzie]

Correct, the proposal did break up the graph to a lower lever, but into a low level form which the only flexibility gained could leave the internal state of the geometry set mutilated by faulty assumptions about the flow of data by the end user after every operation. If done in this state it would be up to the users to make sure they sanitized their graphs of topology mismatches inbetween working with attributes. The attribute management would have to be sandboxed in order to provide the user a more atomic way of working with this data without having to navigate an error prone minefield.

[HooglyBoogly]

It does break the link, because it passes around an attribute as data from a socket without the corresponding geometry.

[JuanGea]

@Kenzie

by faulty assumptions about the flow of data

Ok, but that’s what errors are there for, and also, why there was a “container” node planned, so high level users can avoid such errors, but low level users can have flexibility.

In this case black boxes are a very bad idea and it’s what @zebus3d is trying to explain.

It’s your responsibility as a user to learn how to work with low level nodes, ir if you don’t want to, you can always keep yourself into high level nodes, but that’s up to you.

Also I don’t see a problem in your modification of the mockup, I mean I will get an error in the following node, but that’s it, and as a low level nodes user is my responsibility to fix it based on what the error message tells me.

I think here is where the main concept problem lies, or at least what it’s hard to understand, why can I do that?

[JuanGea]

It’s not that a high level node cannot exists, but based on what was planned and proposed, and the flexibility aimed, that node should not be constructed as a black box hard coded node, but as a container node with those low level nodes inside of it, that’s what @zebus3d is trying to expose I think, and what I’m trying to expose, that’s what we see as an error, it’s not that such a node cannot exist, it´s that it should be made of other nodes, and you as a user should be able to reproduce the behaviour manually with nodes, which is what the @zebus3d mockup did.

Does it exposes the tree to user errors? of course, that’s the price of flexibility, but that’s also what you solve with container nodes, giving to each user type what they need:

• High level users: high level nodes
• Low level users: low level nodes

[Kenzie]

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.

[dimitar]

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.

[JuanGea]

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

[Kenzie]

@JuanGea

Can the “Attribute Compare” node be recreated with low level nodes right now?

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.

[JuanGea]

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

[AlexeyAdamitsky]

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?

[slowk1d]

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?