Geometry Nodes

[Kenzie]

Are you talking about attributes or properties? Those are diffirent things and it seems they are getting mixed up. Properties can be linked to data blocks. Attributes are just an internal container of per-vertex/face/edge data inside the geometry set. Ironically inside the material graph they are both accessed by the attribute node but they are not the same thing.

Having a pool of properties inside the scene makes sense and we already have that through custom properties. Having a pool of attributes tied to a scene doesn’t make sense at all, it’s data local to each fragment of geometry, not global.

It seems like you are looking for a way to bring in custom properties without drivers if I am not mistaken?

[JuanGea]

I’m talking about attributes, the ones that you can generate with “Random Attribute Node”, if I used the term properties it’s a mistake, except in the case it was mentioned regarding the drivers.

However what I’m talking is about variables that are easily created and used inside a node tree, one type is scene tied, the other type is Node-Tree tied.

If they are attributes or properties, it’s not a big deal, maybe the first are properties and the second are attributes, that’s something that I’ll leave devs to decide, I would prefer to call them “variables” and that’s it

And keep in mind that the driver thing is for the scene ones, not of the tree-tied ones, what I’m looking for, the key of what I’m proposing, is to improve the variable creation and usage workflow in a procedural tree, since right now it will be a mess as soon as you have a medium sized tree

[Kenzie]

Ah, I see. The “variables” created by the Attribute Randomize isn’t node local. It becomes a permanent part of the geometry that can be accessed by attribute nodes in any downstream modifier. Ideally these “variables” will have the ability to not only be created but be deleted from geometry sets mid node graph to clean things up downstream, and with string processing nodes the names of the attributes might be generated on the fly (ex. Stored results of a operation inside a for loop each step). Further more a user could take the string node link from the attribute and give it to the geometry modifier input and allow the end user of the modifier to specify the attribute they want to use as an input. (For example creating an attribute to color modifier). If you want to better organize the hard coded attribute names in the tree you can create a couple of string value nodes and link it up to the appropriate inputs. (Similarly to how we already organize shared colors, vectors and values in our graphs)

(Edit: Without saying it, I believe I know of what software you are talking about that uses the pre-defined pool of attributes, and the reason it does that is due to the performance cost of creating these containers at runtime to keep it’s performance realtime. Blender isn’t limited by this and can dynamically create these containers if that is the case.)

[JuanGea]

@Kenzie

Ideally these “variables” will have the ability to not only be created but be deleted from geometry sets mid node graph to clean things up downstream

Having this as an option is great, but also a problem, imagine yoiu have 150 nodes, and you want to change one variable out of 35 you’ve created, you will have to scout and look for that node where the variable was created, that’s the bad workflow I mean.

Maybe when an attribute is created by a node it can be added to the list, and you have the option to add them manually and access them with the corresponding node later.

Precisely, since we don’t have that limitation, may be a good idea to mix the best of both worlds, having a place where you are conscious of all the variables you’ve created it’s a good thing I think, and if you are able to manage it, create them, delete them, better then

(Now that I think, maybe a filter in the new spreadsheet may do the trick for this too.)

[BD3D]

Just tried the last build!
it’s nice to see that the attr now automatically get transferred to the vertex group of the same name,superb move! I hope that vertex-colors will also be supported too

Btw, I still didn’t get how vertex-groups could influence the particles scale for example. anyone find it?

Also, the new collection instance is amazing, but i hope that sampling random instances from a collection option will still be available. variation of different instances model from a same particle system scattering is extremely important

[Kenzie]

@JuanGea

Having this as an option is great, but also a problem, imagine yoiu have 150 nodes, and you want to change one variable out of 35 you’ve created, you will have to scout and look for that node where the variable was created, that’s the bad workflow I mean.

It seems to me that this is an issue of poor graph management on the user’s part. Every node editor has had to solve this issue of readability at scale, users will inevitably get lost in their work if they aren’t careful to keep notes. If the node graph is properly grouped, framed, commented, and cleaned up then finding the area where an operation occurs or an attribute’s life-cycle takes place shouldn’t be much of a problem. If they do step away from the project and end up getting lost (this is from experience) usually the best way is to quickly scan and make your way through the graph again and re-trace your steps with preview nodes and the spreadsheet.

(Now that I think, maybe a filter in the new spreadsheet may do the trick for this too.)

The spreadsheet is for inspecting the geometry sets, not the node graph. Filtering should be used to inspect values resulting from the geometry of a selected node. If an attribute is short lived before deleted or reused in multiple contexts then the spreadsheet isn’t going to be much help as it should only show the results of an active node.

Maybe when an attribute is created by a node it can be added to the list, and you have the option to add them manually and access them with the corresponding node later.

Maybe a good idea for the node wrangler or another addon? Might be difficult as the names of the attibutes might not always be explicitly defined by the user in the case of runtime concatenated or formatted strings.

[JuanGea]

@Kenzie

It seems to me that this is an issue of poor graph management on the user’s part. Every node editor has had to solve this issue of readability at scale, users will inevitably get lost in their work if they aren’t careful to keep notes.

I disagree with this, yes the node tree must be properly organised, but that does not disable the benefit of having a list of created variables.
Even if the tree is organised you will have to navigate to the variable, then navigate to the next one, then to the next one, instead of just accessing them from the variable list.

@Kenzie

The spreadsheet is for inspecting the geometry sets, not the node graph.

Well, you yourself said that the attributes are part of the geometry, so it may be possible to have a variable/attribute inspection mode.
Now in the case you refer, that’s a situation that would have to be solved, but it’s not something that will always happen.

@Kenzie

Maybe a good idea for the node wrangler or another addon?

I don’t think such a fundamental part of the inspection tool of the node tree has to be covered by an addon, plus that may slow down the tree I suspect.

Are you against the idea of having a list of attributes / variables created in the tree?

I don’t mean removing anything from what is there already, but adding this option to the N panel.

[Kenzie]

@JuanGea

Even if the tree is organised you will have to navigate to the variable, then navigate to the next one, then to the next one, instead of just accessing them from the variable list.

As I said the variable might not always be explicitly defined upfront, in this case you won’t be able to just hand tweak these attributes, a single attribute node could be responsible for the creation and modification of countless attributes. I know it sounds messy but it is very much a thing I have encountered out in the wild. Providing a useful,comprehensive, accurate and understandable tool to keep track of the edit history of dynamically created attributes is much more complicated than it sounds and it is hard to explain how.

Are you against the idea of having a list of attributes / variables created in the tree?

If someone could come up with a concept of how to tackle the most issues needed then I am totally for it. Maybe a good source of inspiration would to look at some code debuggers and see if any of them tackle keeping track of dynamically changing data over their lifetime.

I don’t think such a fundamental part of the inspection tool of the node tree has to be covered by an addon, plus that may slow down the tree I suspect.

Shouldn’t be any worse than exporting a million polygon model to an ASCII format with Python… It doesn’t have to be running constantly, you could just hit a button and statically analyze a graph’s hard coded attribute names, return some insight and let the user quickly jump to points in the graph. (again, might be too difficult for dynamically created attributes). The freer development cycle of an addon (even official ones) would allow for more experimentation and easy contribution to create the right tool we need.

[JuanGea]

@Kenzie

Shouldn’t be any worse than exporting a million polygon model to an ASCII format with Python

You know that´s kind of awful and practically useless in production just because the time lost in that action right? hehe

@Kenzie

As I said the variable might not always be explicitly defined upfront, in this case you won’t be able to just hand tweak these attributes

No need to keep track of their ongoing change, just the initial value or the final value, as it’s done in other packages, and it works very well

In some situations, if there is no dynamic “setter”, you may be able to change the initial value and that would be the same as the final value, if there is a change down the road you will be able to see/change the initial value and the see the final value, but not change it.

There is no need to track all the intermediate changes, initial/final as much.

I still don’t think it’s so complicated, specially because there are plenty of examples out there

I’m against the addon option, just because all this is being created right now, and if things can be done right and with options from the beginning, the better, relying in addons is not the best idea, we are at the begining of something important, and you may think about this just for geometry, I’m looking at this as something that will be extrapolable and useful in the future, for particle nodes, function nodes, and many other node based options, not just for geometry nodes, but the foundations are being set now, what is not done now, will be something hard to do the in the future, no matter if it’s possible to do it with an addon.

A good example is the exporter for an external render engine, it can be done as an addon, but it’s pretty hard to achieve Cycles performance, because it has to go through loops of python and there are a ton of things that cannot be parallel, or that simply Blender don’t allow to access through Python, or the API falls short, or many other problems, if the foundations for this tool can be set here and now, the better, it can be a basic functionality as I said, and then, that functionality can be expanded, through patches or through addons, but the functionality has to be there to be expanded, and if it’s C++ it will have a good performance, if it’s python… performance in semi-complex node trees will be not good I’m afraid.

[Eary]

Currently if you connect the input value to a scalar value, it will stay scalar even if you reconnect it to a vector value (like the screenshot below), I believe it would make more sense to either have the input type be a setting in the N panel, or have the socket automatically changes the type as it reconnect to another node. What do you guys think?

[ManuelGrad]

The mechanism that the socket type of input or ouput is automatically matched to the type its connecting to for the first time is a nice gimmick. But that’s about it. It shouldnt be the only way to set the type. One should be able to layout inputs/ouputs of a nodegroup or modifier without connecting dummy nodes to it just to get the right type of socket.

As far as i know the developers are aware of that, its just a matter finding time to implement it. The fact that we can already define the socket types in one way (with abusing a gimmick feature) will justify putting this feature request to the bottom of the todo list though.

[grosgood]

As @BD3D notes, there are now mappings between attributes and vertex groups

abbot is painted by a Random Attribute node

costello is a hand-weight-painted blob

abbot - costello

The node tree

This mapping has the nice side effect of turning the vertex group list into a listing of attributes. Also, the contents of attributes are now less opaque; I can inspect them as a vertex group - if I had the foresight to set up the mapping.

Maybe when an attribute is created by a node it can be added to the list, and you have the option to
add them manually and access them with the corresponding node later.

Unfortunately, this side effect doesn’t address this, because I had to manually assure the mapping by creating the vertex groups and making sure their names were spelled the same way as the attributes. That is subject to spelling errors; I can still name an attribute in the node tree, and if there isn’t an identically named vertex group, I don’t get to see what the attribute ‘looks like’. If I’m in a hurry, I could easily miss the mis-naming.

I share @JuanGea 's cautionary that this is the time to get the node-based workflow right. This mapping is nice but it is not complete and maybe, perhaps, a little haphazard? And it is a terrible thing when haphazardness becomes ingrained.

[Hadriscus]

I see this as a consequence of trying to tie new systems to old ones. But somehow it all has to stay compatible right ? As of now, the vertex groups panel in object data lists some attributes, but not all. I don’t think this is ideal either… but maybe this is just a first step. Let’s see.

[BD3D]

As @BD3D notes, there are now mappings between attributes and vertex groups

Could be so cool to also interact with vertex colors (if the attr is made of vector color)

@grosgood

I don’t get to see what the attribute ‘looks like’

There will be an attr viewer

https://developer.blender.org/D8637

[PatBoy]

@BD3D

, the new collection instance is amazing, but i hope that sampling random instances from a collection option will still be available. variation of different instances model from a same particle system scattering is extremely important

I also hope that this feature will not be forgotten, a simple toggle could do the job.

Randomly scatter different assets from a collection is a MUST

As @BD3D notes, there are now mappings between attributes and vertex groups

now automatically get transferred to the vertex group of the same name,superb move! I hope that vertex-colors will also be supported too

Indeed would be cool to see vertex colors also supported, I believe there’s currently no non-destructuve bridges possible between the two type of data

[grosgood]

@BD3D

There will be an attr viewer

Yes. Thank you for the link. I’m catching up on the various GeoNode design and task docs now.

@Hadriscus

I don’t think this is ideal either… but maybe this is just a first step. Let’s see.

I gather Agile iterations are being tried in this project, so I’m telling myself not to worry too much about sky-blue attribute sink nodes where there appear to be no corresponding sources - ditto for the orange object nodes. There is a certain amount of play and idea testing going on. In the long run, though, I would wish not to see hacks get baked in. So from time to time I may post a ‘Whut?!?’ if the play seems to be getting too close to an edge. Please don’t be too alarmed about that.

@BD3D

it’s nice to see that the attr now automatically get transferred to the vertex group of the same name,superb move! I hope that vertex-colors will also be supported too

I agree. I have the impression that vertex colors will be supported. Still catching up on reading…

I’m sure many are aware of this, but one may access the attribute data via the vertex group weights array of the evaluated object.

>>> aob  = C.active_object
>>> dg   = C.evaluated_depsgraph_get()
>>> eaob = aob.evaluated_get(dg)
>>> eaob.vertex_groups['abbot'].weight(1697)
0.9000945091247559
>>> eaob.vertex_groups['costello'].weight(1697)
0.8882108926773071
>>> eaob.vertex_groups['ADDAC'].weight(1697)
1.788305401802063

As noted, buyer beware re: clamping within [0…1]

@BD3D

Here is an example that illustrates the problem of attr going beyond 0-1 limitation. is see devs talking about that in the chat.

Also, in real life, one should wrap weight() calls in a try: ... except RuntimeError: as vertex groups are not guaranteed to have entries for every vertex.

>>> eaob.vertex_groups['costello'].weight(158)
Traceback (most recent call last):
  File "<blender_console>", line 1, in <module>
RuntimeError: Error: Vertex not in group

Have fun, everyone.

[BD3D]

As noted, buyer beware re: clamping within [0…1]

Thus the need of a clamping solution

side notes:

Also, in real life, one should wrap weight() calls in a try: … except RuntimeError: as vertex groups are not guaranteed to have entries for every vertex.

IMO every vert should have default weight.
It would also be nice to batch set vertex-group weights, we are forced to loops over each vertex to assign weight which seem a bit absurd… if a dev is reading, merging this patch https://developer.blender.org/D6227 or something similar would help a lot of bpy users.

[PatBoy]

Hello, i have a few remarks for the devs @HooglyBoogly @dfelinto

Short version:

1) Mixing rotation together with euler is a bit awkward
2) why don’t the points herit from their emitter attr?

Long version:

1. Mixing Rotations, Currently impossible?

   right now mixing rotations together with euler is a bit akward ?
   here’s an example of problem, when trying to create a local orientation set up, but this problem is recurrent when mixing rotations in general.

   • Add a scatter nodal system
   • track your particles orientation with the emitter object, then you’ll obtain a local orientation set up
   • now try to mix this with a XYZ rotation randomization… seem impossible witouth quaternions right?
     
     

2. Get geometry normals ?

   Right now the particle node don’t support along normal scattering ? I hope it will be added really soon, it seem like a basic feature right? (not sure if already possible)

   This problem could be easily resolved if it was possible to transfer emitter attr to point cloud attr when scattering.
   Then have a default normal attr for geometries and here we go, problem closed… more on emitter to points attr transfer in 3

   

3. Transfer emitter attr to points attr
   not sure if mentioned before but, why the emitter attr disapear after the Distribute node? each scattered points should retain their emitter attr after scattering!

   The points are distributed on the emitter surface, so i don’t see why the points couldn’t recieve attr from their emitter… each points should get the attr from their interpolated vertices attr depending on the area they were scattered. It is a logic behavior. Is it on a task somewhere? Sorry if i it is already

   

[mumfinallywearenoone]

btw why there is no voxel remesh node? this would be extremely useful when creating procedural organic model.
sometimes boolean union does not give very good result especially when dealing with fine detailed organic mesh.

[Hadriscus]

I don’t think this would be part of the first iteration (focus on scattering for set dressing)