I don’t think there’s a handy/elegant way to select specific elements yet, but as a workaround, using the index converted to the domain you want you can do it like this
1 Like
You mean manually selecting something specific from the procedural geometry right?
well afaik, that’s the biggest problem of ‘procedural blender’ the fact that there’s only the original mesh “state” that can be edited and a post modifier state that can be edited only after applying mods
There’s plans for “Geometry Checkpoints”, so i suppose creating a manual selection will be done from his new checkpoint concept
1 Like
Selecting points inside of bounds (for example, point locations greater than (0,2,3) but less than (1,4,5)) should be simple as well, and it will be easy to make more complex selection node groups and reuse them everywhere.
Also, selecting points inside of a volume should be possible with a couple nodes in the future.
9 Likes
+1, I agree with that, I know that the goal of nodes is about UX , reduce the typing in favor of wiring, and having the possibility to plug attributes dragging from sockets makes the tree more visual and most of the times readable, but the old workflow has its pros. I hope it will be kept.
Whatever proposal will be chosen to be merged in master (Fields, Expandable sockets, Attribute Processor) I think that just like the first iteration of geometry nodes, It would be nice to focus the development of few nodes, useful for a “example task” and test it to see how it goes. In the first iteration it was scattering instances, and I think It went fine.
From my experience, the most important thing I missed is a selection system, that was really a show stopper for me to test the system further.
Do you think that the next “example task” could make sense to be some kind of procedural box modeling?
It looks like to me that this is the direction right now, since you added the extrude node in the prototype to help test it with meaningful use cases (thanks!!)
I Hope it’s not too off topic. But my wish list is:
Selection Nodes:
-Select by index range
-Select inside volume (bound or mesh)
-Every node where a selection makes sense
should support it (like the current extrude node)
-Grow/shrink selection node
Topology and Mesh editing (all supporting selections):
-Complete and robust Extrude node (with new options like subdivisions , twist, extrude along path, modulate inset by curve)
-Vertex Merge(by distance , selected to center etc)
-Loopcut node (insert edgeloop)
-Bevel Node
-Simple Deform Node(Twist bend etc)
-Solidify Node
-Vertex/edge slide
These are the most basic for me to be able to do a lot of stuff (like the procedural bottle example i posted before), probably some of them are already in the making.
Extra: Active nodes should have viewport widgets. This is something I miss in the compositing and shader nodes too, but widgets make even more sense in geo nodes , of course this is something that is not vital and can be implemented later, but I think it would be a very welcome feature for UX and beginners learning experience.
Example: if you select a transform node, a transform gizmo is displayed in the viewport (this would solve a lot of headaches with shader nodes transform node actually).
If you select an extrude node , an extrude handle is displayed and can be manipulated both in viewport or on the node parameter. User chooses.
Back to fields:
In the current 2.93 (correct me if I’m wrong) we only have geometry data flow visualized with wires, the attributes flow along with the geometry, while now we have fields and geometry.
Would it be useful to visually distinguish the geometry data flow wires from the attribute field data flow wires as well ?
I was thinking about having the fields like dotted lines or something lighter than geometry data wires, but since the fields wires are kinda related to shader wires, I think it’s a better Idea to keep the fields wires as they are, and make the geometry data wires visually heavier, like darker/bolder.
Let me know your thoughts about that!
3 Likes
I also have some suggestion.
First, can we have the index, position, face normal etc. in a seperate category like “Field Input” (or whatever name)?
Second, can the selection field inputs have a checkbox when nothing is connected to it, for selecting all or selecting nothing? For instance, the geometry delete node would select nothing on its own, if you want to delete everything, you need to manually plug something like a value “1” to the input. This was not a problem in the master, since it is easy to just select some attribute from the attribute search manu, that will for sure select everything. For example, use position, and in most cases it should select everything. But in the Field prototype, the attribute search thing is replaced by a direct connection, then we need to manually create a different node just to plug something to it. I think it would be nice to have a checkbox to make it select everything or nothing, and the checkbox should disappear when something is connected to it.
This also helps with some clarity in some cases, like the delete geometry node selects nothing by default, but the material assign node selects everything by default. A checkbox will make this more explicit and clearer.
Third, can we have a Combine Selection (or Join Selection) node with multi-input socket?
4 Likes
Some more thoughts today.
The randomize float alone is kind of troublesome for randomizing attribute. I know you can use a random float and put the index in the seed, but this is actually pretty troublesome, for example when you are trying to randomize a vector:
you would need to combine the three random float manually to make it a vector. That’s not the end, if you just do that, because the three use the same index as seed, the three will end up the same. You need to somehow randomize the index, I try to multiply it by three random numbers I casually dragged. But you get the idea of how troublesome this gets.
Maybe have a random vector node? Or even just have a random value node, with a drop down for switching data types like float, vector, boolean, etc. I guess this should solve the problem
Actually now I think about it, connect the index to the seed is actually not ideal, since you just lose the control over the seed by doing that. You can of course use a math node in between but that’s not ideal. What about having a checkbox for making it an attribute, so we can have the seed a seperate control?
Also what is happening with Poisson disk distribution? It does not change anything after going above 1, almost like it’s clamped.
1 Like
I used the fields patch to create a simple phyllotaxis pattern. Overall, I prefer this to the expandable geometry socket, as the attributes are more accessible and easier to find. Expandable geometry socket is fine, but messier and takes more clicks total to set up.
8 Likes
Hi, can anyone please tell me how to distort vertices by curve nodes in the fields-branch? I just started making a tutorial on how to do a wheat head in the fields-branch, just to recognize that the nodes i used aren’t there anymore.
The first picture is the undistorted custom grid, the second one shows how i used to do it in 3.0 alpha, and the third shows how i would think Blender expects me to think, but obviously that doesn’t work.
When i make a nodegroup in 3.0 alpha, containing just the “attribute separate xyz” node, it even works in the fields branch, but there is no such node there to add manually anymore. I fear that in the future this positive bug will break the file.
And does anyone know when the core devs will decide how they wanna proceed in terms of geonodes officially? At the moment it feels a bit like exercicing a dead language - a waste of time.
Btw: This picture shows that the custom grid (the only basemesh for the wheat head) can be manipulated by my custom “attribute-separate-xyz” nodegroup in the fields-branch (, without the internal “attribute sep. xyz” node being existent in the add menu anymore):
Furthermore, i consider that the default behaviour of the selection gizmo should be “tweak”, not “box”.
1 Like
Here is how you do it with field:
Currently there are two (or three? but the proccessor one does not seem to be active) designs competing, no one knows which one will win. So it’s better to not rush doing tutorials, we should at least wait until it gets to the master.
1 Like
I don’t know if it’s a good Idea to start making tutorials right now… this is a prototype, and It’s not even guaranteed to go in master AFAIK.
The point Is to allow users to test the prototypes and see what looks the better path to proceed (I guess). @jacqueslucke is there a deadline scheduled to decide what the development path will be based on user feedback on prototypes?
What Gizmo are you talking about? What do you mean with “tweak”? Just curious to know more opinions about selections. It’s a topic that I care about a lot.
1 Like
Thanks! Doesn’t it feel counter intuitive to plugg a grey x-value in a purple vector slot? How am i supposed to come to that without people like you helping me out?
Well, that’s actually my choice, you can do it this way:
Yeah I was trying to redo what you did in the master so I put the seperate node first, yes it makes more sense it put it afterwards, I should have posted this in the original post.
1 Like
With this tweak selection mode, even without overlays drawn, you could in edit mode drag a vertex just by LMB-click-dragging. The left hand can be used for more pleasant things than pressing “g” (e.g. holding a cup of tea).
It just annoyes me to make my settings each time i dare to pull out a new 3d view editor. The other editors share the same problem though: A new compositor won’t inherrit the settings of the one in the startup file, but what Blender has hardcoded for new editor windows. Unfortunately the person who decided what’s good for us had a different workflow than me apparenty (even the quick fav settings are deleted in new editors)…
2 Likes
Hmm I think this is more of a personal preference. I actually like the default behavior a lot, and when I open someone else’s file set to tweak, I would constantly be making accidental operations. I think it’s just a matter of personal preference.
2 Likes
Oh, I thought you were talking about ways to implement selections with nodes, isn’t it off-topic here? ( No blaming, just pointing that out to focus on the fields topic, but maybe I missed the point)
1 Like
Yeah, it’s weird that there is no float curve node.
It takes the attribute from the geometry it’s eventually plugged into. Basically those input nodes don’t hold a specific value, but look for the attribute in the geo down the line. This could help:
And that Attribute Transfer - yeah, if it had a field output, I’d use that, no need to “write it out”.
OK I know I have posted this already, but today as I am doing more instancing stuff this is really giving me nuts.
Here is what it looks like in master:
And what it looks like in field:
This is giving me nuts. I am seriously considering this a regression because of the lack of random values for data types other than float.
@HooglyBoogly @jacqueslucke I want to ask, what do you think of my idea of a more generic random value node with the drop down for data types?
3 Likes
That is just because the prototype is not a complete implementation. In general you should very rarely feel the need to give attributes explicit names in the proposal. The Attribute ... nodes (e.g. Attribute Transfer) that are in master and in this prototype just have not been ported to the new system yet.
Same reason as above, we just did not port everything to the new system yet, this is just a prototype currently.
Yes, we do want easier to use nodes for common randomization tasks. For now you could just create a node group instead of copying all nodes all the time.
15 Likes