Holy crap. That’s almost a work of modern art. Bet you can’t wait for loops to get implemented.
The one thing that most struck me about the leaves is that, if it’s not too high poly, you could use that for low lying grass really easily.
2 Likes
I saved that picture for later. It’d be great for moss and stuff.
1 Like
I just added your split in on my trunk. Other than the fact that I REALLY screwed up the rotations somehow when I was tweaking it up, it actually pretty damn good.
8 Likes
No “The from trunk / from stub angles” switch is not needed for single splits it changes the distribution of the angles for multiple splits.
The space split angle nodes are also obsolete for a single split.
I should have got rid of them.
The taper input is a good addition.
I am not sure about the fork “override radius”, I had a “shrink radius” factor because the split already has the same radius as the split point on the trunk, giving the split a larger radius than the trunk is not a good thing to do. But with the taper input neither are necessary.
What I do not like is the control curve you use.
You are welcome to do it in they way you want but it seems less functional, the control points give you absolute control the shape of the split once you understand how they work.
The nodes in the create and shape group are a little confusing because they are not in order.
There are actually 4 points but you only have control of 3.
The default split shape is this with the shape points (offset) at 000 (no noise so you can see what is going on.):
It also acts in conjunction with the split height input. The split height input acts on the Z position of the third shape point (the tip).
The default shape for all the points is set using the position of the points inside the node group. The only input parameter for it is the split height.
The shape point parameters act on the offset of these points, they are in local space of the split.
The first point (0) is fixed at the 0,0,0 position of the split, you do not have control of it.
“shape point 1” is by default little bit up and a little bit out of the center on the local x axis.
It is best to keep this point close to the center it is what makes the splits initial direction, unless you want it to stick straight out or do weird bending. This point gives you that subtle slit at the start of the split.
“shape point 2” is the bend in the split.
“shape point 3” is the tip.
As the points work in local space
Z is up and down (as long as the split is facing upwards)
X in and out from the center of the split point.
Y tends to “twist” the split to one side.
That is why I left a split rotation and scale parameters that rotate and scale the whole thing from the split point ( the rotation is like your “rotate fork around”)
You can place the points any ware you want it is very easy to do these sort of variations:
Maybe it is me not understanding your curve system bit I find working with these 3 points much more intuitive and controllable.
I have to get round to fixing my version getting rid of the obsolete bits and adding your taper.
The bradius does work if the incoming geometry is the trunk, the problem arises when you put one split node after the other that is why I get the radius from the incoming points, you would also have problems adding a split node to the branches with the bradius.
3 Likes
Wow that is an impressive motherboard!
2 Likes
I’ll check it out again tomorrow. Right now, my major concern was getting the node on the same rough setup as the rest. Now that that’s done, I’ll reimplement what you’ve said above.
I’m fact, I might implement it in the rest of the nodes going by what you’re saying.
1 Like
I did it to your trunk node 
I swear I have so many versions of all this that I sent the wrong one.
The named attribute node was also for the multi-split version this one just uses a normal sample index node. The problem with the multi-splits was that they are all one object and their indexes summed up (did not go from 1 to 10 each split, they went from 1 to 30 for all three splits)
This one should work fine without the bradius it gets the radius from the points. (Unless you want it to inherit the trunk taper) I got rid of the non functional inputs. I added your taper setup and a taper input.
TrunkSplitting (single)_1.1_AlphaV2.blend (235.3 KB)
The noise z strength is useful when you do extreme distortion, distorting on the z axis distorts up and down and is more delicate that XY.
Have to get some sleep!
2 Likes
Wake up! It’s after noon now!
If there is one thing I’d want to change, it’s that the fork offset coordinates should use global space instead of local. If Z doesn’t grow the fork upwards, it’ll just end up confusing everyone.
That said, I have reimplemented a lot of your previous nodework in alongside my stuff. Pradius was actually doing the same thing as bradius, with the only difference being that it was grabbing the radius of the points at the beginning of the new node, rather than at the end of the previous. I thought that made more sense from a usability standpoint, so I just changed everything to use pradius from here on out.
Also, got bnorms working on the forks. Turns out there are these numbers…
2 Likes
You know I really am a vampire!
Well Z does go up.
Edit
I just checked Z always goes up. because local space is that of the original object. (unless you rotate your tree in object mode)
I might’ve messed something up then. For me, Y goes up.
Hmmmmmmm, X and Y do change because you can rotate the split but Z should always go up and down.
X out from the split point and y from side to side of the split point (not “world” X, Y)
I just checked with a branch and they behave the same.
I am talking about single split V2.
For multiple splits things are more confusing.
I figured it out. It’s due to me having the Fork Axis in there, and the align euler was throwing things off. I might end up taking that back out.
1 Like
I was getting confused there.
What is a bit stupid is if you look inside the “create and shape” node group, I mixed up the inputs and fixed it by reordering them and changing the names
It works just don’t look inside. 
1 Like
Tell me what you think of this. I removed some redundancies both within the nodes, and those exposed, and made what I thought was a good mix of our two setups.
TrunkSplitting (single)_1.0_Pre_Alpha_Redux2.blend (266.9 KB)
Also, I’m really thinking that the roots should be moved into the trunk node.
2 Likes
I will check it out.
I am playing with what we have so far and I am pretty sure we can make that Oak you posted! 
2 Likes
If we can make that oak, then we know that we’ve achieved apex tree.
1 Like
I prefer to have the preset split shape, it might be just me, but having to start from scratch is fiddly (with the points at 0,0,0). you can add default values but you can not get back to them if you mess things up without calling a new node.
Although you can put the points wherever you want I think the general rotate and scale options are important. Once you have the right shape you would have to redo all the points if you just want to rotate or scale the whole thing.
But yes it does work fine 
so if you prefer it like this fine.
Honestly, I didn’t even think about it. It won’t be too difficult to whip up a default shape right fast.
If that’s your only issue, I might just go ahead and port it into the master file.
For me that, and the lack of rotation and scale, but as I say you can do it with the points it is just that you have to edit them all.