Remove from the add/search menu or entirely from blender ?
If the first case, it won’t break files and will lower the probability of users ranting about spending time on now obsolete nodegroups
Another thought on the constant inputs of nodes:
Since it is planned anyway to implement a “Point Instance” node that can instance geometry directly instead of an object, I think it would be useful to allow the instanced geometry to depend on the attributes of the instancing point.
For example the following setup would distribute n-gons on a plane with a random n between 3 and 6:
Note that the “Vertices” input of the “Mesh Circle” node is connected to a non-constant field.
This would of course mean, that the “constant” inputs are no longer really constant, only that they are not allowed to evaluate a field that depends on attributes inside the geometry domains. So it might be more consistent to just treat these inputs like any other and show a warning if they do not provide the dependencies of a field they are connected to.
I updated my reply with the delaunay triangulation demo to include the expandable geometry sockets prototype and a comparison of both approaches.
4 Likes
Composing fields.
Object is just a cylinder with subdivisions.
“Attribute Fill” used to apply field.
I tried to keep the actual fields separate from the “Attribute” input.
18 Likes
Are fields related to dynamic typing or duck typing?
It looks like Contextual typing or something.
Having fun with this prototype, Using fields to select faces to extrude and displace the points along normals. I find it pretty intuitive. Can’t wait to have all the options on the extrude node!
Thanks for all the hard work everybody! I’ll try the expandable sockets branch as well if I have time!
19 Likes
Updated Prototype
- New field inputs nodes
- Add “Position” input node, to replace using the attribute node for position
- Add “Face Normal” input node
- Add curve parameter node to give the length factor of each point along a curve (NURBS not supported currently) (demo below)
- Add “Extract Attribute” node like the “pop” from the expandable geometry socket proposal
- Add initial “Extrude and Move” node for use case demo
- Add “Set Position” node
- Support fields in the Point Separate node
- Support 1D noise in the noise texture node
- Rename “Store Attribute” to “Attribute Freeze”
- Fixes for adapting selection attributes between domains. Previously some interpolations weren’t quite what was expected.
As always, builds are here:
Builds are just started, they won’t be ready for a few minutes
28 Likes
Thanks Hans for the hard work.
I tried the build, it seems much more intuitive to use normal nodes on attributes data.
Not sure if my feedback is all relative to this alpha, and I’m sure a lot of it is already known. I’d like to provide as much good feedback as possible so please feel free to let me know if this is useful and what you’re looking for.
-
Auto-conversion is very useful, and there are many areas where it could be used. I saw float can already work as Vector which is great, here are a few more examples:
-
Being able to create objects within the nodes would be extremely useful for having a packed setup and being procedural
-
I find it hard to figure out how to distribute in object components other than vertices.
-
It would be intuitive if the instances would use the point they were distributed on as their local space, and be able to work in different spaces. There could be “Point Space”, “Object Space”, “Global Space”.
-
I think it would be useful to be able to just create a number of points and distribute them. The Density option is useful, but is there a way to be precise about the number of points being created?
-
I noticed we can only save basic datatypes on points, it would be amazing to be able to save whatever data we need on each point.
-
On that regard, it would also be fantastic to have a Script node that we can use to parse data and apply formulas that are inefficient to create with nodes.
Thanks again!
4 Likes
Ah so great, seeing parameters/attributes as actual nodes without need to write in anything. You are much closer to what I initially envisioned. Some small feedback:
I still have to write in some attribute/parameters with strings, which is still tied to the former UX. If attributes could be from a list of fixed nodes, dynamic attribute filter nodes, or gate IN nodes with drop down selectors to OUT - it might make it a bit easier to “plug and play” and string up attribute workflows. It can be a custom attribute when you select it, then the edit box would show up.
Attribute String out from Fixed Node = individual nodes per attribute type (ei, normal, position, float, custom, etc). You’d have a whole list in the add menu or the parameters from the geometry get nodes to quickly add these in, and see an overview of all the types that exist. You’d have to define where you are getting the attributes from, either with no in socket and a geo-selector or socket in for geo in.
Attribute String out from Dynamic Node = from a node that has a geometry in, and it will dynamically update the dropdown list to select an attribute based on the geo in. Has option to set new custom attribute too.
But just seeing position and others floating as a node instead of a disconnect string is encouraging. Keep up the awesome work! Thanks for revisiting this. Now… how do you know it’s getting position data from X geo? A generated mesh? the parent mesh with the modifier stack?
But close!
Hi there,
the attribute field is already like a dropdown menu too. Perhaps it could be improved, but is the purpose of the additional node to offer a more explicit dropdown menu ui?
1 Like
I would be careful with adding too many implicit conversions, at some point it becomes a guessing game. I’m already facing this when converting between vectors and floats in different node systems, never quite sure if float → vector makes (x, x, x) or (x, 0, 0), or whether vector → float takes the x component or an average (iirc happens with colors in compositor). With the more complex types like Geometry → Vector it becomes even more opaque.
So i would prefer to have very few, if any, automatic conversions. Instead creating a link between different socket types could automatically insert a small explicit conversion node, e.g. “Separate XYZ” when connecting vector → float. Then it’s clear what exactly is happening to the data, while still providing that QoL feature.
7 Likes
Wouldn’t it make more sense to have a Geometry input node rather than fragmented individual inputs?
It would make list of nodes more condensed and therefore easier to learn and manage. And on top of that, it would enhance the parity between shader editor and GN editor:
This Geometry node in shader editor can still be easily collapsed using the “Hide Unused Nodeslots” keyboard shortcut, in which case it ends up looking exactly the same as your fragmented nodes, not cluttering the nodetree:
Any steps taken towards the parity between Shader Editor and GN editor will make sharing data between the two much easier in the future. I dream about the day I will be able to simply add output node at any place in shader editor and use output of it as an input field in GN editor.
18 Likes
Hi Lukas,
auto-creating nodes can also be very useful. But one of the biggest issues with graphs is their readability once they grow in size, and having less nodes definitely helps with that.
Auto-conversion, like shortcuts, is an additional layer of expertise; something you need to learn and remember but it amounts to more efficient workflow and cleaner UI.
Maybe there can be a balance between the two. For geometry to vector it sounds nice to have an “Attribute Extract” node auto-created with the position connected by default.
For Vector to Float, Length/Magnitude is actually a very useful float to get out of the vector rather than one of its components. If I want to use a vector as a “Strength” or “Intensity” value, I’d likely use that.
1 Like
I’m trying the build!
The set position is really handy! Do you think it would be hard to add something like a “keep offset option” that allows to set the median point position instead of collapsing individual points in the input position? Something analogous to what “snap selection to cursor (offset)” does.
The curve parameter node is something that I really wanted to see ASAP! Thanks for adding that!
I was trying out some use cases, using it to modulate the radius works fine:
However I wanted to create a new attribute (radius is a curve builtin one) to say, convert the curve to mesh and scatter points with density that varies along the curve parameter, but I couldn’t find a way to transfer the curve parameter varying density attribute from the curve to the mesh:
It would be great if the attributes could be automatically transferred when a geometry conversion occurs.
I tried to manually transfer the attribute from the original curve to the converted mesh with no luck.
Am I doing anything wrong? I know It’s not directly related to the Parameter node itself, but I’d like to test it in more scenarios, any help is welcome!
1 Like
My guess is the attribute transfer node has yet to be updated with field inputs (in place of the string inputs)
Oh wait no it should actually work… because you’ve set a persistent attribute in the middle of the tree. My bad, I didn’t catch it.
2 Likes
Thanks for the answer, let’s wait for someone that can figure out if it’s just stuff that needs to be yet implemented.
Here is another test with fields:
Right now the deflector object is an empty, but I’m pretty sure that I was able to replicate the same using another object vertices positions of another mesh, using 2.93 master geometry nodes… but I haven’t got access to the PC where that file is right now, and I can’t remember how I did that, ouch.
Here is another test of a node I would really like to see implemented as a selection node (I even did a RMB proposal for this): “Select inside bounds”. I wanted to just enter the upper and lower limits, then I thought it would be nice to just move the selection in the viewport, so I used a 1 meter empty to control it. It works as long as you don’t rotate the empty. I tried with the bounding box node, using a cube, but the node seems broken, min and max outputs the same values for some reason.
4 Likes
Of course, it’s quite fun adding these features to the prototype! Jacques did most of those in the list above though.
I’ll agree with Lukas that the automatic conversions you suggest are more troublesome than helpful. However, I also agree that there’s some room for automatic insertion of helper nodes to give more explicit automatic conversions.
I don’t see that happening, objects and geometry (object data) are two very different things. Though it’s fair that the distinction is more clear internally than it is the user currently.
These points are not really related to the prototype. I agree that we should add different distribution methods for face centers and edges.
Honestly I’m not sure I agree that what you suggest is intuitive. The fact that geometry nodes works in the modifier object’s local space has been a very nice simplification in practice.
We’ll have to add a node to calculate surface area for this.
Keep in mind that because this is just a prototype we haven’t changed all nodes to the new design paradigm. It would be more consistent in a proper version. The discussions about these changes in Amsterdam have apparently been heading in the direction of removing even more attribute name string uses from the node tree actually.
Personally I’m not a fan of those monolithic nodes, but I see your point. It might make sense to have “Mesh Info” and “Curve Info” nodes to output these builtin attributes (or commonly calculated data).
Right, there’s no way to do that currently, it’s just a feature that needs implementing.
That node group is a great example of this prototype in action, very cool!
7 Likes
Yeah, right. That actually gives us an opportunity to make the attribute transfer and related nodes a bit more intuitive. Some mockups:
The actual nodes would need some enum dropdowns, but it’s really nice that they can just have a single geometry input when they are the more general field nodes.
9 Likes
So in the context of fields, how do you specify the geometry from which the attribute is derived ? for instance in this attribute transfer node ? I see how that would work with the geometry expander, because that proposal makes it obvious where the attribute is coming from (being “drawn” out of a geometry node), but fields using “floating” attribute nodes… I just don’t see it
The fields are always evaluated in a geometry context from the node that evaluates the field, so that’s the geometry that the various attribute input nodes get their geometry from. However, the “Attribute Transfer” node is basically another nested context, so the attribute input on that would use its “Geometry” input as a context. (I should have named the socket “Target” or something).
I’m hearing that current discussions for the workshop at the HQ are about whether it’s possible to make this context more visible.
1 Like