I thought it could be useful to show how scattering flowers workflow can look in Sverchok.
4 Likes
I like Sverchok to an extent, but honestly this looks too bogged down to me. I feel like all you need to achieve that should be no more than 5-7 nodes. Starting geometry, Point Distribute, Attribute manipulation, Instance to points, and maybe a mask thing in there, but you can do that with attribute manipulation I feel.
I much prefer the attribute workflow that seems to being worked on here in blenders geometry nodes. I know with this setup in Sverchok you have a lot of control but it just seems there is too many nodes flying around. I think itās easier when you can follow a ācourse of eventsā that makes itself more obvious to the artist. For instance, in this sverchok image, Iām not even sure what that āMeVā node is doing up in the left corner there.
4 Likes
The flower scattering workflow can be done a little bit more straight forward with SV as well if youāre prepared to borrow normals from the base mesh. Obviously Iām not doing anything avoid collisions though.
Would this be a good place for me to share my thoughts on Geometry Nodes having spent some time with it?
6 Likes
@Erindale yes. As I mentioned in the initial message in the thread the team (me anyways) is reading all that is said.
1 Like
For the records, I updated the initial post with a link to the (work in progress) documentation.
2 Likes
Iām not a developer myself so I canāt speak for optimisation or anything but I did notice that Geometry Nodes was only using a single thread so when I was ārenderingā (read: screenshotting) my animation I found it faster to open 20 windows of Blender, each loading a different frame. Apologies if this is something that will come out in the wash, I just wanted to mention it.
A few thoughts:
Boolean node difference operation - I think the sockets are reversed? I would expect the first socket to take the base mesh and the second socket to be the cutter but it was always the mesh going to the second socket that was visible after the operation.
Group nodes - The viewport does not update to changes while working inside the group unless forced by changing the camera or playing the timeline while working. If plugged into the front of a group node, changes could be made from outside the group and it would update fine so I guess thereās something about being at a deeper level.
The enigmatic geometry socket. I would definitely want to have vertex / edge / face information exposed to the user. Things like instancing to verts is an important workflow but you want procedural systems to give you the control to be able to pick which verts. I hope weāll see more data / list management functionality moving forwards.
The modifier - Iām not sure if youāre absolutely deadset on having it function as a modifier but itās not something that makes much sense to me. I work primarily procedurally in Blender and Iāve worked with procedural software outside Blender. To me, the ultimate form of Everything Nodes would be a Scene graph, under which, geometry/simulation/shader etc nodes are nested, but not separated. The power of a system like that is being able to have intercommunication, not through attributes, but by direct, visual connection - in keeping with the node user experience. I understand the convenience of being able to apply the geometry node tree to an object like a fancy custom modifier, but thereās no reason that a detached node tree couldnāt point to a specific object (in the same way we can already pull in other objects through the Object Info node). As a modifier, if you want data to effect two objects the same - though each with their own tree - youād need to be sending specific data between trees somehow, rather than just connecting a noodle 2 ways. Would it not be possible to replace the modifier stack entirely with nodes and save shoehorning Geometry Nodes into an incumbent system?
As a procedural artist Iām really excited to see Blender developing some more native tools! Iāll be watching with interest!
10 Likes
I thought exactly the same!
Also, for me the Boolean node has a behavior quite hidden EDIT: my bad, I started only recently to use this, and of course I found out to use the Object Info node to drive the Boolean with another mesh 
!:
NEW QUESTION
-Instead of using an Object Info node, wouldnāt be better to have an object picker inside the Boolean node itself?
1 Like
This is easier to understand what is going on I think. I think what I am trying to say is that I really appreciate it when there is a simplicity to the flow of events. Coming form Houdini, even though people call it a very complicated software with a learning āwallā, I have no issues finding out what is going on in the flow of things. I think there are a couple reasons for this.
One reason is legibility. Houdiniās nodes are always just little boxes, with all parameters hidden in a parameters browser. Itās always been blenders way to expose parameters on the node, and I do enjoy it, but it can get a bit spaghetti messy. Things like
Unless this is relegated to a utility node to expose such parameters at any step, you get things like nodes triple connecting to each other like in your example, which if it happens all the time does simply get messy imo, even though itās helpful.
More importantly for legibility I think is just naming. Houdiniās nodes usually have names that are pretty artist friendly. Itās maybe harder to describe but for instance, the difference between āBevelā and āMatrix Normalā. āBevelā pretty much tells you what operation is being carried out, whereas āMatrix Normalā, if one wasnāt inclined to know some math and/or be 3D savvy, I donāt think it really denotes what it is doing. Iād maybe call it something like āPrime operationā vs āUtility operationā or something like that. Itās not like Houdini doesnāt have tons of āUtility operationsā, you have your array append, matrix align, quaternion to matrix3 etc, but these are mostly inside nodes like attributeVop or attributewrangle (where you just write code and can get as esoteric as you want).
Because these things are mostly hidden within nodes, I feel it really helps keep a very clean and self evident flow of operations. You get trees like "Bevel ā normal ā subdivide ā attributevop ā copy to points. The utility nodes are packed away inside the attributevop, so if you are a beginner itās still pretty easy to read, instead of seeing several utility nodes flying around.
I think Sverchok and Animation nodes are not as simple in their presentation as Houdini because of this. They all can pretty much do the same stuff, but I just find Houdini easier to read, always. Iām not trying to bash Sverchok or animation nodes, I love both of them, I am merely hoping that presentation for the user will be more friendly in something that will be in master. I hope that makes sense
I would also like to greatly second this.
5 Likes
Ah, good point, it might be better to reverse this.
I donāt think so, because in general these nodes work on a geometry level. Not all geometry is tied to an object, especially intermediate geometry in the node tree. Eventually there should be some way to use a collection though.
2 Likes
I agree on Sverchok being too complicated for most users. I believe itās very powerful and has a vast amount of nodes, but most node setups Iāve seen are not easy to understand by quick look. The issue is partially because of naming of nodes, which is mostly very technical. I hope Geometry Nodes will be more like Power Nodes that Iāve seen in development. Iāve tested Sverchok only very briefly and Power Nodes donāt have any public version to test, so my opinion is based on what Iāve seen in discussion for both addons at Blender Artists forum.
Maybe Blender developers could exchange ideas with Power Nodes developer? I think he has a good concept for his project and seems to be skilled programmer.
A simple little mography thing using the current build and eevee. Blender is going to be killer for mograph in the next year or 2 with the combo of geonodes and eevee. My background is using the typical C4D/AE combo for mograph/broadcast, but I can really see Blender taking much of that market share within a coupe of years. Add in some of the upcoming blender tech like viewport compositing, vulkan realtime raytracing and greasepencil/lanpr and there are interesting times aheadā¦please excuse my enthusiasm 
Really looking forward to some sort of falloff system and procedural noises in geonodes that can be used to drive attributes. As well as a time/frame node to drive animation.
12 Likes
For the problem of the complexity of strelok but the necessity of atomic nodes maybe could be better a retake of the āgroup nodesā concept. Nothing special, but could be a simple thing and a big improvement in general for all nodes editors.
Allow that āgroup nodesā could be āoficialā nodes inside a category. So (for example) if devs want a ātransform randomizeā node they can have it. But inside this node they use a random attribute node and other nodes that users can use in their own nodes.
It will make easy create custom nodes for users and keep it like normal nodes and not only in the āgroupā category.
It could be a big improvement for users in other locations like shader editor and to share assets between community.
6 Likes
Coming from C4D as well, I totally second this.
Yes, having āpre-madeā nodes for different uses would speed-up the workflow, and I think also help the users in understanding better how different nodes work!
To organize Node Groups in categories; this could relate to Asset Management.
3 Likes
Hi Hans, I wonder why is there need for āattribute mathā ? Why wouldnāt regular math nodes able to operate on attributes ? @HooglyBoogly
Hi, hereās a tutorial for my previous forest video, enjoy.
9 Likes
Hi! This is the fundamental difference between a system with callbacks and one with actual data flow (what weāre building). In a callback system the nodes are just UI elements used by some other system to build a final representation of what the node tree does (for example, compile it to a shader). In a data flow system each node is more independent-- all the information a node needs to work is contained in its inputs, and some changed form of that data is passed as outputs.
This means there must be a special node to do math on attributes, because the data being passed around is the geometry, not number values.
This does have some downsides, mainly that it requires entering attribute names all the time and that the node graph is a bit less visually self-explanatory, but I think it is definitely the best way to go in the long term. Having independent data-flow nodes means it will be much easier to use them in other systems, and it can be easier to reason about a system when you can properly think about its state at certain points.
Note that this is just my take on all that, maybe others would think of it differently.
4 Likes
Alright, thanks for your explanations !
This actually sounds to me like what I thought Jacques was going for with his particles prototype, at least what I had gathered from his logs, but I must have misinterpreted it.
Arenāt attributes mostly just floats or vectors ? (even point positions and normals ?)
Surely from a usability point of view it makes sense to expose the data directly, rather than have users remembering and manually inputting attribute names? If geometry is just verts (as XYZ vectors) and polygons, thatās fairly easy to manage as indexed lists.
Iām coming at this from Sverchok and Grasshopper so my understanding of procedural modelling is fundamentally as list management.
2 Likes
Hi there!
I dont know if these points have been discussed already so, sorry by advance if ever it has.
-
A nice parameter for the point distribute node would be a smooth / relax / distance / repulse (or any other appropriate name) slider in order to avoid scattered points being too close from one to another.
-
A way to make any existing scatters affect a specific point distribute.
E.g : I have scattered a bunch of trees on a plane and then, I want to scatter some grass on my set but I want that grass scatter to keep small empty spaces all around the trees position.
We could just plug the output from the point distribute A and connect it to the input of the point distribute B in order to affect its out result and control the falloff with a slider. -
A list to display all the used attributes and their results at the end graph, both the built-in ones and those defined by the user.
-
Allow the transfer of attributes from one object to another.
E.g : Color from point cloud to geometry in order to create a mask where the points are scattered.
4 Likes