I don’t blame you for running. It’s a giant pain in the ass. 
While having nice and cleaner node groups would make for a more managable UI, I’d be a little concerned on making the whole thing more complex and adding stuff that could cause things to break on later versions of Blender (if/when they add the ability to collapse items on node groups) when opening up older files with said node group.
It is of course upto Renzatic to decide what goes in his Tree system, I just try to avoid adding stuff that could break later on.
3 Likes
Anything could brake there always adding and removing nodes, many tutorials from 2021 dont work as the nodes dont exist ect
Its the nature of using an in-development tool
Its the same experience making a game on unreal then deciding to upgrade to a new engine version having to go back and update scripts ect
1 Like
Current update: still stuck, and still can’t figure out why. I’m in one of those situations where it looks like I have all the appropriate pieces in all their appropriate places, but it’s not giving me the appropriate expected results.
This is what the vector normals on my tree should look like…
I’ve successfully grabbed the vector normals from the trunk…
And I’ve successfully grabbed the vector normals from the branches…
But when I go to apply the trunk normals to the branches, it doesn’t transfer them.
It’s driving me crazy. Even worse, I know that when I do finally manage to figure this out, the solution is going to be so obvious, it’ll leave me feeling really dumb.
3 Likes
I’m a little confused as to what you’re trying to achieve 
Something like this?
Though on a tree it gives weird results (probably because “nearest” point is always different and it’s a mess):
2 Likes
That’s exactly what I’m trying to do. I want the base of the branches to steal the normals from they’re spawning from their parent object, then falloff to their regular normals a small distance away from their base.
I figured all I’d have to do is grab the normals as an attribute, then use a geometry proximity for the falloff, and I’d be done. The thing is, it won’t transfer the norms from the trunk to the branches. It’s completely static. I can see that it is capturing and storing the normals, but I can’t use them on anything else.
The reason why I’m spending so much time with this is because of this smooth transition right here…
2 Likes
Well based on your own node example from above (or so I though, but I might have badly misread it?), this is what I got (it’s messy, i’m sorry):
Fill a single attribute with the original normals, on branches write either sampled normals or original depending on the proximity factor… or something.
I don’t think I like the results so far though. The faceting keeps showing up for one. And some shadows/lights on “seams”. I think it has to do with branches being so deep inside the trunk that they sample points on wrong sides of the trunk. Maybe.
Found why I didn’t have faceting problem in the test file: AO was turned off
5 Likes
Man, even when I have the answer right in front of me, I still can’t manage it. Though the ordering shouldn’t be important here, that’s the only variable I can think of that’s screwing me over.
2 Likes
The only thing I can think of is maybe a typo in attribute name somewhere in material? Because these seem to be the exact same nodes…
2 Likes
It’s doing something, but only on the last branch attached to the branch nodes. It’s still ignoring the trunk.
This means I have something in the wrong place somewhere. Maybe I should try to store the norm attribute within the trunk node starting off, then capture it on the branch half before the join geometry. Let’s see what that does.
edit: BOOM! YES! THANK YOU!
6 Likes
I owe you a beer now.
2 Likes
As you’re probably well aware, the shading errors can be mostly minimalized by pulling in the Greater Than so that it accounts for JUST where the branches meet with the trunk. You still get some blips and blobs here and there, but I think the tradeoff is worth it, especially when I start messing with really gnarly trees.
I’ll probably go ahead and expose the Greater Than float as well, just in case.
7 Likes
That looks beautiful😮
4 Likes
Thank Billie for that. 
3 Likes
GeoTrees 0.4, now with fancy normal shading on the limbs, and reintroducing the option to use custom objects for your limbs (currently untested, but really, it should just work.)
GeoTreeR_0.4.zip (2.0 MB)
Next up, I think I’m gonna work on the leaf generator.
7 Likes
Very, very, very slight update. I won’t tell you what I changed, cuz it should’ve been done to begin with.
GeoTreeR_0.41.zip (2.0 MB)
6 Likes
A progress post, (you are much faster than me!)
First… Wow you are racing ahead! I love the new canopy float curve. 
I have solved a couple of major issues with extreme distortion, (it has been a headache but in the end is was not to difficult, just took me a long time to work out.)
I have also changed the control a lot, the splits are now very controllable and a lot more logical.
The only thing to take into account is that the splits happen from a “stump” which means that you need a trunk with an end radius and value to plug into the split node. You won’t want to split from a twig!
The node will look something like this and you will be able to plug it in after your trunk node an before the branches. (do not worry about the warning on the root node I will get rid or it and it is not important) This example is all splitting (no Branches).
I still do not want to post a file yet as I have to refine the inputs and set good presets. It has to be worthy of your tree.
I am also working on controlling the splits separately (note that that already have different lengths)
Maybe I’ll play at spot the difference! 
3 Likes
True, I just think that adding python code on top of said ever changing nodes in order to just make said nodes look a little cleaner as a UI is an extra risk that just isn’t worth the reward.
It then also adds extra maintenance work over time.
2 Likes
It’s easy to find, but I’ll save you the effort, cuz it’s not all that exciting.
I changed this…
To this…
Per Zorro’s “no need to expose a switch box” setup.
Also, hurry up! I want to play with tree forks!
3 Likes
I think I can get away without this although having a stump can be cool as well, or “sawn off” branch stubs.
One thing that occurred to me a week ago is a very important concept that I think we have overlooked POINTS HAVE RADIUS.
There should be no need to pass on radius values because the points have them assigned. If you duplicate a point you also duplicate its radius you can also extract its value.
This will allow me to keep the original trunk and shape it with my shaping curve, duplicate the “above split” points and spawn them in the same way I am doing with new curves, then randomize parameters. It will be very similar to what I was doing in edit mode, with the added advantage that the radius is already set (It can be manipulated later).
I have to check this because the main problem that was getting me was “extreme” distortion displacing the splits from the stump, in the end It occurred to me to mask/culll the distortion at the root of the split.
It was an easy solution that took me days to realize! I am pretty sure I can still do the same I just have to check.
I nearly gave up and said just do it in edit mode but now I find this new concept exciting.
So the closer I get, the more I have to change but I am sure it will be worth it. 
Do not worry I will post a file within 3 days (famous last words!) 
3 Likes