Thanks again. I’ll definitely check those out.
One of the first sets of languages I learned was C /C++ albeit at an extremely basic level. I’m hoping that knowledge pays off now.
The merge by distance node is useful, but limited in certain cases. Has anyone considered a merge by index mode? All points assigned the same index would be merged. For instance, points 0 would be merged, but not with points assigned 1 or any other number.
This would be incredibly useful in cases when you need to extrude two adjacent faces and merge the caps, but not with each other.
Have you tried to assign the group index to the position?
Good idea.
Capturing the position, setting it to the index, then setting it back will merge points with the same indices.
Then I need only capture the indices of the original geometries before joined and add them together:
For reference, here’s what it’s like without the merge node in this case:
And here’s with the regular merge by distance:
It feels just a little cheaty, but hey, it works!
That’s clever. Still, a generic merge node would be nice. It would have a single group index input -all elements sharing a group index would be merged together. No need to build kdtrees and all that, probably a good performance saving
Hi folks, thinking some more about this… I wonder if the following would seem useful ? →
Instead of having a “merge by distance” node (or in addition to it), what about splitting the merge functionality into its own node, give it an input where the user can connect anything (a sort of “merge index”) and make the kdtree (or whatever structure is used to store proximity) accessible on its own (new node) for other purposes? I wonder what these could be. I’m thinking geometry generation : creating faces or lines/curves between groups of points…
@HooglyBoogly you probably have other things on your mind right now,… but how does this sound to you? do you think it would open the door for new things?
One precedent for this kind of thing is the split edges node that went from “split edges by angle” to just “split edges” with a selection input
Kdtree, closest element that is not self would be dank
edit*
oh or return a geometry that is points !!
input index-> output that points data if it exists
8 posts were split to a new topic: Is there a way yet to properly link up a hierarchy chain that runs along a path?
2 posts were merged into an existing topic: Is it possible to control light intensity with geo nodes?
Getting really closed to being finished with this, been working on it for a while now in my free time and I’ve learned so much about geometry nodes in the process.
Really can’t wait for a loop node to be made, because having iterations avaliable would make a lot of busy work c/p node groups over and over. Ces’t la vie. I’m really happy with how it’s turning out.
It seems that the community decided that this is the official support, showcase and everything else about Geometry Nodes thread. And no one can stop us. Old habits are really hard to break.