What is missing right now in the node cylinder is , the possibility to add vertices or separations in the height, by the way this is missing too in the classic cylinder creation but you can edit the geometry and subdivide with (ctrl r) witch is not possible in geometry nodes.
this is already possible for the plane,
this would be also a plus for the other type of meshes, like the cube, the possibility to add subdivisions separately on any axis x-y-z.
3 Likes
Ahhhh! I remember seeing that on Twitter now, thank you!!
This is a long thread and I might have scrolled over it, but is it currently (git master) possible to add a custom attribute to a geometry that contains user-specified data, either 3-vector or multiple floats? What Iâm looking for is a way to set a per-vertex vector attribute, preferably through Python, and then use that in the geometry node graph as any other vector attribute.
I donât think there currently is? And misusing the existing builtin attributes seems to have downsides (e.g. vertex color might get clamped to [0,1], uv is only 2 floats, per-vertex normal might get based on face normals, etc). One workaround I looked into is having one mesh define vertex position, with another meshâs vertex positions storing the custom vector values, but I donât see a way to transfer data from one mesh to another in a general way. E.g. creating a âmyvalueâ attribute on mesh B by copying mesh Aâs âpointâ attribute values in the geometry node graph. But then again, I might have missed such a thing in this thread (and I need to spend more time experimenting with these awesome geometry nodes!).
Would it be possible to create geometry nodes at given coordinates? For example coordinates read from an external text file. This would be helpful to create forests, or to create cities with buildings at specific coordinates. Probably Dimitar has a suggestion? @dimitar
I tried my best to update node wrangler to work with geometry nodes (2.93). Can people please test out this version? Iâm asking, because node wrangler has so many functions that itâs almost impossible to keep track, and test things properly. You can leave feedback and see the changes here.
Link to the full updated file: https://pasteall.org/WPhF
6 Likes
Hi guys, i got a question regarding the collection instance node. If i remember correctly there was a patch in the works allowing to define the count of each object in the collection. What happened to this ? I would also like to know, if it would be possible to use the bounding boxes of the objects to be used with the poisson disc method to avoid intersection. Thanks !
Does anyone know of a way to mix geometry sockets/values? I know you can mix vectors, ints, and attributes, basically every socket type but can you mix geometries? Use case, building a node group, and wanting to give users the option of turning certain features on and off. Often there are other ways of visually turning off the feature but the nodes still run and process which of course can slow everything down. Appreciate any help!
There is a switch node coming, which I think is what youâre looking for (https://developer.blender.org/D10460). That will be optimized such that only the parts that are true get evaluated. Since that requires a lot of changes it might take a while before it lands.
Oh perfect! At least I have hope now. Thank you so much.
Having a look at https://developer.blender.org/T86907 a.k.a: Selection / Tagging in Geometry Nodes.
This is a pretty important cornerstone to nail, and I think judging from the 3 proposed methods blender has the right idea generally. The thing is I think from what I can tell from blender chat is that it would be only 1 of these? I personally think both Explicit Selection and Forking / Merging have their respective places here.
I made a super crude mockup here, sorry itâs so simple. Also reading the idea behind it before looking at the chart might make more sense:
Basically This is making a staircase
We start by making a step with a cube, and a line and join them together. On the line we âgroupâ both points on the line, as well as just the top, these two âgroupsâ will be used later. This is using Explicit Selection, which from what I can tell is sorta just beefed up âgroupsâ.
Then we array all of this. The nice thing about this is it should propagate the selections. So all the lines themselves should have a selection available, as well as just the tops.
Now we can separate the intended components after having procedurally created the selections using array. Next using skin we can make the vertical bars, and using âsweepâ we can make the top railing. I know âsweepâ doesnât exist but Iâm just trying to keep it simple, and I think you get the idea.
Finally we join the components into the final product.
Now, technically you can achieve this with with just Explicit Selection, but you would need to continuously add the âgroupsâ you want to perform the actions on in the latter half. That is to say both sweep and skin would require to have their selection fields used, no biggie, but in the case all the results coming out of Fork Geometry only have 1 operation after them. In the situation where you would need multiple operations before rejoining the geometry then you would always have to fill the selection field on each operation, which is unwieldy. Imagine having 7-8 nodes after that, that is a lot of typing.
Forking makes this kind of stuff way easier. Itâs basically the same as âseparate selectionâ that we already have in normal modelling. Sometimes you need it so you can perform distinct operations on different parts, even though they may act as a whole, such as animation. Personally I consider it an absolute must.
In the proposal there was also Implicit Selection, but Iâm not sure about that one yet. Not in a negative way, I just need to wrap my head around it more.
Hopefully this is helpful in some way. I hope we can get both Explicit Selection and Forking, I feel they are both needed.
3 Likes
https://docs.blender.org/api/master/bpy.types.AttributeGroup.html
attr = mesh.attributes.new(name="my_attribute", domain='POINT', type='FLOAT_VECTOR')
for elem in attr.data:
elem.vector = (42, 17, 38)
7 Likes
Thanks for the thoughts and the example! I agree thereâs room for both splitting and explicit selection, with a caveat-- I donât think this needs the kind of forking that is mentioned there, which is to have both forked geometries still really be the same thing. I think this just requires a sort of âPoint Separateâ node but for meshes. In other words, the different parts can be actually separated, without that implicit link that (IMO) really confuses things.
I think a combination of explicit selection and real splitting probably gets the best of both worlds.
2 Likes
Cool work @dimitar!
would you have a sample file to share to learn from your GN setup ?
Best,
Olivier
Iâm not sure I fully follow. Can you clarify by what you mean by:
As far as I know, everything within a node tree pertains to a âsingle objectâ, and shows as a single object in the outliner. So even if I have multiple primitives all joined up and outputâd, it is still technically one object yes? Is that what you mean by implicit link? Although if you use point instance the statistics will show more objects based on how many instances there are, does it have something to do with that?
Or maybe its Data/Object like in the material options?
Thanks, got it working!
I think it would be better if there could be an option to decide whether the rotation on the spreadsheet displays radius or degrees, right? To many users, degrees makes more sense, so I think there should be an option to choose.
8 Likes
Another little experiment that grew out of testing an update to my phyllotaxis spiral node.
The only inputs here are a petal and leaf, an icosphere and a suzanne head for the seeds.
Iâve disconnected part of the node tree on the right which adds a load of viewport brushy smudge mark planes because they were filling the view otherwise.
and render:
Nothing used outside of geo nodes and basic shaders
35 Likes
Could you show how to set string type attribute?
obj.data.attributes.get(attr_name).data.foreach_set("what is the name of string type of data?", data)
@HooglyBoogly hi, I read â T86907 Selection / Tagging in Geometry Nodes and Iâm not fond of âimplicit selectionâ. My pov is that the user should stay in complete control of what they make of attributes/selections, by specifying those explicitly in every node. âImplicit selectionâ looks like it works more linearly, like edit mode which has modeling operators alter selection. Itâs desirable in such a context where âthere is no going backâ and there is no other way for the user to âhave beveled edges selectedâ than having the operator do it for them, so I donât think that behaviour should be ported over in geo nodes where this limitation doesnât exist.
I have more or less the same take about âforking/mergingâ : separating geometry should never be necessary provided the user has enough control on what parts of the geometry they want to affect. eg the scatter node : If they need to scatter on a specific part of a mesh, then they should make a density attribute that corresponds to that area; if they can manage to select this area for âforkingâ, then surely they can select it just as well for scattering directly. If they want to bevel a certain group of edges, then they should select those edges with a boolean attribute and whatever rule allows them to do so, and bevel those only, not separate them first and re-fuse them later with the rest of the mesh. I think mesh separation is -also- fundamentally a tool from edit mode.
Generally, I think attributes should be flexible enough to handle all these cases. They are already quite flexible, and with a few additions such as transferring, filters (blur, expandâŚ), rules/walking through geometry, selection by volume, etc. theyâre going to be killer.
My post feels a bit negative all in all, but what Iâm trying to say is Iâm in favor of explicit selection/tagging. Cheers ! 
3 Likes
I agree that explicit selection is the way to go, seems like the cleanest way to handle multiple selections, masking, etc.
1 Like