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!
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.
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.
What I fail to understand is that attribute transfer works between two geometries so how can we only have one geometry socket here ? I’m sure I’ll wrap my head around it sooner or later, just a little puzzled for now. Carry on heheh
This is fine, the fields proposal negates a lot of the need for it, but would we still have “Store persistent attribute”? I think that particular feature is still really useful, like for sending attributes for shading etc. Also being able to bring in an attribute node way later in a tree removes the need for noodles circumnavigating half the planet, which is a nicety.
Thanks! Here is another use case of the selector node, completely procedurally modeled bottle.
I had to use two geometry groups modifiers due to the lack of solidify node and simple deform node: The last extrusions had to be performed after the solidify.
I had to do some workarounds to scale parts of the geometry, since the transform node doens’t support selections, so I relied to the point traslate node.
Also it would have been more convenient to just use the mesh extrude node, but the component type extrusion is not yet implemented (I started from a circle, I relied on extrude and move node that allows to extrude edges)
Right now is a rough quick test, but linking the selectors positions with the extrusion distances could allow to pack a nice bottle generator. The linking could be done with drivers or other nodes like set position with offset, (as I suggested before), combined with a “get selected points centroid”.
When i got HooglyBoogly right then the attribute transfer Node, walks back the link of the incoming attribute (or maybe the attribute itself carrys the geometry, not sure how its done internally) to find the source geometry.
In my example (makes not much sense, it is just for clarifying) it would retrieve the icosphere in that way.
Fair enough. I’m just concerned it can result in too many nodes.
It can still work in object’s local space, it doesn’t lose that. There could be a dropdown on the node itself:
Provide additional spaces will allow to do transformations easier, with less nodes and with less math knowledge.
For example, if you scatter points on a surface and you just want to offset the points a little along their Z axis, you could input the offset value directly, as long as you switch to Points space.
Without the point space, we’d have to extract the current position and current orientation, do vector math to create vectors along the z axis and add that to their previous positions, a more difficult and complicated operation.
That completely clears it up… didn’t think of going back to the original post, thanks for linking that. So I assume this “transfer field” node would allow “field-ing” any attribute ? It’s real mental gymnastics for me, but I think I’m getting it ! heheh.
So in effect… this “transfer field” node is almost like the “geometry expander” node from the other proposal. It takes a geometry and outputs an attribute. How it’s used after that is different but conceptually it’s pretty close.
The final version of the “Transfer Field”/“Attribute Transfer” node might not have a string input actually, it would probably have an input for field itself (which would probably just come from an anonymous attribute). That sounds complicated, but it really just means the attribute to transfer would be chosen by plugging in a noodle rather than typing a name.
I started a new build on the buildbot. Looks like the mac buildbot has stopped acting up.
Great job on these updates!! Keeps getting nicer and nicer to explore this prototype.
Btw, I noticed in this last update these extrude sockets look like they don’t accept fields, but they actually do:
Something else I noticed in both prototypes is that the poisson distribution mode in the point distribute node seems to be capping the density very low even if min distance is set to 0, but I guess that’s a known limitation of the prototypes.
Agreed! One of the best things about the current 2.93 attribute workflow is being able to create and store attributes upstream to be able to access them at any stage downstream. I would not want geonodes to be exactly like shader nodes, with the need for giant noodle streams all over the place.
I have been playing with the fields prototype, and using the store persistent attribute node in combination with the new fields workflow, does seem like the best of both worlds. You can then create attributes upstream that are reused by many other nodes downstream, as well as using fields for individual nodes. Really hope that this is the direction that the development goes in, as it is very unique and powerful!
Why does the selection ouput by the Extrude and Move node the old one instead of the newly extruded one? This is strange, is it just not implemented yet?
Also we really need a better way for manual seletion, I tried to use the vertex group for extruding that face but vertex group is in point domain, which means it would select some neibouring faces as well. I used this method to select the top face, but I think we really need a better way for manual selection:
It feels strange, shouldn’t the delect old face operation be done by default?
EDIT: It seems the regular extrude node works as expected, not sure why the Extrude and Move node behaves so differently. I thought it just changes the offset from a float distance to a vector, but it is apparently not the case.
Sure ,node groups can help to tidy up a sprawling tree and make it more readable. I was more talking about noodles that have to travel from one end of the graph to another. As long as the persistent attribute concept is kept, then I am happy with the current fields approach.
I have been doing some tests, where I use the noise node piped into the store persistent attribute node (which is the renamed attribute fill node) and then I can refer to this attribute at any point downstream. Without it, you would have to have long noodles making connections to that original noise node.
