A new tree add-on part V: speeding up skinning of the tree skeleton

one of the issues that bothered me about my new tree add-on was that applying the skin modifier to flesh out the branch skeleton was incredibly slow, especially for larger trees. I therefore decided i'd try writing my own skinning routine and the results are quite promising: a factor 10 or more for moderately sized trees.


The new version (0.0.7) is as usual available on GitHub. How to use and install this add-on is documented in previous articles: I II III IV.
The new skinning method is the default if you uncheck the no modifiers checkbox but if you like you can still select Blenders skin modifier from the drop down as shown on the right. (This can also be done later because we leave the skeleton itself intact; as it only consists of edges it won't show up in renders but you could use it to add any modifier later on).

Timings

The table below lists some timings for my computer, all values were left to their defaults except for the number of endpoints:

Timings in seconds for generating a tree skeleton
Endpoints	No modifier	Own skinning	Blenders skinmod
100	0.02	0.04	0.46
200	0.04	0.07	0.74
400	0.08	0.16	1.51
400	0.56	0.87	14.43

The last line shows the results for a fair sized, bushy tree (400 endpoints, but with the internode length and kill distances reduced to 0.5 and 2.5 respectively and with 3000 extra endpoints per 1000 iterations). The difference between less than a second and more than 14 seconds is the difference between comfortable modelling and frustration, and there is still some room for improvement because the code is still riddled with print statements.
There are three factors that help to speed up the skinning operation compared to blenders built-in skin modifier:

• unlike the modifier we do not have to make a copy of the mesh,
• we also generate a lot less geometry it seems and
• we don't have to deal with special cases: the skin modifier can handle any geometry while our skinning just has to deal with straight edges or simple forks.

Results

When we apply a subsurface modifier to our skinned branches the result is already quite acceptable although I see room for improvement, specifically in the shape of the forks. As you can see there is some bulging were the branches join and this is especially noticeable when there is either a very sharp anngle between the branches or when both branches bend out of plane. Fortunately the highlighted 5-gon lends itself to all kinds of angle dependant adaptations so I expect I can tweak this further to get smoother results.
The focus for the next minor release will be on bug fixing and code cleanup to prepare for a full 1.0.0 release. This will be accompanied by better (hopefully: -) docs as well.

A new tree add-on part IV: adding objects and fixing bugs

version 0.0.6 provides new functionality to add additional objects to the tree besides leaves. This might be helpful in creating trees with blooms or fruit.

adding arbitrary objects

If you click on the add object button you can not only select an object to duplicate but you can also set a number of additional parameters that control the distribution of this additional object analogous to the parameters that control the distribution of the leaves. [Sorry, no sample image yet. The code is, as always, available on GitHub ]
Check for earlier articles in this series the archive section in the sidebar on the right.
Besides this extra functionality version 0.0.6 fixes two bugs: selecting a saved preset might give an error so now we exclude the various group properties from saved presets (after all a named group might not exist at all in another scene) and in certain situations many identical internodes might be produced. This is not only difficult to skin but results in bunches of leaves as well. This might be a flaw in the original algorithm that we solve by checking whether a new internode doesn't occupy the same position as any existing one.
That last one is tricky and happens when a newly calculated branchpoint is not within killing distance of the endpoints originally directing it and further away from those endpoints than the original branchpoint causing the same branchpoint to be generated again each iteration. I've illustrated this situation in the diagram below:

(original branchpoint in red, new branchpoint in purple, endpoints in green. Here the original distances (purple lines) are larger than the kill distance and the new distances (blue lines) even more so.) I wonder if there is a better way to prevent this than just increasing the kill distance (which would result in a very sparse tree) or checking a new branchpoint against all previous ones like we do now (which is quite expensive and rather inelegant).

A new tree add-on part III: multiple trunks

Version 0.0.5 of my new tree add-on adds functionality to specify a group of starting points facilitating the creation of hedgerows or twinned trees.

multiple trunks

When you want to create a hedgerow or a small copse of trees combining multiple trees might not lead to an acceptable result because branches might cross and the shape is not quite the way you want it to be. Also the amount of work needed to create a hedge of thirty plants can add up. I therefore added the possibility to define any number of starting points by refering to the locations of objects in a group.

Part of the scene setup used the create the example image is shown on the left. 
The empties (represented by the green cone shapes) are all in the same group and their locations are used as starting points.


The parameter settings were as shown on the right.  As usual the code is available as a zip-file on GitHub. More info on how to use the tree add-on can be found in two previous posts: A new tree add-on and A new tree add-on part II: better workflow

Future directions

I noticed that the mesh created by the skin and subsurface modifiers contains not only a huge amount of faces but also contains quite a precentage of vertices (20% or so) that are so close together that they practically overlap. Generating such a mesh takes a considerable amount of time so I think I will try to come up with a skinning method that is suitable for our tree trunks but hopefully somewhat faster.