Yep. That’s half the reason I wrote it in two layers. So if someone wants to play with tree generation they can worry about the meshing another time… or if they want to make better tree meshes because that’s their thing, then they can mess with that layer.
For those a little interested in those details. The SimArboreal library breaks down as follows:
Tree and Segment are the ‘tree data structure’. A tree is basically a holder for the root-level segements… whether the trunk and tree root segments or whatever the tree needs.
Segments are the parts that make the trunk, branches, roots, etc… there are convenience methods for taking one Segment and extending it out into multiple other segments. (Branching, extending the branch, etc.) A segment has a length, radius, and some UV parameters.
That’s what defines a tree.
There is an existing TreeGenerator that uses a simplified L-system to fractally generate trees based on the TreeParameters and BranchParameters. The TreeGenerator produces a Tree with Segments… which in turn have child segments and so on.
Finally there is SkinnedTreeMeshGenerator which takes a Tree object and makes a JME mesh from it:
It in turn uses a MeshBuilder which is a non-tree specific way of building meshes.
Anyway, the thinking was always that we might have different mesh generates for different kinds of tree mesh types. (For example, SpeedTree type trees have a lot of special detailing that my simple skinning approach lacks.) Or one could potentially parameterize it to switch textures/geometry at different levels to support palm trees, whatever… all from the same Tree classes.