Unfortunately it sometimes gets to a stage where you decide to change the fundamentals of a setup and have to almost start from scratch!
1 Like
Fortunately, I don’t think I’ll have to redo the entire thing. Most of the work should be be confined inside the Branch Axis node.
1 Like
How do you inherit the initial child rotation?
I think this is what was baffling me at first. He uses the same “branch axis” node group in both the branches and twigs so changing things inside the node group inherit “backwards” (and forwards)
1 Like
Where is this in the nodesetup? (Sorry I have never read into the setup.)
The screenshot is inside the “branch axis” node group which in turn is inside a “branch node group”.
That branch node group gets its input from another branch node group that also has a “branch axis” node group inside it!
Things get complicated!
Edit
1 Like
Yes thats how far I could follow. ( I mean the branch node being able to be used as a childrens) But there is no concept that derives the principle orientation from the parenting branch?
There isn’t. I initially didn’t have any pressing need to determine their orientation at spawn, since the next immediate step after that would be me spiraling them around their parent object. It always looked good, so I never bothered much with it.
It’s only now that I’m trying to gain more control of the process that I’m seeing some of the shortcomings.
Ok. That can quickly become troublesome. And what is the rough meaning of branchaxis?
It’s what I ended up calling my instance spawner/rotator/translator, a holdover back from when I was basing my trees off that one Russian guy’s Youtube video.
1 Like
So the b.-axis is the instantiator and the branch is the modifier of it. But the baxis already changes the orientation, with constraints that it gets forwared from the surrounding branch.
And you calculate it all in the same object space, right or is there a new childspace somehow?
1 Like
To note, you want to make sure the branches are constructed in a way where the transform origin is at the spot where they are attached to the parent curve.
Then there is the decision as to when to use the instance specific transform nodes (that work with the instance output) as opposed to using the fields in the Instance On Points node (there is actually a very important difference in how spaces are handled).
1 Like
Here’s a real quick breakdown of the Branch Node:
As far as orientation is concerned, it all starts out with the spline, which is stretched along the X axis. You can change the length, the shape to make it arch, and so on. The results of that are fed into the Branch Axis, where it spawns instances of that spline, rotates them about the tree, pitches them upwards and downwards, and all that good stuff. The coordinates it uses are all localized per instance, which is where the problems lie.
…and now that I think about it, maybe I should just change the order of my rotation types. Save the spiraling for last, instead of placing it first.
5 Likes
Okay, first experiment with reordering my rotations. I would’ve done this sooner, but I was busy making fun of people.
Alright, let’s do angles first off. So far, so good…
Now, I’ll just do the spiraling, so that…
FUUUHHHHHHHH…
5 Likes
Okay, I got it to work. Turns out that putting a rotate instance node outside of the Branch Axis group makes everything behave as you’d expect.
Don’t ask me why this is, because I don’t know.
Edit: So, after a good bit of work, I’ve now got things set up so that they make a lot more sense, and are more controllable. All splines now determine their length along the Z axis, rather than the Trunk being Z, while the various branches being set to X. This is more something for the people who’ll delve into the node tree itself, since lengths and heights are given a generic name on the nodes.
I got rid of gravity, since I always thought it was kinda goofy. It’s been replaced with Bend, Twist, and Bend/Twist Position, which are all various settings for your axes on the middle point of a 3 point bezier curve.
Upper and Lower Limb Forward Bias, and Upper Limb Start Position have all been replaced with Upper Branch Sweep, Lower Branch Sweep, and Upper/Lower Sweep Position, and it also works a helluva lot better than it did.
Input fields for the Blur Attribute node have been added. Things can more easily be made moar smoover now.
Also, I broke things up into categories, so it’s hopefully easier to navigate.
The one thing I really want to do is set it up so that you can set Growth Start/End differently depending upon a branch’s position on the tree. So that, say, the bigger lower branches will have their respective children growing out of them near their base, while the higher branches only have children spawning more from the end.
3 Likes
Makes sense, given how trees IRL work.
1 Like
I’m just another Santa Clause here
1 Like
Yup. I just have to figure out how to do it.
And without further ado, GEOTREESR v.0.55! There’s nothing really new in this release, but everything’s been cleaned up, tweaked up, and should be easier to use.
GeoTreeR_0.55.zip (2.3 MB)
7 Likes
You can’t imagine how long i want to look into this…
1 Like
If you’ve got any questions about anything, feel free to ask away.