Kinda. Thanks for your answer. I was wondering about some finer control. For instance, some vertex or some edge from the new extruded faces. By these node groups on the image, the selections are a little generic (in lack of better wording, sorry). I mean, we can select top faces and side faces, but can we select a specific top or side face?
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
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
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.
+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.
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.
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?
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.
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):
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.
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.
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?
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.
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)âŚ
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.
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)
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:
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: