Working on version .02 right now. I’m hoping this will be easier to use and customize. Only got the twig done so far, but I’m hoping that once it’s done, I’ll be able to mix and match all kinds of shapes and leaves to create any semi-stylized tree you can imagine.
I’m also going to try and ape some of @Charles_Weaver’s style for the trunk. Try to find a way to draw a spline that groups multiple thickened and randomized splines together into a gnarly looking old tree.
Here’s a good shot of my previous attempt with half the leaves gone to show the underlying branches. It’s about 190k tris with everything together, which I’d say is fairly decent.
Here’s an asset that you guys might find useful when working with bezier splines. I for one find it difficult to work when you can’t see the very handles you are manipulating. Work with invisible handles no more!
It’s set up with four color coded materials that work right in the viewport, so you can distinguish the different types of handles. You can quickly disable the entire group with one click, and it won’t show in the final render even if it is enabled.
I hope you find it useful! It’s already marked as an asset, so just drag it into your library folder and get started. The file contains a demo scene if you would like to see how to use it.
It produces everything in tiers, using splines to build up the objects from twigs to the entire trees.
The twigs are a number of splines, one used for the twig itself, and the others to act as paths to generate the leaves. The branch node places twigs around the base spline in a rough spiral, and the limb places the branches in much the same way. The trunk branch places a variety of limbs around your trunk in a similar fashion.
I’m trying to make it so that you don’t have to get down into the nitty gritty of the geo nodes to create a ree. If you want to see how it works, detatch all the nodes from each other, grab a twig node, set it up, and play with the settings, then attach it to a branch node, do the same, then work your way up from there. Follow the example tree to see how I set it all up.
Hey, anyone want to post any feedback on this? I’m working on hopefully simplifying some things (and making other parts a little more complicated), and I’d love to hear some opinions.
I do, in fact have some feedback on the matter. I hope you don’t mind that it’s a bit critical.
I’ll start off by saying I didn’t get a lot of time to study it this last week, but I think I’ve toyed with it enough to find the higher level strengths and weaknesses.
Let’s start with the good news:
Beautiful results in both E and C
Renders quickly, pretty much instant feedback in the viewport
Looks good from all angles
Most noise seeds give a good looking result
Bark texture follows geometry very well
However, there are some things to be desired:
Difficult to get varied results from system, most combinations end up looking similar
Difficult to iterate through multiple patterns quickly (the primary advantage of proceduralism) and requires tweaking values back and forth to get a desirable results
Structure of the system seems a bit strange to me (more on that later)
I recommend taking it one step further and making it even more modular.
Such as creating separate groups for:
Leaf generation
Branch generation
Trunk generation
Root generation (something we never thought of in the past, which could take it to a whole new level)
Additional effects (moss, ivy, fungus, etc)
Also, the structure could be a bit more logical. Rather than plugging a top bottom and middle branches into the trunk and setting sizes manually, find a way to generate the falloff mathematically (through exponents of some sort) ,and put them in a more convenient order. For example, have a trunk gen that outputs a set of points for distributing branches, those branches output twig points, and so on. Maybe tomorrow or later I can give you some visual examples of what I mean.
Overall, the results are great so far, and I think it has some serious potential. I’m exited to see what will come out of this!
This is one of the main things I want to fix. Right now, it applies the branches in a philotaxis spiral, with a bit of adjusting here and there. I want more randomization from it. Like pushing some branches a little closer together, skewing some branches just a bit off the usual spiral, or removing some entirely.
Nothing I’ve tried gives me good results yet though. I did try to use that point distribution setup you posted in the other thread, but that just ended up fugly looking.
Also, I need to set it up so that it places branches along an underlying mutipoint spline, rather than using the vertices from the generated geometry.
I still need to do a lot there too. It’s good for bushy leaves at the moment, but it still needs more. One thing I want to do is make it so that all the leaves droop like they would on a real tree, with some randomization here and there to break things up. Really, I don’t feel like I have enough control over the placement of the leaves.
That’s not too terribly difficult (at least if you want a tree without any real forks in it. All you have to do is take the branch node, aim it upwards, and distribute the limbs from there. Though personally, I want to leave that part somewhat manual, since I think ploping splines down and mixing them together gives you more granular control over the shape of the tree itself.
Oh, most definitely. We need roots!
You can somewhat do that now. If you look in the trunk node, you’ll see a few float curve nodes attached to the scale output on the Instance On Points node that can do just that. Originally, I just made it a semi-linear curve, but now I’m thinking about exposing it outside the node, so you can tweak the profile of the trees.
Though I still like the tree tiered setup, because I love being able to mix and match. Also, if you were to rely entirely on using curves to adjust scale, you’d end up with branches at the top and bottom with super tiny leaves, which looks kinda goofy. That’s actually one of the reasons why I created those three extra nodes.
For now, this is where I’m at after some slight tweaks, and a couple extra settings here and there. Among other things, I’ve set up some slider limiters here and there, so you can’t pull some settings so far out on the positive or negative that you end up overwhelming and crashing blender.
Once I can use this to not only make the usual bushy trees, but also oaks and pines, then I’ll say it’s pretty decent. I’m almost there for the pines, but I need some improved branch generation before I can do it fully.
Oh, and I need to expose UVs on the graph as well. That’s one thing I’ve been putting off for awhile now, since I can just tri project the bark texture onto the trunk and branches.
Another concept to consider would be to take a custom cage mesh (manually edited and shaped) and use proximity to generate branches out to the edge of the mesh.
I’ll have to look into methods of doing this, and if it’s even possible with the current system, but if it is, it would be a great way to give a lot of control over the shape, while maintaining procedural abilities.
That’s not a bad idea. The only problem with it I can see is that it might introduce too many extra steps to the creation process.
We could probably add that as a further customization option, maybe. The trees aren’t totally reliant upon you building a cage, but it’s there if you want to do something more specific.
Of course! That’s another part of increasing modularity.
Prefer sculpting a cage? Use the “branch distribution cage” node. Rather use sliders for more precision? Use the “branch distribution values” node.
This goes for anything. For example, if you leave the leaf type open, one could choose between a realistic leaf generator or billboard blobs.
Splitting larger tasks into lower level nodes means more flexibility in general. If the system if fairly consistent, it would be relatively easy to make new generators for each component that fit seamlessly.
You already have some of that in your latest iteration. I can only imagine what it would be if it was even more modular!
So I exposed the float curve that controls canopy scaling, and made a video showing how it works.
Next up, better leaf distribution, and some more limb randomization. Maybe some possible considerations for cleaning things up as well, because it’s getting a little crazy with the nodes upon nodes upon nodes nested in nodes.
Edit: This just popped up in my Youtube feed. Looks like we have some competition we’ll need to beat up.
I’ll check that out when I get home. See if I can incorporate it in.
Also, when I get back, I’ll probably upload the latest mini version of the trees.
Edit: I’m home! And with less blood in me than what I had when I left!
Alright, here’s Geotree v. 0.257. Now, I’m gonna check out your cage work, see what I can do with it. By the way, I had to make it a .7z for the board to allow it to upload.
edit: Quick heads up. For some reason, one of your custom nodes shows up empty when you load it. I figured it was similar to that random distribution setup you showed me in that other geonode thread. You might want to turn on Automatically Pack Resources.
edit: I’m thinking a variation of this might be a good combination of both our approaches. I’m gonna goof around with it, and try it tomorrow.
I’m still trying to split the difference between randomized and manual generation. Here’s basically what I’m wanting to do.
…it helps me to spell this stuff out in my attempt to math it up.
All limbs will be generated inside the canopy cage, spawned off the generated points on the manually placed trunk spline. The splines the limbs will be generated from will adjust their length according to the radius of the canopy cage. My idea is that they’ll grow out from their origin points until they touch the face, then terminate.
So, in digest, I need to find a way to generate spawn points exclusively along the part of the trunk spline inside the cage, then find a way to grow the splines out until they touch the faces of said cage.
End result will be starting out with something like this:
If anyone wants to point out that the radius of the cage doesn’t exactly match the trees, comeon, this is just for demonstration purposes. Shuddup.
So off to take apart your model, and spend some time in the Youtube grind!
edit: Thinking about this after looking at your cage trees a bit. The start point of the limb splines will start at the trunk spline, the end point will then grow out at a random, though upwards on the Z axis, towards the geometry of the cage, then stick. Kinda like a reverse shrinkwrap. Then we could add points between the start and endpoints to randomize the shape, and spawn branches off of.
That’s kinda what you did with your geometry proximity node, though that confines the endpoints to the shape of the cage, rather than acting as a sticking point.
I’m also thinking maybe a raycast node would work here somehow. Man, I wish I knew more about this stuff.
With Special Thanks to Meru over at the Blender Discord server.
This is what I’ve got after a couple hours of goofing around with it. There are still a few things I need to do, but haven’t yet quite figured out with this new setup.
First, I want to make it so that points only spawn within the canopy cage. I tried combining josephhansen’s And gate using the base geometry hooked up to a Bounding Box node to set that up, where everything inside it is 1, and everything outside 0, but I haven’t been able to get it to work. It makes me think that I need to learn more about the basic attributes, how to expose them, and how they work together, cuz right now, I seem to have the basic geonode logic down, but I don’t quite understand the verbiage and syntax and as well as I should.
Secondly, I can’t seem to get the individual branch scale curve to work with the raycast setup. Dunno why exactly yet.
(Oops, hit ctrl+enter. Stupid slack is getting me in the habit.)
It looks like you’ve got something going. If you could find a way to slide the branches up to a higher point on the source(by somehow manipulating the source vector), that might do the trick.
P.S:
I didn’t think much of it when I started the thread, but “Trees” may a bit of a poor name for a thread heavily specialized in the creation of procedural trees in blender geometry nodes. Should I change the name to something more descriptive, so this thread can get the attention it deserves? What should the project be named?
