A new Tree addon, adding functionality

Compoared to the previously documented features this new version (0.2.5) adds a preliminary version of apical control and a 'Leaves' vertex group.

Code availability

Downloaf the installable .zip file from GitHub and read the installation instructions carefully, especially if you have installed an earlier version.

Apical control

Apical control (or apical dominance) is the phenomenon where buds on the end of a branch supppres the developments of bufs lower doen the branch. Often this will lead to trees with straighter branches and less side shoots. This versions contains a preliminary version but because I'm not quite satisfied with it yet I won't elaborate on it.

Vertex weights

The generated tree now has a vertex group called Leaves. It has more weight near the end of the branches and the clustering can be controlled with the leaf clustering option. (As shown in the image below for a value of 1.0, 4.0 and 8.0 respectively). In the future we will add a ;eaves particle system as an alternative to the mesh leaves and the density of this particle system will be controlled by this vertex group. Of course you can now use this group yourself if you configure a particle system by hand. Note that without a skin the tree mesh consists only of vertices and edges (no faces) so the weights are not visible in weight paint mode although they are there. With a skin (either our custome skin or one generated with Blenders skin modifier there will be faces and the weights will be clearly visible (the skin 'inherits'the weights from the tree skeleton in both scenarios).

A new tree addon, revisited

It has been a while since I worked on the new tree addon so I thought some attention was due.

Over the last six months or so my thoughts did keep coming back to the speed of the space tree addon. We already got quite some speedup from introducing kd-trees to store the branchpoints but still it felt kinda slow.

A time complexity analysis is difficult because the number of branch segments grows while the number of endpoints either falls (when branches come within kill distance) or rises (when they are added at random while generating new branch segments) but what was clear that we calculated all branchpoint/endpoint interactions for each iteration anew. And with the number of branchpoints easily rising to hundreds if not thousands and the number of endpoints initialy amounting to several hundreds this adds up quickly, especially because calculating a branchpoint/endpoint interaction is computationally expensive.

This new version takes care to recalculate such interactions only when necessary: when adding or removing an endpoint it recalculates things only for the branchpoint to which it is closest and when adding a branchpoint it checks which if any of the endpoints is now closest to this new branchpoint and does the necessary calculations only for those endpoints.

The resulting speedup is tremendous: A moderately sized tree with the settings shown below takes 76 seconds to generate the branch skeleton on my machine, while in the new version it takes just 0.6 seconds! These two order of magnitude mean that I am tempted to remove the update button and return to truly interactive modelling, however, skinning such a tree takes still considerable time: almost 5 seconds with Blenders skin modifier, way too slow for interactive modelling (I didn't yet compare my own skinning method).

max. iterations2000
no. of endpoints500
internode length0.35
kill distance0.51

Code availability

I have not commited this new version to the addons-contrib repository yet because I want to test it some more (the changes in the code are quite big) and because I discovered a bug in Blenders skin modifier that this addon can trigger (edit: wow, that is fast, fixed almost immediately!). Nevertheless, this version is available for the adventurous on GitHub, just make sure you read the installation instruction posted there (important if you use a Blender daily build because then the old version of the addon comes bundled and needs to be removed).


A roadmap might not be the correct term as it implies some form of commitment I cannot possible pledge to a hobby project but nevertheless i'd like to present a list of things I have in mind for the spacetree addon.

None of those items might see the light of day and the order in which I might tackle them is not certain at all but it might give end users some indication of thr direction I'd like to take the addon. It also functions as a worklist that I can use for myself to tick items off.

  • [done] correct radius (and positioning) for native skinning
  • interactive/manual update switching based on elapsed time
  • twigs
    final extra branchpoints not controlled by endpoints
  • [done] implement 'influence' option
    restrict the range within endpoints can exert their influence
  • branch angle control
  • better leaves
    • [done]better geometry (a small group of low poly leaves)
    • [done]vertex group w. weights based on connectivity (or its reverse, tips have more leaves)
    • [done]a default particle system (as an alternative to placing leave objects)
    • [wip]some default leaf shapes (alpha masked textures, freely distributable, so I'll need to make my own once it is springtime again)
  • [done] experiment with blended box mapping material for branches, include seamless bark texture). Blended box mapping didn't work out that well but a material based on a normalxtangent based coordinate system works quite well (see BlenerArtists thread). Code and library are in place, but with a placeholder material for now.
  • [wip] apical control
    control the suppression of side shoots lower down branches. (I have a rudimentary implemenation in place but it's not quite what I want yet)
  • branch shedding
    control automatic pruning of branches that receive little light
  • endpoint distribution based on rudimentary mesh
    distribute endpoints within some radius around the edges of a mesh to 'draw' a basic shape of a tree
  • better display of timings
  • [done]uv subdivision

Simulating erosion in Blender part V, a rain map

It is time to finalize the necessary features of the addon before giving the erosion algorithms a close look again. This new revision (0.0.2) of the addon sanitizes the UI a bit and adds an option to control the distribution of the rain.

New options

The way we distribute rain over the mesh has changed a bit. Instead of just a uniformly distributed amount with some local variation it is now possible to use a rain map. If the option Use rainmap is selected the local amount of rain is multiplied by the weight of the active vertex group (if there is no vertex group, the option is grayed out). So for each iteration the amount of water raining down on a single vetex position is given by
Ka * weight * (1 - Kv * U)
where U is a uniformly distributed random number.

The whole idea is that we can use such a weight map to create a side of a mountain range where it rains relatively more due to prevailing winds or to mark a spot on the side of a hill as a well spring.

Note that the amount of rain Ka has a soft maximum: the slider will stop at 1 but you can type in larger values by hand. Also note that the weights of any vertex group but the active one are set to zero. This is an unfortunate byproduct of the way we calculate the mesh. So if you need different vertex groups later on, for example to control the density of a particle system that generates trees, you should create them after you're finished with the erosion calculations.

Another option that was added is mesh statistics. If checked it displays a panel with some height and slope statistics of the mesh.

Code availability & feedback

The code is available as an installable .zip file on GitHub. You can install it as a Blender addon by choosing File->User preferences->Addons->Install from file and selecting erosion.zip. Don't forget to enable the addon. The package is dependent on Numpy and having Numexpr and Psutil installed is recomended (the first for serious speedup, the latter for accurate timings, see the opening page of the erosion repository for more info). After the installation the addon is available if you select an object in the 3D View and choose Object->Erode.

Note that if you have installed the erosion addon before, reinstalling it might not get rid of all files in the previous installation. You might try to restart Blender after reinstalling or, if the old version still seems to be there, get rid of the installation directory (typically Your Blender Install Dir\scripts\addons\erosion) and install from scratch.

Besides commenting on this article it might be interesting to check out this BlenderArtists thread.

Previous articles

Articles in this are labeled with the tag erosion. The list up til now consists of: