Geometry Nodes

I do have to say I am very concerned that it seems like the only way to do complex per point math in geometry nodes is to use a ton of attribute mix/math nodes and create temporary attributes for something as simple as the result of a single math operation… This seems like it really won’t scale well to real world formulas and likely create a massive mess of both the node graph and a mesh’s attributes.

So before this thing becomes too unweildy some sort of per-point/face/voxel sandboxed scripting solution be it code or function nodes based needs to come in ASAP.

7 Likes

do have to say I am very concerned that it seems like the only way to do complex per point math in geometry nodes is to use a ton of attribute mix/math nodes and create temporary attributes for something as simple as the result of a single math operation… This seems like it really won’t scale well to real world formulas and likely create a massive mess of both the node graph and a mesh’s attributes.

That’s because they don’t let us detach the attr from their geo and do op like proposed below

1 Like

I feel like it needs to be more isolated than that proposal. You really can’t really detach attribute arrays from a geometry container and use it elsewhere without having the exact same topology or some way to reinterpret locality. For loops in the geometry nodes level feel like they should work on mesh parts not over individual attributes. The “itterator” should also be opaque as ideally the data should be able to be operated upon in parallel rather than serially (like how shaders work).

So maybe some sort of attribute node that encapsulates a subgraph (there is already a design in progress for a data blockless graph organization) that is designed similar to the user as working with material nodes (except inputting and outputting attributes rather than shader enclosures) might be a good solution that feels right at home. Might be especially convenient to people who have participated and built things during nodevember.

Just going to throw this out there, not sure if this is a good idea but there should already be an optimized CPU side implementation of material nodes via the SVM in Cycles. Maybe finding a way to repurpose that into a general vector operation system to execute over attributes might be something to look into? At least if creating such a node graph from scratch with function nodes might take too long.

I have made a new proposal in rightclickselect.

This proposal tries to use the GROUPS as ATTRIBUTE COLLECTORS, and for this it is required to be able to instantiate them apart from duplicating them as before, and to improve their editing, therefore improving the workflow.

I leave the link in case you want to take a look at it.

Can you link to that?

It seems like a weird proposal and the mock ups don’t make much sense but when I talked to some people on chat it made much more sense as it was basically just groups without blocks (might be useful for loop node contents as well). The name is a bit of a head-scratcher though and there could have been some better communication. https://developer.blender.org/T82697

1 Like

This proposal tries to use the GROUPS as ATTRIBUTE COLLECTORS, and for this it is required to be able to instantiate them apart from duplicating them as before, and to improve their editing, therefore improving the workflow.

This isn’t about the organization of the node graph user interface, this is about providing a utility to execute custom logic to wrangle attributes in a per-entry sandboxed environment. Without mentioning them, other applications have had to solve this issue of creating such kinds of “processor” nodes that allow the user to dive deeper than a high level operation (subsurf/boolean/filters/etc) and work with the data in a much more fine grain manner (math operations/procedural noise/image sampling/voxel sampling/mesh sampling/etc). I feel as though that geometry nodes currently handles those high level operations but doesn’t offer a solution (or poorly offers) to those lower level per-point/face/vert/voxel operations that can make up the building blocks of higher level operations. Because of the different level of the data that is being worked with (whole geometry containers vs. single entries of data in isolation) in these situations it seems appropriate to separate it from the geometry nodes. Don’t get me wrong attribute math/mix/fill/random is great for quickly working with attributes as masks or for simple tweaks but seems like it’s more like a crutch when the task gets more complicated. I believe even the original design concept for function/everything nodes mentions moving in this direction.

2 Likes

Plain white noise won’t work. You are looking for Cell noise which is white noise evaluated over quantised coordinates. Exposing quantization scale factor might be necessary.
If you want to build deterministic system you always need to sanitize input for hashing floats / white noise.

1 Like

I think it’s a little confusing the way a new attribute is added. It has a very easy solution and it is more modular and easier to understand here I leave my little proposal:
1 Actual system:


2 My proposal:

10 Likes

The attribute input sockets are just string sockets for the attribute names.

Am i the only one thinking that this is a bit of a wasted opportunity?

Yes Indeed!
Already discussed above… basically the devs want the attr (that are only but matrix in the end? ) to stick with geo at all cost. right now the attr type is only a string that represent the name of the attr

I’m not so sure that your proposal would be easier to understand what’s going on under the hood.

As I understand it, attributes are bound to the geometry, they can’t exist without the geometry it’s attached to. So in your example, the random attribute node alone doesn’t do anything yet. It only starts randomizing attributes after you define a geometry in the add attribute node. That means the attribute “noodle” going out of the random attribute node carries no meaning on its own and can’t be combined with, let’s say, another attribute through an attribute math node for example.
Please someone correct me if I’m wrong on this.

But I’m in favor of the “add attribute” node! This could serve as an additional way of adding attributes – it’s much clearer and less easy-to-miss in the jungle of nodes.
Although, it shares functionality with the attribute fill node so I’m not so sure if that even makes sense to have an add attribute node. Hmmm.

3 Likes

I was thinking of something like this:


And inside the processor node you can do something like this…

(Edit: Yes… I am aware of the minor mistakes in this demo.)
(Side-note: would be nice to be able to expose color ramps and curves as inputs.)

Inside this node you can perform all the complex logic you want, wrangle attributes on points/faces/voxels in a very flexible way. This approach will likely be very familiar to people who work with a certain industry standard procedural modeling package, people who work with vertex shader graphs in game engines, and blender users who work with the existing material system.

Here is the thing… I agree with blender’s decision to access geometry attributes by name keys rather than an opaque, fixed node link. Other modeling software takes this approach as well and once the attribute spreadsheet and string processing nodes and working with upstream attributes from other modifiers come into play it will likely become apparent why addressing attributes by a wireless string identifier rather than opaque hard wired connections is a strength rather than a design oversight.

If you want to keep the possibility of injecting other names to the attribute from outside, you can leave the attribute name separate

1 Like

@jacqueslucke @dfelinto @HooglyBoogly

Have you considered in creating a “variable” / “attribute” pool?

In fact, two pools, one would be an scene pool, where you can create scene related variables of different types, and refer to them from any node tree.

The second one would be a tree related variable pool, you would be able to access them just from within the node tree where they are created or you can make them public so they can be accessed from other node trees with a reference for the node tree.

This could be very hepful IMHO, not just for geometry nodes, but for anything node-related.

2 Likes

Hello everyone, point cloud is once again “hidden” under the experimental features. For the geometry nodes use mesh objects instead.

4 Likes

Some sort of per point frame (or per domain so it can work for edges and faces too) definitely makes sense. We do plan on working on that at some point. It would probably look pretty much like your mockup @Kenzie, like a special non-data-block node group.

The other thing that keeps coming up is disconnecting attributes from the geometry. There’s pretty strong agreement among the team that this is not the way to go. Among other reasons (some of which were nicely put by @ManuelGrad) , it’s just not connected enough to the way the data actually works, so long term it would end up being more confusing than helpful. There will be other ways to transfer attributes between objects of course.

@JuanGea I’m not sure sure what you mean with the idea of a “pool”. It doesn’t seem to connect with the fact that attributes are stored in geometries. So far the design has been pretty clear that external dependencies of the the node tree would be on the ID level (data-blocks like objects and collections).

4 Likes

I guess it might be confusing to have attributes created implicitly whenever a name is used for the first time. Once you know it and understand it’s not very confusing, but I could see that being a block for some people. Anyway, the attribute fill node can add an attribute, but it can also fill an existing attribute. Given that information, adding some “Add Attribute” node just seems dishonest, more confusing than helpful, but maybe it could work.

1 Like

Since it’s not ok to mention other software implementations it’s kind of hard for me to explain this :slight_smile:
But this concept has been widely used.

What I mean is that you can create a parameter or an attribute at a scene level and use that attribute in all the node trees you have in the scene.

That parameter would not be created inside a node tree, since the scene does not have a node tree, but rather in a “atrribute pool” where you can create random parameters that can be freely used by any tree.

Picture it like a custom parameter of the scene that can drive many settings in different node trees.

For example, an age parameter for a forest scene, you would have several distribution / modeling trees in that scene, for Tree A(model), for Tree B(model), for trees distribution / forest creation, for bushes, for peebles, for water level, and I can imagine a ton of things more that can be procedurally created with nodes.
Then in the scene you have a parameter that we will call “Age”, all your trees can access that parameter and modify their results based on that parameter, if you want the tress to be young, the forest to be in it’s incipient point with just a few trees, more water or less water, more or less pebbles, etc… since all the node trees can access that scene parameter, they can be driven by affected by it.

That would be the scene parameter pool, something shared across all the scene.

Now, on the tree level, right now to create an attribute you have to use a “Random Attribute” node, so you have to input an attribute inside a node inside a tree, leet’s imagine tha attribute is called “MY_VALUE”.

Let’s picture a big node tree, somewhere in the node tree I created the attribute “MY_VALUE” and I want to use it in several places, so far so good, I just call the attribute, but if I have to modify that attribute value I will have to look for the “Random Attribute” node where I created it and then modify it.

If we have an attribute pool, it’s just a variables list, and we can pick that attribute in that list, in the N panel, and access and modify it’s values, we would have just two nodes to access that attribute, the “Get Attribute” and the “Set Attribute”.

With the “Get Attribute” we are just getting that attribute to use it, that’s it, the “Get Attribute” node socket would vary depending in the Attribute type it’s called, or it can be a “joker” socket where the user has to be conscious of the type to use it.

The Set attribute node would allow you to modify the attribute value, so you can do whatever operation you want and modify it on the fly, procedurally, on the execution tree, but the initial value is set in the attributes pool.

That would be a “Node-Tree specific attribute pool” and we don’t require to generate a node and input one more node in the tree to create Attributes.

It’s ok when you have one or two attributes, but it would be a nightmare to have to look for 10 or 20 “Random Attribute” nodes where you create and input new values and attributes, with this you use or modify the attributes in the tree, but you initially create them in a simple list, easy to access and modify without having to become crazy looking for it.

As I said it’s a concept applied in several other places for nodes and it’s a very successful one, efficient, simple, user friendly and advanced user / high level technical user/director friendly.

It is possible to add custom properties to a scene and use them via drivers to control properties of any node of any tree in your scene.
drivers

3 Likes

That’s not the point, a driver is an option, but the setup is harder even than creating a random attribute, also the idea is to be able to access those attributes without having to do any extra setup.

An option could be to create such a pool and have it linked to the Scene Custom Attributes, but avoid the need of doing a driver, which is a bad workflow in this case.

EDIT: A possible solution would be to have two different get/set nodes, “Get Scene Attribute” and “Get Attribute”, that way there is no way to confuse the scene attributes with the tree-related attributes

Also that does not solve the inside-tree attribute workflow.

The key thing here is the workflow being created, not to find a workaround, that of course exists :slight_smile:

2 Likes