Structural Modelling with GroIMP/XL

Being based on Java, the software runs on any platform that is supported by a JVM.

GroIMP ships with a battery of examples, that demonstrate some of its features. The user-interface is fully dynamic and consists of panels, that can be moved and (un)docked.

A layout of the GUI can be saved for later use. This is used also, for instance, to provide two initial workspace configurations, one for interactive modelling and the other for RGG development.

Several import and export filters allow to share files with other programs, for instance GROGRA[Kur94] (dtd,dtg), external libraries (jar), or images (png,jpg, . . . ) for use as textures. Export of images rendered by the built-in raytracer to such file formats is also possible. Images can be managed by a panel called image explorer. Panels for other types of resources like shaders, functions, curves, and datasets exist as well.

GroIMP has a plug-in architecture, similar to the Eclipse platform¹¹. Each plug-in is described by an XML file plugin.xml which defines the plug-in’s capabilities, a list of prerequisite plug-ins, and libraries the plug-in depends on. Capabilities are represented as a tree structure and include menu entries, input/output filters, etc., and are combined for all plug-ins into a single registry. The list of prerequisite plug-ins is used to derive the initialization order of the plug-ins and prevents cyclic dependencies between the plug-ins. A schematic view of the plug-ins and their dependencies can be found in figure 3.8, and a short description in [Kni08].

The RGG plug-in connects GroIMP to the XL programming language. It provides compilation filters for different source file formats (rgg, xl, java, lsy, ssy), and calls the XL compiler for all such files contained in a project. The plug-in also provides a class de.grogra.rgg.RGG, that serves as base class for relational growth grammar de-velopment and manages the life cycle for such RGGs. The package de.grogra.turtle contains scene graph nodes for turtle commands, to provide compatibility with the GRO-GRA software. Finally, the classde.grogra.rgg.Libraryprovides utility functions that ease model development.

As many parts of GroIMP, and especially the RGG plug-in, are repeatedly involved when creating a new model, a new file format (rgg) has been designed that simplifies this action. Files with such an extension are modified before they are passed to the XL compiler. The RGG dialect of XL implicitly surrounds the code by a declaration of a subclass of RGG and the addition of several import statements. It also defines a static field INSTANCE that allows to refer to the instance, for instance, if a project consists of multiple files.

3.6. Structural Modelling with GroIMP/XL

Model development with GroIMP and XL usually starts by creating a simple structural model. This can then be extended by inclusion of physiological processes to an FSPM (functional-structural plant model), or used on its own in areas like computer graphics.

How to create a simple structural model of a daisy has been shown in [SH10].

The steps involved in creating a structural plant model are (see figure 3.9)

11http://www.eclipse.org, accessed 18 October 2011

(a) Data acquisition (b) Topology

(c) Texturing (d) Parameter calibration

Figure 3.9.: Steps to create a structural model of a daisy.

(a) Data acquisition, (b) Creation of topology, (c) Texturing,

(d) Parameter calibration.

Data about the plant can be obtained by collecting real plants and comparing their Data Acquisition

structure, measuring lengths (of steam, branches, etc.), count parts of them (like leaves, blades, etc.), and observing their color or texture. Also books can serve as reference for such data.

Topology in the model defines what parts the plant is made of, how many of each Topology

occur, and how they are connected. Figure 3.10 shows a schematic view of the daisy. In

3.6. Structural Modelling with GroIMP/XL

Figure 3.10.: Schematic view of the daisy.

the model, for each part of the plant a corresponding module is created. Each module also possesses a list of parameters relevant for it. Modules are also equipped with a graphical representation, either by deriving them from some geometric primitive, or by using an instantiation rule. For instance, the stem and flower petals were defined as

module Stem(float length, float diameter) extends Cylinder(length, diameter/2);

module Flower(float length, float diameter, int color)

==> if (color == YELLOW)

(Cylinder(length, diameter/2)) else

(leaf(length, diameter));

and the other modules in a similar way. The instantiation rule for Flowerdynamically chooses a geometric primitive (cylinder or parallelogram) based on the parametercolor.

Use of these parameters is made in a rule, that replaces the initialAxiom:

Axiom ==>

// create rosette of 7 leaves, diameter half of length for (int i : 1:7)

( [

RH(i * 137.5) // rotate by Fibonacci angle { double r = 50 - i * 5; }

Leaf(r, r/2) ] )

// create stem, length 70mm, diameter 2mm Stem(70, 2)

...

Leaves (and also flowers) are created in a loop by successively rotating around the Fibonacci angle [PL90]. The remaining parts are created in a similar way by that rule.

Additional rotation and translation commands were inserted to control orientation of the parts.

Using textures allows to give the model a more realistic look. The importance of Texturing

this can be seen by comparing figures 3.9b and 3.9c. For texturing, GroIMP provides a material system, which makes it possible to map images onto surfaces, or define textures procedurally. In case of the daisy model, image data was obtained by making pho-tographs, and then using an image editing tool like the GIMP¹²to cut out the textures.

Then, these image files were imported interactively into the daisy project using GroIMP so that they appear in theImage Explorer andShader Explorer.

A material defined in the shader explorer can be used in the model by obtaining a reference to it, and then applying the material to the module. For instance, the leaves can be assigned a texture by

ShaderRef leafShader = shader("leafShader");

...

module Leaf(float length, float diameter)

==> leaf(length, diameter).(setShader(leafShader));

Finally, to further improve the visual appearance, parameters like lengths and angles Parameter

Calibration can be calibrated. Also, randomness can be introduced by replacing a fixed parameter value by a normally distributed value (where mean and variance depend on measure-ments). Parameter calibration can also be reversed, by first creating the structure and collecting statistical data from it [DKH⁺07], then adjusting parameters so that the values derived from the model correspond to the measured data.

Other plants like fern (figure 3.11a) and horsetail (figure 3.11b) were modelled in a similar way. Figure 3.12 shows a scene that combines daisy, fern and horsetail, together with an alder tree [Rog08], grass leaves, an ivy plant, and some spruce trees [HKL⁺08].

It is also possible to distribute the plants according to a function. For instance, in figure 3.14 the daisy flowers were arranged according to a black/white image containing the text SCCG08.

The structure of trees (and many other plants) follows one of the architectural models proposed by [HOT78], which are shown in figure 3.13. Templates of such architectural models in form of GroIMP projects have been developed by Smolenova [SH10], and can serve as a starting point when developing new tree models.

To obtain an FSPM (functional-structural plant model), these templates can then be extended to include physiological processes. An often used approach is the pipe model theory [SYHK64a, SYHK64b]. It considers a so-called unit pipe (figure 3.15a), a collection of leaves associated with a pipe of constant cross-sectional area, corresponding to water-conducting vessels in branches and stem. A community of plants can then be thought of as an assemblage of unit pipes (figure 3.15b), but also an individual plant (figure 3.15c).

12http://www.gimp.org, accessed 20 October 2011

3.6. Structural Modelling with GroIMP/XL

(a) Fern (Dryopteris filis-mas) (b) Horsetail (Equisetum arvense)

Figure 3.11.: Virtual fern and horsetail modelled with GroIMP/XL.

Figure 3.12.: A virtual scene combining different plants.

Figure 3.13.: Architectural models of trees (image from [Fer00]).

3.6. Structural Modelling with GroIMP/XL

Figure 3.14.: Daisy flowers distributed procedurally.

The pipe model can also explain the development of tree growth, where when lower branches are shed parts of their pipes remain in the trunk giving them a conical shape (figure 3.16). In GroIMP this shape can be modelled by a frustum.

Pipe model theory also conforms toLeonardos rule, that states that “all the branches of a tree at every stage of its height when put together are equal in thickness to the trunk” [Ric70]. This means that the total cross-sectional area remains constant at every branching point (disregarding shed branches).

(a) Unit pipe

(b) Stand (c) Plant

Figure 3.15.: Diagrammatic representation of the simple pipe model (from [SYHK64a]).

Figure 3.16.: Diagrammatic representation of the pipe model of tree form, showing the successive accumulation of disused pipes in the trunk associated with the progress of tree growth (from [SYHK64a]).