It is a batch program and the input files needed by it are divided into categories:

- Plant class file: a file for describing the 'biology' of a plant (L-System definition, leaf definition).
- Plant attributes file: a file describing some plant parameters (colors, number of generations, drawing parameters etc.).
- Irit file: a file containing a surrounding object by which to prune by and the location and direction of 'seeds' from which plants will grow.

Grow is based on the paper 'Synthetic Topiary' and was written by Erez Louidor, Adi Izkovitch and Ido Tal as a project for the Intelligent Systems Lab and was supervised by Dr. Gershon Elber.

In order to define environmentally sensitive L-System we will first define general L-Systems.

**w: b;** **p1: a -> a b;** **p2: b -> a;**

The rule which has **w** as its identifier is the axiom and **p1** and
**p2** are the production rules. By these rules the current word of step i
is:

**b****a****ab****aba****abaab****abaababa**

We should point out that our program works with parametric L-Systems and a
module with zero parameters is represented as the module name followed by ()
(for example **a()**) in contrast with our first example. This is necessary
in order to avoid the ambiguity that arises when allowing modules with multiple
letters names (otherwise for example **ab** can be interpreted as 2 modules
named **a** and **b** or one module named **ab**).

The axiom is always the first rule.

A rule's identifier is syntactically like a module name, and is optional as it isn't being used in any way in our program. It is applied however in all of our examples to improve the readability.

At the end of every rule (or axiom) a semicolon (**;**) sign must appear.
To denote an epsilon successor, simply put that sign after the **->** (for
example: **S()->;**).

C-style comments are allowed everywhere (**/* comment example */**). New
lines, tabs and blanks are ignored.

We can extend the above example to be a parametric L-System, for example:

**w: b(1);** **p1: a(x) -> a(x+2) b(x+0.5);** **p2: b(x)
-> a(x+1);**

By these rules the current word of step i is:

**b(1)****a(2)****a(4)b(2.5)****a(6)b(4.5)a(3.5)****a(8)b(6.5)a(5.5)a(5.5)b(4)****a(10)b(8.5)a(7.5)a(7.5)b(6)a(7.5)b(6)a(5)**

In the successor, each parameter may be a real numbers' expression. An expression is a combination of real numbers (in regular or scientific representation), variable names and built-in operators and functions.

The arity (number of parameters) of every module is determined the first time it is introduced (or is predefined for built-in modules). In any case of arity mismatch, the parser will print an error message.

If the current word is: **a(5) b(3) a(7) b(6) b(5)** then the production
**b(x) < a(y) > b(z) b(k) -> b(x+y-k);** would be valid for the
third module **a(7)** but would be invalid for other modules, specifically
the first module **a(5)** because at least one context doesn't match (in fact
both don't). We can also define an ignore list which tells the program to ignore
certain modules when matching contexts, for example: the production **a(x) >
a(y) -> a(x+y)** is invalid for the first module **a(5)** in the above
example, if the ignore list is empty. If the ignore list includes module
**b**, the production becomes valid.

This command must be placed after the L-Systems rules.

Like in the predecessor, modules in the contexts must have variable names as their parameters (if any). Variables declared in the contexts may be used in expression in the rest of the rule.

The case where several rules match a certain module is generalized in the Probability section.

**p1: a(x) -> a(x+1) : 1/x;** **p2: a(x) -> a(x-1): 1-1/x;**

To sum up, the most general production has the form:

label: lc < pred > rc : cond -> succ
:prob; |

**?P(x,y,z)**: a query module which returns the turtle's position.**?H(x,y,z)**: a query module which returns the turtle's H (Heading) vector.**?L(x,y,z)**: a query module which returns the turtle's L (Left) vector.**?U(x,y,z)**: a query module which returns the turtle's U (Up) vector.**F(x)**: advances the turtle x units along the H vector while drawing a cone.**f(x)**: advances the turtle x units along the H vector without drawing.**+(x)**: rotate (yaw) the turtle around the U vector x degrees to the left (changes the H and L vectors).**-(x)**: rotate (yaw) the turtle around the U vector x degrees to the right (changes the H and L vectors).**\(x)**: rotate (roll) the turtle around the H vector x degrees to the left (changes the U and L vectors).**/(x)**: rotate (roll) the turtle around the H vector x degrees to the right (changes the U and L vectors).**&(x)**:rotate (pitch) the turtle around the L vector x degrees to the left (changes the H and U vectors)**^(x): rotate**(pitch) the turtle around the L vector x degrees to the right (changes the H and U vectors)**[**: push the turtle's current state (position, 3 vectors and peripheral information) onto the stack (begin a branch).**]**: pop the turtle's current state off the stack (end a branch).**%**: prune a branch.

**p1: a(x) > b(y) -> d(x+y);** **p2: a(x) > c(y) ->
e(x+y);**

In this case *both* productions are valid for the first module
**a(1)**. The logic for this is as follows:

For **p1**: we start out at **a(1)** and push the turtle's state onto
the stack (the pushing action does not change the turtle's state so we ignore
it) the next module the turtle encounters is **b(2)** so **a(x) >
b(y)** is a good matching.

For **p2**: we start out at **a(1)** and push the turtle's state onto
the stack, next we encounter all sorts of modules (**b(2)** and **b(3)**)
and after them we pop the turtles state off the stack. At this point the turtle
"remembers" only encountering **a(1)** and we proceed to **c(3)**. At this
stage the turtle "remembers" **a(1)** and **c(3)** so **a(x) >
c(y)** is a good matching.

*More formally:* when trying to find a right context match and faced
with a **[** we can either continue looking to the right of it or jump to its
matching **]** and look to the right of it.

**p1: c(x) < a(y) -> e(x);**

**p2: b(x) < a(y) -> a(x);**

**p2** is a valid production for **a(1)** for the same reasons that
**p2** of the previous example was a valid production. **p1** is not a
valid production because after c**(3)** we pop so the turtle "forgets"
c**(3)**.

*More formally:* when trying to find a left context match (moving from
right to left) and faced with a **]** we proceed to the module to the left of
the matching **[**.

- Leaf definitions: Lets the user define special modules which will cause
the turtle to draw the Irit files attached to them (used primarily for drawing
leaves). When drawn, the leaf is first multiplied by the turtle's orientation
matrix and is then moved to the turtle's position. The syntax is:
**#defineLeaf**module_name**= "**file_name**";**

Any number of leaves can be defined (including zero, this definition is optional). The leaves have zero parameters (so you must add empty**()**after their names in the L-System). - L-System definition: Lets the user define an environmentally sensitive L-System as was explained earlier (this definition is mandatory). The ignore list is considered a part of the L-System.
- Attribute file definition: Lets the user define a plant attribute file for
this plant class. This file will be used by a seed using this plant class file
if the seed has not overridden it. This definition is optional (the system has
built in defaults). The syntax is:
**#loadAttributes "**file_name**";**

Below is a list of parameters:

**coneBaseAngle**: The angle of a cone drawn by the turtle in response to an F command (in degrees).**initialConeBaseRadius**: The cone base radius when the turtle is at the start of the current word.**coneBaseThreshold**: The smallest possible radius of a cone (cones which were supposed to be drawn with a radius smaller than the threshold will be drawn with the radius equal to the threshold).**coneBaseDepthDecayRatio**: The factor by which to multiply the cone radius when we start a new branch.**leavesScale**: Used for scaling the leaves to the appropriate size while drawing.**coneState**: Can be one of these:**DrawNoCones**,**DrawPolygonCones**,**DrawFreeformCones**.**generationsNumber**: The number of generations the plant will grow.**coneColor**: The color of the cone drawn. The syntax is: (R,G,B).

The Irit object type is string and the value of the string is "SEED". This
object has several attributes:

Attribute Name | Attribute Type | Description | Optional |
---|---|---|---|

H | vector | initial turtle H vector | no |

L | vector | initial turtle L vector | no |

U | vector | initial turtle U vector | no |

P | point | initial turtle position | no |

CLASS_FILENAME | string | L-System class file name | no |

PARAMETERS_FILENAME | string | name of overriding parameters file name | yes |

grow *'List of Irit input files'* *'Name of Irit output file'*

Both .dat and .bdt Irit formats are supported.

An example:

**grow dino.bdt seeds.dat dino-tree.bdt**

Will read the binary Irit file **dino.bdt** and the ASCII Irit file
**seeds.dat** and will write the result to **dino-tree.bdt**.