Thanks a lot, man 
1 Like
Go on hit us up ! let the hive swarm the tree ! 
1 Like
Good news then, because I’ve decided to release the version I have now, sans one feature I really wish I could’ve implemented, but I’m gonna leave on the backburner so I can get something out before this snowstorm rears up on me, and I probably lose power for a day or two.
The manual is just about finished. I’ve got about 6 more entries to cover before it’s entirely finished. My current plan is to release it as 3 files, one HTML, one Typora formatted markdown file (this is what I use), and one Obsidian markdown file.
If everything goes well, I’ll probably have it out later today.
As for the version of Geotrees itself, it’s not brand new, with tons of extra, much sought after features (yet). It’s more a Quality of Life, all cleaned up, better organized, more predictable release.
7 Likes
What’s the one thing you’re trying to figure out?
1 Like
Ready for a paragraph or three?
I’ve had DNorman and Debuk help me out on this, and we’ve all come to the conclusion that you can only perform so many rotation operations inside geonodes until all the local axes on your instances are so skewed and screwed that they’re no longer controllable or predictable. Try any more, and you’ll either get spazzy results, or it’ll mess up something you’ve done previously.
The only way I can see to get around it is to reset the axes on the instances. And the only way to do that is to realize the instances, then perform further rotations on those. The problem is that once you realize the instances, any further rotations will treat the bunch as one single object.
So how do you get around that? Mesh islands. You set things up so that geometry nodes treats every separate, unconnected piece as their own object, provided you do all the math right.
…and I’m having trouble with the math.
I need this so I can orient the branches so they’re all tending towards one area, leaving a bald spot on the opposite end. This isn’t all that big of a deal for regular trees, but for forks, where the branches tend to grow away from each other? It’s nice to have.
Here’s a couple of links I’ve been using to help me out.
…and that’s the story of my life so far.
3 Likes
Introducing Geotrees 0.65!
GeoTree_0.65.blend (433.5 KB)
Now with a manual!
https://1drv.ms/u/s!AiaM6CyVvt2BmKdBfWsbhmAyLaoncw?e=7axujR
As usual, I’m open to any suggestions or criticisms.
edit: Manual has been updated for the Linux people.
14 Likes
Yes, I’ve had issues with rotations too. I barely managed to work around them by fitting my original instances’ orientation to the hardcoded instance rotation order (XYZ). You might be doing more operations on them that I do, and at some point it breaks because of gimbal lock. But that should not be the case anymore with the rotation/quaternion socket ? I haven’t tried it because I have rig linking issues with 4.0 so I can’t upgrade for a while, but you should really take a stab at refactoring this because I think quaternions open up many new possibilities.
This is super convoluted and kind of impressive workaround, hah! There’s the “mesh islands to instances” node in the works that should help with that, and also allow specifying the output instances’ origins. Although rotations are lost in translation (which means you can’t modify an axis on its own) it’s better than nothing. I can’t find the PR in question right now
2 Likes
It’s a good suggestion, and I imagine that it probably would solve a number of problems, but…
I don’t understand quaternions at all. I tried to wrap my head around them once before, and each time I thought I was beginning to understand them, they threw me for a loop, and did something totally unexpected.
Guess this means I’ll have to buckle down on the studying.
Me neither, I don’t think you need to at all. There’s just a bunch of new nodes that allow you to rotate stuff without running into gimbal lock issues. I would have to save the specifics for once I’ve taken a look at your file, which I managed to download by some miracle (again, undersea cables got gnawed on by sharks, or cthulhu for all I know, and it took us back to the 56kbps era).
I’m sure you know of these, but just in case… (personally they did nothing for my understanding but who knows you might grasp it better)
5 Likes
My god, just looking at the thumbnails for those videos makes my head hurt.
If this is what it means to be an artist these-days I’m starting to think I should break out my old tin box of Faber-Castell pencils and russell up some textured paper and go sit quietly in the corner…
3 Likes
It’s kinda like you’re rotating the three euler coordinates along a 4th extraplanar point, which means it’s kinda like a combination of local coordinates inside of global coordinates, but really it’s not.
Anyway, I decided to finally get around to retaking some high school trig courses again.
Ha ha, well 3d is sort of a mix between art and brain teasing!
1 Like
@Renzatic Only had a very quick look and this new version and not looked at the manual yet. Just wanted to quickly ask about the anime version of the leaves
Did you intend to make its own leaf node that you use instead of the current one?
Dose the old part of that code work with your new nodes because i could probably figure out which part of the code to chop out and make its own node group from the old version
1 Like
Yeah, I plan on adding it back in eventually, along with the UV mapper.
Though if you want to do it yourself in the meanwhile, the newer layout is actually easier to deal with, since you don’t have to delve deep into the node tree, then start moving things about, or cutting things out. All you have to do is remove the leaf node, then build one of your own that distributes spheres of various sizes across the spawn points, which are all fed from the points outputs on the trunk, forks, and branches nodes,
Hi. Is this nodegroup capable of achieving results similar to what is mentioned in this talk? Maybe it will also serve as a reference for you.
4 Likes
I’ve looked at using l-systems for the trees before. It produces great results, but it doesn’t give you quite as much control as the setup I’ve got.
Though I might use it for the roots. We’ll see.
Anastasia Opara doesn’t use L-systems; in fact she discarded them early on in her explorations because she found the rules too rigid.
She uses, umm, I guess one could call it “biology”, actual factors that go into how trees grow.
4 Likes
I’m following the “this is basically how a tree grows, so I’ll do X, and if it looks good, then yay” approach to the problem. It’s netted me some decent results thus far, and it’s a good fit for the more stylized trees I like, but I do have a long way to go before I could say it can produce very realistic trees.
5 Likes
Hi @Renzatic . I’ve been using your node group and it’s great, I shared some tests here. JoelRVC Sketchbook - #3 by Joel_RVC
By the way, I have a suggestion, you may already be aware of it. When you want to create a forest and you generate instances of the tree, there are problems in shading with the normals of the trunk.
Since they are normals captured before scatter the instances, they remain frozen and move with the rotation of the instances (which should not happen in this case) and that results in shading errors in the instances.
-This shouldn’t happen
-something like this yes
In one of the @Ascalon videos I saw that an alternative is to convert these normal (which I assume is object normal) to world normal, I tried doing that by connecting a vector transform node after the attribute node in the trunk bark shader, like this:
It gave the results I expected and the shader worked as it should on the instances.
It gave the results I expected and the error disappeared.
From the video I understood that world normals are generally rarely used since they are only for static objects, which works here, but I did not test if it would work in case of animating the branches. Even so, I wanted to tell you about this use case and as an added suggestion in case you need it.
6 Likes