Indeed, thought it might be worth something 
1 Like
You have a point there. Also if each single split is one node things are much more controllable just with the shape points.
This would drastically reduce the number of parameters needed for the splits, I could get rid of all those offset parameters and nodes. it would make the split node much less intimidating.
I was trying to work out a way to get the split’s radius’s transferred to your branch node. The easiest way would be to change the radius input in the branch node.
In my split node I get the “bradius” directly from the trunks points with a sample index node but you use the named attribute that does not refer to the splits.
I think I will leave that for the moment and make a much simpler split node that you can use for single hero splits. That way you will have control of the branches for each split, I will make a quick moc-up and post it.
Ye he delete nodes and inputs! 
2 Likes
You’re probably stumped on the same thing I was for so long, trying to grab the bradius after the Curve To Mesh nodes, where it seems like you’d actually having physical radius attributes to pull from. What you really have to do is grab and feed it out along the point line after the set curve radius, before anything’s been converted to real geometry.
No that is not the problem.
When I plug in your branch node the branches do not get the right radius, “bradius” does not work because the splits and new truck points have different indexes compared to the original trunk.
If your branch node used the points radius instead of the named attribute the problem is solved. The points do not care what index they are they just have their own radius value.
I will include a modified version of your branch node (with a different name) using point radius, in the mo-up, to show you what I mean.
1 Like
The way I have it pictured in my head, your splits could still be considered children of the parent trunk node, and should inherit any attribute from it, same as the branches. So long as you’re feeding in and outputting the same information as any of the other nodes, it should just work.
Though that we’re now splitting what was once a single line into multiples to account for each new split probably will break something somewhere.
Also, I’m wondering if I could use a proximity node to limit growth between different branch sets somehow. Like you have branches on Trunk A, branches on Trunk B, and when the two groups of branches just about touch, they stop growing outwards to keep from overlapping.
This is more or less how trees work in real life, and it would solve the issue I illustrated above.
And I still need to find a way to create an upward bias that effects the entire canopy. Maybe I should add another node to the end of the line, just before the leaves, that allows you to tweak the tree globally.
Ten Character Minimum Override.
2 Likes
Unfortunately it does not just work.
I got it working with my branch node so I will take a look how, I think I resorted to saving a named attribute, but that presents yet another problem having to change the name of the attribute per branch node. 
I will investigate.
1 Like
It’d be nice if things just worked, but from my experiences, it usually doesn’t. 
1 Like
Well in the end this seems to work. I did stick the “branch point radius” node in your file to check and it looks ok.
I have made a new split node that only does one split. I got rid of all the offset options.
I changed your branch node so it uses the input points radius, I did have use a store named attribute node but I think it works without having to change its name for each iteration. (the capture attribute and sample index nodes have been driving me crazy)
I named the modified branch node “branch (point radius)” so you do not mix it up with your original.
I have left 3 splits with there respective branch nodes in the file.
(I did not take time to make it look good!)
TrunkSplitting (single)_1.0_Pre_Alpha.blend (237.8 KB)
Edit: one thing I noticed is that all the splits were drawing the trunk so I have given the node a draw trunk button. I have updated the file, in this example only the trunk branches that come from the trunk draw it.
1 Like
I’d check it out, but I think the forum farted up your link.
1 Like
Link fixed 
3 Likes
Got it. Checking it out now.
Here you go. I fixed up a ton of stuff so that it aligns more with how the other objects in the node behave. I removed some stuff, added others, changed some entries, and for the stuff I didn’t know what it did, I left that alone.
I think the biggest change I made is that I created a quadratic bezier along the X axis, something I did for all the limbs and leaves, and set it up so that the only deformations you get out of it are basic positioning. I save the noise for after the realize node.
I also got bradius to work, though bnorm is giving me a hard time for some reason. I’ll check it out later. For now…
TrunkSplitting (single)_1.0_Pre_Alpha_Redux.blend (274.8 KB)
1 Like
I will take a look, did you add a draw trunk switch? all the split nodes were drawing the trunk.
Not to the fork node, no. Is that what the From Trunk/From Stub checkbox does?
Very nice! I like the leaves in particular. Is that all deformed geometry?
Thanks @Renzatic !
Leaves are a happy accident. They are made from a grid node.
It’s all made in geometry nodes. Including the pot. This is tree node setup:
6 Likes