The rigged trees can easily be animated with keyframes, such as to push branches aside upon collisions with passing objects, vehicles, or large animals.

The optional wind sway animation is a fast and lightweight alternative to the existing Wind Shapes tool. A mild turbulence together with breeze animation on the twigs can get you great results, with just a very few bones for the trunk and main branches.

You can also simply use the skeleton to pose the tree, by rotating bones and moving around the attached branches.

The skeleton can also be used in game engines. Just make sure to heavily reduce the number of bones to keep the performance high. You’d be surprised at how just a few hundred of bones can do the trick even on bigger trees.

Controls

The trick is to create the least number of bones that you can get away with, and it starts with the Reduce parameter that increasingly skips adding bones to thinner branches. Depending on where you want the tree to deform most, you can use the Bias parameter to create more bones either up high in the crown or down at the base of the tree. The thicker main branches that are included in the skeleton are sliced into equal pieces controlled by the Length parameter.

The Connected option is designed for exporting trees to game engines or software like Houdini. Each 3D program implements skeletons differently, and many require a connected hierarchy of bones. Blender, however, supports separated bones that aren’t directly connected to their parent, enabling an even bigger reduction in the number of bones.

After all these optimizations, the small number of bones is super optimized and so performant that the skeleton can even be used in game engines. Mind you, the Grove expects you to know your stuff when you want to export trees to game engines; it does not provide support for direct export to known game engines, so it will take some expertise to integrate this into your pipeline. This is, however, something I want to work on in the future.

Faster by 50%

A pattern is emerging where one release focuses on simulation and the next on optimization – now it’s time to squeeze every last drop of performance out of the code!

During the simulation, the Grove draws a yellow-and-red sketch in the viewport that shows the progress of how trees grow through time. When growing big trees, or many trees at once, it could take more time to draw this preview than it took to run the simulation.

The solution was to move the draw code from Python to the high performance core and to reduce the number of draw calls. Drawing the sketch is now nearly instantaneous and, given that this was a considerable part of the total time taken each year, this makes the entire growth cycle run a whopping 50% faster when trees grow older!

Faster tools

Since the simulation has become so fast, there were two tools that were lagging behind — the Draw and Bend tools. This release fixes the laggy interaction and makes the tools super fun to work with! I hope this will inspire you to experiment more with the tools, and get real creative.

More and more game studios are using The Grove to grow realtime trees. Surprisingly, because the focus has always been on as much realism and detail possible. It always felt like a step backward to optimize trees to a level of detail suitable for games but, to be honest, it’s pretty cool to experience trees in an interactive environment. So in this release we’ll tackle the biggest hurdles for games.

Level of detail

To get down to the level of detail for games, we’ll have to aggressively optimize the mesh to reduce the number of polygons while keeping the tree character. We found that that there’s surprisingly little to gain by reducing the geometry of the trunk and main branches – instead where it really counts is in the thousands of small branches that grew in the most recent years. Replacing these with progressively bigger twigs reduces the number of polygons significantly – a tried-and-tested way of optimizing game trees. The trick is to find the optimal point to cut the end of the branch.

Cutoff thickness

Cut of thinner branch ends using the branch diameter to consistently fit a certain sized twig, and allows for an incredible reduction. It works great for conifers and deciduous trees of all sizes. You can build several LODs by using increasing sizes of twigs. The Grove’s current offering of twigs are way too detailed for these types of twigs, but they are a great starting point to (manually) bake down to low poly leaf cards. Creating game foliage is so different from the usual detailed twigs. Perhaps a short baking tutorial is in place?

Cutoff age

Use the node age to cut off the most recent years. This works well up to a couple of years, but not so well for older trees and also conifers whose lower branches grow slower, which means that a much longer and thicker part of the main trunk is lost before the fine growth below is reduced.

Blends

We already got the biggest reduction by using the thickness cutoff, but there’s still a lot to gain by skipping blends, the smooth interpolation of branches. This transition from the main to the side branch requires a couple of extra nodes which quickly add up to many thousands of triangles, mostly for the thinner branches. No worries, we won’t be skipping the blends of thicker branches, and the foliage in twigs will hide much of the blends anyway, while the polygon count will absolutely plummet! You might even want to use this on regular, non-game trees.

End caps

There’s more to gain on the thinnest of branches, where we can skip building end caps, while keeping the thicker cut branches closed. Depending on the tree’s foliage and how close the player can get to the tree, you may not even see the difference. But this optimization works best for the highest level of detail, simply because there will be more end caps to skip.

• Best of all, these new optimizations were developed to work seamlessly with the new skeleton! You can build the tree in several levels of detail, and all of them will work on the same skeleton.
• The effect of Build > Detail > Resolution > Reduce kind of stops at 0.8 for a normal build, but with a thickness cutoff the remaining branches are much thicker and it has a massive impact at 0.9 or 1.0. Great if the trees are to be used in realtime engines.
• In the above example tree, the twigs are a simplified, baked down version of the European beech twig. I added a Realize Instances node at the end of the geometry nodes for the twig duplication modifier.

Seeds

Trees can now reproduce by scattering seeds, so as to simulate a naturally spreading forest, whether through seed dispersal or by sprouting new trunks from the root system. Let’s explore this new feature and its parameters… In the interface you will find Sow as a new feature panel that you can enable, similar to Auto Prune, Stake, Surround, React and Record. Sow works well with all of these existing features, and it is a a great extension to the Plant tool.

For some tree species, the Plant tool is the most natural starting point from which seeds provide a logical extension. Forests of eucalyptus and conifers often regenerate en masse after a forest fire raged the area, and species like lodgepole pine even need the blazing heat of fire to open up the cones and release their seeds, which is why lodgepole pines form same-age stands very much like the artificial plantations of modern forestry. So start with a couple of trees in the plant tool, then let nature find its way.

Sow is now one of the many steps in the simulation loop, where it dynamically adds new trees and removes dead trees over the years. While you grow, green dots indicate where a new seed germinates, and red dots indicate a dead tree.

Parameters

It takes several years for a tree to take root and establish an energy positive state before the tree starts to produce seeds. This can be as little as 5 years for apple trees, but for trees like oak it can take decades before they start to produce acorns. The Delay parameter controls this time of delay.

Because of the exponential nature of reproduction, the number of trees can quickly grow out of control. In reality some trees sow thousands of seeds, leading to the germination of hundreds of new saplings every year, but (luckily) almost none of these make it, and the ones that do make it get eaten by deer when they leaf out in the next season. In the end there’s only room for one tree to replace the spot of the existing one… And as the number of trees is already hard to simulate as is, use the Chance parameter to control the number of new trees, and set a Limit to the number of trees. This keeps the simulation under control.

Apples don’t fall far from the tree, and so new trees tend to grow pretty close to their parent tree. The thousands of acorns also drop inside a small radius of the parent tree, but some get stashed by animals, extending the range. Maples use helicopter wings to propel seeds over longer distances. Use the Distance parameter to set the scattering radius.

Visible branch radius

The Grove’s polygon reduction technique works most effectively on the thinnest new growth, where reduced thickness correspondingly minimizes the number of points in its circular cross-section. This elegant principle helps computers efficiently manage the hundreds of thousands of small branches that compose a grove of trees.

However, when using just a few points to describe a circle, a deviation occurs in the visible thickness, which makes branches appear thinner than they really are. With just 3 points to create a circle, the visible radius when viewing the branch from all sides ranges from 75% to 87% of its actual radius — an average 20% thinner than it should be. And the maximum deviation is even worse for a 4-point circle, at a whopping 30% thinner.

In short, polygon reduction made thin branches appear thinner than they actually are. This release compensates for that deviation while building the mesh, which gives your branches an even more natural appearance.

The above image sequence shows how close the new compensation gets to the ground truth, whereas the old behavior creates branches that are too thin — although subtle, you can clearly tell by the increased brightness of the overall image.

Long and short twigs

Previously all branches would be extended by an end twig and side twigs were placed alongside. To build more detailed trees and to improve twig placement, we now distinguish between long twigs and short twigs. This means that slow growing branches can get a short twig at the end, and fast growing side branches can get a long twig instead.

And for even more detail, instead of extending a branch with a twig starting at the end, we can now replace the last nodes of the branch. Depending on the length and orientation of the latest years of growth this can result in either a short, long, upward or dead twig. The same applies to a side branch – if it’s just a year old, replace the entire side branch by either a short, long, upward or dead twig. This can improve the twig distribution especially for apically dominant trees like Douglas fir or apple trees with their very short side branches.

For now this new behavior is optional and a work in progress – to enable it use a Build > Detail > Cutoff Age of 1 or more and rebuild. Sometimes you’ll want to adjust the simulation scale to match the preset better to the twig size. In theory you can still use the twig density slider to controlt the foliage, but when using a cutoff age, it should realistically be set to 1.0. Overall this gives a more detailed and aged look to trees.

Backward compatible

This is a tools-and-optimization release with no changes to the simulation. That means you can copy over any presets you made from the 2.1 release and they will grow the same.

And it gets better, because the Grove is now backward compatibility at last! We can import .grove files from older releases and edit existing groves in older Blender files. For example, on existing older trees, we can continue to prune unwanted branches, tweak the twigs, rebuild, add wind effects, change the bark texture and even add the newly introduced skeleton. However, be aware that, when you continue to add new years of growth to much older trees, the simulation may have changed too much for the tree to retain its original character.

JSON

Starting with release 2.2, The Grove fully embraces JSON for storing presets, configuration and simulation data. This means that the format of presets has changed. If you copy over old presets from release 2.1 to the 2.2 presets folder, the Blender add-on will automatically convert them to the new JSON format. This functionality is temporary and will be deleted in release 2.3.

If you’re interested in the technicalities of these changes, for example if you are automating growth with Python scripting, you can read more at JSON.

Breaking changes

• Blender 4.2 LTS is now the minimum version that can run The Grove.
• Important change: the attribute names in Blender are now the same as in Houdini, in snake case with the gr_ prefix to prevent name collisions. Side and end twigs are now called short and long twigs, and the attributes are gr_twig_long and gr_twig_short. Update your materials or geometry nodes if you made use of any of these attributes.
• Important change: in Houdini, the gr_twig_side primitive group is now called gr_twig_short and gr_twig_end is now called gr_twig_long. Change your twig scattering nodes accordingly!

Structure

The 2.0 release moved most of the Grove to a compiled module — super fast, but as I gathered from your feedback it made the packaging and installation frustratingly complex. With the 2.2 release I hope to fix that with a completely new structure, to again make it easy to install.

The Grove Core is now the main package and when unzipped it has a structure that is ready to be filled with the twigs, bark textures, presets and add-ons. This is the suggested structure that will work great for most users.

When you extract the Blender add-on package to the addons subfolder, the Blender add-on will automatically find the presets, bark textures and twigs folders in this new structure, shaving off several steps in the installation.

The structure and installation of the Houdini add-on has also changed a lot to make it so much easier to maintain. The add-on is installed in the same addons subfolder, now using the same Core module and presets.

To learn more about the structural changes, check the Structure page.