In this tutorial we will create a growth model for a crown architecture. The model considers only the branch structure, without leaves, to provide an easy entry point. It may be helpful to understand the basic RGG code structure first, a tutorial is provided here.

The model is based on an annual scale, meaning that each run of the growth function simulates one year of growth. This way of simulating a tree in GroIMP is only one of many, and this tutorial focuses on understanding the development.

As mentioned above, the model only considers the branching structure. Therefore it needs only two organs, shoots and buds.

In this tutorial, a shoot is always an annual shoot, i.e. the part of a branch that has grown in one year. We do not take into account the bending of a shoot, so we can describe a shoot as a cylinder.

In GroIMP, our shoot will therefore be a module that extends the turtle command F, which draws a cylinder.

module Shoot extends F;

Each bud considered in this tutorial will generate a shoot, as the other organs that emerge from buds are not considered in the model.

In our GroIMP model, a bud is represented by a small sphere. This means that our bud module extends the sphere object with a parameter for its diameter.

module Bud extends Sphere(0.1);

In this model we assume that the simulation starts with a bud. Of course in reality it would start with a seed, but for now we will keep it simple.

As described in the code structure tutorial, the initial state of the simulation is described in the init function. In this case we replace the axiom of our model with a bud.

protected void init ()
[
 Axiom ==> Bud;
]

Looking at our two organs, we can define our very first rule: a bud becomes a shoot, or more precisely every bud becomes a shoot. Writing this in an XL query is quite straightforward: Bud ==> Shoot . But with this rule the fun would soon be over, because we can only apply our rule once, after that there are no more buds in our scene.

This means that our rule has to be a bit more complex, not just for fun, but to keep up with real plant growth. In many cases a bud will not only produce a shoot but also new buds on the shoot. Our example tree will have a bud right at the end of the shoot, this bud is called apical and describes apical growth. So our rule is really every bud becomes a shoot and a new bud.

As an XL query this can be described as Bud ==> Shoot Bud and in our model we can now create a first growth function:

public void grow ()
[
 Bud ==>Shoot Bud;
]

Applying our new rule three times would always replace the bud with a new shoot and a bud, leaving the old shoots underneath the bud untouched. The yellow bud turns into a yellow shoot and a red bud, the red bud then turns into a red shoot an a green bud and so on…

With our newly created model we can now create a chain of shoots step by step, basically a branch . However, the growth of our model is completely linear and therefore quite unnatural. Even for a very simple model we would like to add some decrease in the length of the shoots over time, as we know it from most trees. So we would like the behaviour shown in the figure below:

Formally, we want our bud to produce a shoot that is shorter than the shoot below it. This leads to two problems: firstly, how can we define the length of the shoot, and secondly, how can the bud know this length? A first step brings us back to our organs. A shoot is no longer just a cylinder, it is now a cylinder of a certain length. In GroIMP we describe this as follows:

 module Shoot(float l) extends F(l);

This describes that a Shoot can handle a float parameter and also that this parameter is passed to the turtle command F as a length. This would allow us to do XL queries like : Bud ==> Shoot(2) Bud , which would produce shoots twice as long as before. This solves the first problem. For the second, we will look at our other organ, the bud. Since the bud creates the shoot, it makes sense to let it “know” the length of the shoot. So we add a new parameter to our bud organ:

module Bud(float len) extends Sphere(0.1);

This parameter is not used in the bud, it is just stored as knowledge (a variable).

Assuming that the length of all shoots is still 1, the initial rule would be Axiom ==> Bud(1)

and our growth rule

Bud ==> Shoot(1) Bud(1) .

In addition, we can use the parameter of the bud as information for the rule:

Bud(x) ==> Shoot(x)Bud(x)

This means that each bud in our model is now replaced by a shoot the length of that bud. And the same for the new bud. Finally, we can simply reduce the size for the next generation:

Bud(x) ==> Shoot(x)Bud(x*0.8) This means that if the initial (yellow) bud has a length parameter of 1, the yellow shoot will be of size 1, but the red bud will have a length parameter of 0.8. So in the next step the red shoot will be of size 0.8 and the green bud will have a length parameter of 0.64…

Even so our little model improves, it can still only grow in one direction which is quite untypical for a tree. Therefore we will now add new shoots on the side of our main branch (stem). The image on the right shows what we would like to see after two growth steps.

Knowing that our first rule is turning a bud into a shoot and a bud allows us to estimate what the first step to the branched tree would have looked like. This can be seen on the right image.

This leads us to the task of updating our rule. We now want to replace a but by a shoot, a but on top and two buds on the side.

For this new rule we have to get a little inside on how GroIMP is interpreting the results of our rules. We already defined above that a shoot is a cylinder and a bud is a sphere and that our rule is defining a chain of cylinders with a bud at the end.

This chain of cylinders and the bud is stored in GroIMP in a graph, the project graph. This graph holds almost all information of the project and defines the core of a GroIMP simulation. Moreover this graph is also used as the foundation for the visualization of our model. As we can see in the left image below each shoot in the graph is drawn as a cylinder in the 3d scene. The placement of this objects is based on the concept of turtle geometry. We can imagine that a “turtle” is starting at the position (0,0,0) in the 3d scene and then follows the instruction given by the nodes in the graph. The reading of the graph starts a the top at Node.0 and goes down trough the nodes. The first two nodes (node.0 and RGGRoot) do not have any effect of the turtle, but a shoot tells the turtle to draw a cylinder and move to the end of this cylinder. Therefore the second shoot starts at the end of the first shoot and the bud is placed at the end of the second cylinder.

Left: Our apical shoot as a drawn image, a GroIMP 2d Graph and the GroIMP visualization, Right: the changes in the graph when the rule is applied

GroIMP comes with a howl set of commands that can manipulate this turtle by rotation, scaling, moving or chaining default values for color and sizes. (The most important once can be found here: turtle_commands)

To first get a feeling for this turtle geometry we will create a rule that turns bud into a shoot with one bud on the side pointing to the right. First we still need the shoot and then we add the lateral bud. Knowing that the turtle will be at the end of the shoot after drawing it, means that we have to move back form that position. Therefore we can use the move command: M(distance).

Assuming our shoot growth with a length of $l$, the turtle will move l up with Shoot(l) to get to the middle of the shoot we can just move back halve way with M(-0.5*x). This brings us already to the right position. Now we need to rotate to our turtle so that the bud will point towards the right.

Rotating the turtle is possible along the three axes x, y and z. We can see an example of the rotation tool on the right with the possible rotations in colors: x= red, y=blue and z=green. In the turtle geometry we can rotate this axes with the commands RL(angle), RU(angle) and RH(angle). RL rotates around the local X-Axes (the red circle in the image), RU around the Y-Axes (the blue circle) and RH around the z-Axes. If we imagine the image on the right rotate by 90 degrees, the names make more sense: RL rotate to the left (with negative values to the right) RU rotate up and RH rotates around the head axes.

For our little shoot with the apical bud, this means we have to rotate it on y axis (up, if the branch would lay on the side). Therefore we need the RU command and come the following rule:

Bud(x) ==> Shoot(x) M(-0.5*x) RU(30) Bud(x*0.8)

which,after 3 iterations, produces the “plant” below by drawing a shoot, moving back half the length rotation 30 degrees around the y axis and than starting over again two times.

We have already two possible rules to create our little plant, we either grow to the top or to the right. In the next step we want to do both in one rule. Doing this with one turtle traveling forwards and backwards would be very hard (sooner or later impossible).

In L-Systems, and also in GroIMP, this is solved by using a stack of turtle states (the current position, rotation, scale color etc.). This stack can be controlled by using square brackets [ ].

“[” mans add the current state to the stack of remembered states and “]” means go back to the last remembered state. This concept allows us to let our turtle do little detours that combine our rules to one rule of relpace a bud by a shoot, remember this state, move back half the length rotate 30 degres up add a new bud go back to the last state and add the apical bud. Or in XL:

Bud(x) ==> Shoot(x) [M(-0.5*x)RU(30) Bud(x*0.8)] Bud(x*0.8)

The order of the elements (why we move back before we add the apical bud) becomes clear if we imagine we apply the rule a second time. In that case we want the second shoot be added after the detour and not before (see in the graph representation below), otherwise the lateral shoot would be moved up with the new shoot.

In GroIMP's project graph, the “detour” part is added to the same node (in our case the shoot) but with a another edge (the connection between the nodes). The two different types of edges are called successors (the “main edges”) and branches (for the “detours”), in the 2d graph (see image below) this two edges are visualized by either full or dashed arrows. GroIMP supports more and also custom types of edges but these two are the main once.

As said above, the turtle state is stored in a stack, therefore we can push several turtle stacks in there. In our case this allows us to add some more lateral buds around (rotate by the head axes) the shoot:

Bud(x) ==> Shoot(x) [
 M(-0.5*x) [
  RU(30) Bud(x*0.8)
 ] RH(120) [
  RU(30) Bud(x*0.8)
 ] RH(120)[
  RU(30) Bud(x*0.8)
 ]
]Bud(x*0.8);

Which gives us an already quite nice little plant like structure:

You can now already play around with the values to change the shape of the tree, by for instance making the lateral branches shorter (x*0.5 in stead of x*.0.8) or change the rotation angels etc.

Looking at trees we can see that most of them have different growth-behavior on the trunk and on the branches. To simulate this, we will use the concept of branching orders. In this concept the branches of a tree are separated in orders based on their parent. We define the trunk as order 0 and then every lateral branch on the stem is of the order 1 and every lateral branch on the order 1 is of the order 2 and so on. This can be seen in the image on the right.

We, as many other modelers before us, will use this concept to give our tree more structure by defining different growth rules for the different orders. Lets define just three for now:

• A bud on the stem (of order 0) creates a shoot, a new apical bud with the order 0 and three lateral buds around it with the order 1
• A bud of the order 1 will create a shoot a new apical bud with the order 1 and two lateral buds of order 2 to the left and the right
• A bud of order 2 creates a shoot and a new bud of order 2

To use this rules, we first need the knowledge of the branching order for each bud. Therefore we can extend the module bud again with one additional parameter as following:

 module Bud(int order, float len) extends Sphere(0.1);

And now we learn a new trick, because on the left side of a XL rule it is also possible to specify which value the selected node should have: Bud(0,x) will only rewrite the buds of the order 0. This allows us to specify our rule from above for the order 0:

Bud(0,x) ==> Shoot(x) [
 M(-0.5*x) [
  RU(80) Bud(1,x*0.8)
 ] RH(120) [
  RU(80) Bud(1,x*0.8)
 ] RH(120)[
  RU(80) Bud(1,x*0.8)
 ]
]Bud(0,x);

I now only replaces the buds of order 0 (the stem) and gives the new buds the right orders, the lateral buds get order 1 and the apical bud get 0.

For the branches of the first order the new rule is as following, using the rotation to the left.

Bud(1,x)==> Shoot(x)[
 M(-0.5*x)
 [
  RL(70) Bud(2,x*0.6)
 ]
 [
  RL(-70) Bud(2,x*0.6)
 ]
]Bud(1,x*0.8);

finally the one for the second order is just as we know it from the very beginning.

 Bud(2,x) ==> Shoot(x)Bud(2,x*0.6);

This three rules result in a already quite nice looking structure. (Don't be confused, I resized the radius of the buds a bit)

Now in the last real step of this tutorial we want to look at the diameters of our little tree. In the F class that our shoot extends the diameter can be given as an second parameter: F(length,diameter). So we can just do the same thing as we did with the length and have a parameter d in our shoot hat is then forwarded to the F:

 module Shoot(float l,float d) extends F(l,d);

Now for defining this value in our rules we will use a very simple estimation. Lets assume that the ratio between the length of a shoot and its diameter is 10:1. This means in all our rules we can just change the Shoots to Shoot(x,x/10).

Even so this gives our tree already a nicer first shape, there is another thing we want to do with the diameter: secondary thickness growth. Therefore we add a new rule that states that every Shoot will be replaced by a new Shoot of the same length but a slightly larger diameter.

 Shoot(l,d)==>Shoot(l,d+0.02);

With the diameter our tree now looks like this:

This is basically it for this tutorial. Below you can get the code of this small tree. Now you can start playing around fitting it to your needs adding more parameters and rotations.

 module Shoot(float l,float d) extends F(l,d);
 module Bud(int order, float len) extends Sphere(0.04);
 
 protected void init()[
 	 Axiom ==> Bud(0,1);
 ]
 
 public void grow()[
 
Bud(0,x) ==> Shoot(x,x/10) [
 M(-0.5*x) [
  RU(80) Bud(1,x*0.7)
 ] RH(120) [
  RU(80) Bud(1,x*0.7)
 ] RH(120)[
  RU(80) Bud(1,x*0.7)
 ]
]Bud(0,x*0.8);
 Bud(1,x)==> Shoot(x,x/10)[
 	 M(-0.5*x)
 	    [
 	 	 RL(70) Bud(2,x*0.6)
 	    ]
 	    [
 	 	 RL(-70) Bud(2,x*0.6)
 	    ]
 ]Bud(1,x*0.8);
 
 Bud(2,x) ==> Shoot(x,x/10)Bud(2,x*0.6);
 
 
 Shoot(l,d)==> Shoot(l,d+0.02);
 ]