But I haven’t found anything online about how to do something similar by “simply” transferring the radius to an adjacent curve.
I don’t even know where to start, but I know for sure that it should be done using a repeat_zone, but how? Has anyone else encountered this problem before, or is there a similar tutorial?
If you’re OK with the radius at branching points to be an average of the radii of the two control points there instead of using strictly the bigger branch’s value, you could simply create a mesh copy of your tree spline and letting a Merge by Distance node handle the attribute inheritance. Then you can use that merged mesh skeleton to sample the averaged radius from the nearest point:
Since you’re taking the average, the exact final radius value of any branching point would be different from the one in the UI, but it would still get bigger or smaller no matter which of the two point is selected and being manipulated, keeping the correlation intact.
Let me explain in more detail - I need to transfer the radius of the points from the main curve. At the very beginning, there’s a main curve with radius, and they need to be transferred to adjacent curves.
In the screenshots, it looks like an iteration. Something similar should happen in the “repeat zone”.
On the first iteration, it’s transferred to the upper-right curve, then on the second iteration, it’s transferred to the lower curve, and so on…
I hope I explained it clearly
Well, how are you producing the branches? Manually? Procedurally? How are you tapering them? There’s none of that in your file. Are you using a Repeat Zone already, or do you think you probably will need one somewhere and that’s why you’re mentioning it?
As a very general idea, you would still probably use a Sample Nearest > Sample Index method to do what you want but it would entirely depend on your main setup, which is not clear to me.
All curves are created manually (they can be simple geometry).
After all the curves are created, the radius for the main curve is set using GeoNodes, and then this radius is automatically distributed to all secondary curves, then from the secondary curves to the third curve, and so on(previous screenshot with iterations) TransferRadius_01.blend (1.3 MB)
Well this is confusing… if the curves were not made by Shortest Path as you mentioned before, it’s a very different problem
If this is manual, then you probably need to do something like:
sort the curves if needed (whatever “main” curve means, I guess the one that has index=0), make sure that “joint” point is the first one in each spline;
set Radius from Factor for all;
start assembling new geometry with only the main curve included;
for spline (except main) sample nearest “new geo” point and get its Radius;
map Radius from [0 to “sampled”] on the current spline, write it to spline;
add that spline to “new geometry”;
repeat for the next spline.
Or something along those lines
This is what I got so far (I’m not very good with Zones nodes though):
As you guys have already talked about, if you’re drawing the branches manually, indices will not necessarily follow a logical order from bigger branch to smaller, so ‘sample nearest’ logic will probably get more and more complex (like “smart sorting by distance”). Instead, here’s another idea:
I’m merging everything to a simple, fully connected skeleton again. Then, using Shortest Path nodes, create a curve from every vertex (For Each Element—Point) to the root vertex, then count how many points it takes to get there. The larger the number, farther away the point in terms of branching steps. Then use that number to scale each branching point via a Float Curve. Since this only counts steps, a longer branch will tend to stay thicker if it’s not being divided by smaller branches along its path. If we wanted to, we could also calculate the total path length the shortest paths for each vertex needs to reach the root (via the Edge Cost > Total Cost sockets on the Shortest Edge Paths node) and integrate that into the radius calculation as well…
Since the merge is very straightforward, if the branch is too far from geometry OR intersects other curves somewhere other than at the start, it will lose some paths. But might be okay if precision is not important. Plus, it’s very satisfying to keep adding the branches
Stray , Kuboa - Thanks for the new solutions, especially with the scenes.
It’s really nice to have different approaches. I’ll keep exploring and learning
but that’s a bit off
