If you got this from my comment from Blender Today, know that this is not necessary anymore, since yesterday’s commit you can choose an object to instance inside the Point Instance node, check this out
yeah Weld modifier is pretty handy when you need to filter out points too close each other. I use it quite often to get rid of trees growing unnaturally close to each other. I hope Weld modifier will be added to geoNodes soon.
I think using weld modifier for that feels like a bit of a hack; not that it doesn’t work, but if you want to keep the point count at a specific amount you have to fight with the density amount vs how many points get welded.
I think an easier solution would just to have something like “relax iterations” built into the node. Perhaps some different distribution methods too maybe? Who knows, this is still all very early. Loving it nonetheless!
Hopefully there will be something like blue noise distribution to get a nice non overlapping coverage of points. Would be good if there was an option to be scale aware, so that if a scale attribute is added to points, it can use the point scale radius/bounding box to avoid intersections.
Not sure how this is done, and if it is some form of circle packing, but the new H18.5 scatter tools allow this. No doubt it is less performant but should be an option, especially for a convincing scattering of pebbles, foliage etc. especially when the density and scale are driven by procedural noises.
Miro_Horvath, Bobo_The_Imp, this is exactly the task I faced when creating the bamboo ends texture. Distribution of points, random and even, without crossing points.
This example can be used to test this node system.
Duplicating the group input node (the one built into the modifier node tree, not a user-created group) seems to invalidate the entire tree : my output mesh looks unmodified.
So from first impressions I’m very much missing a simple triplet of float sockets where the vector sockets are. Maybe give both : vector socket aside to the property name (“rotation”, etc), and individual float sockets for each property (x, y, z…). Right now I have to “combine-XYZ” every value I want to input into the transform node’s sockets which seems unnecessary.
Of course I would also want to preview the node tree at any point, ie there needs to be an active preview node specified with a little icon on its header… or something in that vein.
The next thing is… value fields in the node editor could use expressions. It would be a shortcut for what is currently a string of math nodes (most operations take only one, but some take three, and in any case that’s a lot of extraneous nodes in the end). The expression would be embedded in the value field, and able to access only variables in the nodetree (not anything throughout the Blender scene, that’s a job for drivers) and manipulate them just a bit without having to insert a math node in between, which I think is cool because it would show also the actual number in the case of constants (just like in William’s proposal). Of course the relationship would still be shown by a regular noodle between the two (or more) sockets. I guess the value field should be colored or something, so as to make it obvious there’s an operation happening there…
A simple switch node would also be neat !
An overlay to show the output of the active node… in wireframe, unobstrusive, overlaid onto the solid “mesh output”… that’s sparkles I know !
I have a proposal of adding custom properties to a node tree.
The problem is that sometimes trees are growing very big and some properties can be used several times in opposite parts of the tree so you have to add separate value nodes and spread connections from them to all over the tree what is not very convenient.
The proposal is to add node tree properties so any node property could subscribe to their changes and use their values via drivers. This will help to keep tree more clean. Another advantage is that custom properties has more control. It is possible to determine limits and type of the value add its description what value node can’t do.
Without loops or geometry arrays right now, I couldn’t make it so that the number of shelves is dynamic, only their position relative to the bookshelf height. Maybe I’ve missed a possible way to do it ? In effect it is a bit less programmatic than I hoped, but this is still very early : there are almost no modeling operators and those would be my choice for that kind of job, along with a more flexible way to copy things, and the ability to add primitives in the node tree.
What makes it tedious also is we can’t choose the origin of transformation for the transform node. So we have to manually compensate scaling, which always happens relative to the object origin. Ideally there would be a “transformation origin” triplet, or separate “scale origin” and “rotate origin” and a “transformation order” dropdown so that we don’t have to chain several transform nodes.
Right now the geometry is a bit glitchy because the boolean node is used in place of a “merge” node, which in theory would not care about intersecting geometry.
Also, I was trying to distribute books on the shelves, but it felt like I had to add a point cloud object for this to work, and even then my point cloud object would be disconnected from my bookshelf object, because it can’t share the same nodetree and variables that I used. So my point is, all has to happen within the same nodetree. It’s great that we have a point cloud object, but we have to be able to specify points onto which to copy objects within the same node tree (point instance node with two inputs, one for copied geometry, one for points).
Also we totally have to have the ability to add handles (gizmos) connected to properties, to manipulate these things directly in the viewport. That would be awesome.