Upload
dangtram
View
217
Download
0
Embed Size (px)
Citation preview
POLITECHNIKA WARSZAWSKA
WYDZIAŁ MATEMATYKI
I NAUK INFORMACYJNYCH
PRACA DYPLOMOWA INŻYNIERSKA
INFORMATYKA
Generowanie trójwymiarowych modeli roślin
Autor: Kamil Andrzej Ciosek
Promotor: Dr. Paweł Kotowski
Warszawa, Marzec 2008
Author’s signature / Podpis autora:
...................................................
Supervisor’s signature / Podpis promotora:
...................................................
WARSAW UNIVERSITY OF TECHNOLOGY
FACULTY OF MATHEMATICS
AND INFORMATION SCIENCE
B. Sc. THESIS
COMPUTER SCIENCE
Generating 3D Plants
Author: Kamil Andrzej Ciosek
Supervisor: Dr. Paweł Kotowski
Warsaw, March 2008
Abstract
The main focus of the present thesis is the analysis of modern methods of al-
gorithmic plant generation. First, a brief introduction is given to the necessary
formalisms: Lindenmayer systems and plane triangulations. It is followed by a de-
scription of each stage of the plant generation process. These include algorithms for
obtaining: leaf venation graph, leaf texture, stem texture, and the geometry and
topology of the whole plant. Finally account is given of the effort to implement
some of the described procedures in a program accompanying the thesis. In the pro-
gram, textures are obtained from transformed noise, a general plant description is
generated with a parametric Lindenmayer system and a purpose-built particle-based
algorithm is used to simulate leaf venation.
Streszczenie
Celem pracy jest analiza współczesnych metod algorytmicznego generowania
roślin oraz ich implementacja w dołączonym programie. Najpierw wprowadzone
są niezbędne formalizmy – systemy Lindenmayera i triangulacje na płaszczyźnie.
Następnie opisane są poszczególne części procesu generowania rośliny. W szczegól-
ności przedstawione są algorytmy generujące: graf żyłek na liściu, teksturę tła liścia,
teksturę łodygi oraz geometrię i strukturę całej rośliny. Na koniec opisane są kwestie
związane z implementacją zaprezentowanych algorytmów. Program dołączony do
pracy używa przekształconego szumu do generowania tekstur oraz parametrycznego
systemu Lindenmayera do generowania ogólnego schematu rośliny. Wzrost żyłek na
liściu jest natomiast symulowany z użyciem dedykowanego algorytmu opartego na
cząstkach.
Contents
Introduction 5
1 Theoretical preliminaries 7
1.1 Lindenmayer systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Triangulations within a plane . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Cardinal splines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Algorithms for plant generation 17
2.1 Leaf venation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Leaf texture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Triangulation of leaf surface and deformation into the third dimension 26
2.4 Stem texture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Using the Lindenmayer system . . . . . . . . . . . . . . . . . . . . . 31
2.6 Modelling the shape of the plant’s stem . . . . . . . . . . . . . . . . 33
2.7 Possibilities of further development . . . . . . . . . . . . . . . . . . . 34
2.8 Sample plants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Implementation 41
3.1 The choice of the technology . . . . . . . . . . . . . . . . . . . . . . 41
3.2 The design and structure of the program . . . . . . . . . . . . . . . . 42
3.3 The use of external libraries . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Possibilities of further development . . . . . . . . . . . . . . . . . . . 48
3.5 User’s manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Concluding Remarks 57
Bibliography 59
3
Introduction
It is beyond doubt that plant modelling is one of the milestones that computer
graphics needs to achieve to finally get to the holy grail of movie-quality real-time
image synthesis for games and other virtual worlds. Indeed, after programmers
mastered the ways to reproduce simpler elements of our world on the computer
screen, it is now primarily in the foliage that the struggle goes on to stun the
user with the realism of artificial imagery. While each new generation of games
presents a considerable improvement over its predecessors, the results are still not
entirely satisfying and usually apply to only a specific class of plants. Therefore
plant generation truly stands out as an area that is worthwhile to research into and
learn about.
However exciting plant modelling may now seem, it is not a recent invention:
the basic concepts have been around for quite considerable a time now. It has been
a major challenge because unlike with most other objects that we would like to dis-
play in virtual worlds, the difficulty of plant modelling does not lie with the speed of
graphics hardware, but with the high level of complexity and diversity that is intrin-
sic to the intricate structure that most plants posses. In fact, Bloomenthal [1985]
created photo-realistic images of a maple three in an era when graphics hardware
was primitive compared to even the slowest integrated accelerators we have today.
With most objects, realistic display boils down to hand-crafting a model with a
polygon count sufficient to display the necessary detail. This approach has quite lim-
ited use because no model designer could possibly reproduce the level of complexity
represented by a plant, if the model is to be looked at from a close enough distance.
Also, it is impossible to achieve the variety of plants within the same species, or
trace the development of plants over time with manual modelling. Therefore we
need a descriptive formalism that enables us to compress the plant structure into a
workable formula that can be hand-modified and intuitively understood. In fact, it
is one of the central concepts of mathematics to describe some aspect of the struc-
ture of a complex object in a simple fashion. One feature of plants that seems to
5
be helpful in doing so is the fact that they display a certain degree of self-similarity.
Of course, this fractal-like behaviour does not encompass every aspect of the plant
at every scale, but still, it is quite helpful. In this respect, this thesis describes the
concept of Lindenmayer systems: a type of formal grammars that is especially well-
suited for the modelling of plants and that allows the user to easily exploit whatever
self-similarity the plant has.
One issue that often arises during the use of plant-generating algorithms is the
question of how good they are at modelling the biological processes that happen
inside the plant. While this certainly helps because it usually means the parameters
of the model may be easily tweaked to modify the results and the developmental
of the plant structures traced in time, it is not a precondition for a good model.
Computer science is inherently a phenomenological science, so it is really the program
output that ultimately matters. It has therefore been decided that the way in
which a given algorithm imitates what happens inside the plant is only of secondary
importance.
The following chapters give an account of experiments with Lindenmayer sys-
tems, as well as of efforts to patch them up by adding external algorithms to model
the aspects of the plant that they poorly represent (most notably, leaf venation
patterns). It also describes a program that implements some of the presented ideas.
6
Chapter 1
Theoretical preliminaries
This chapter gives a brief and practically-oriented discussion of the theoretical con-
cepts that one needs to master to be able to implement plant generation algorithms.
1.1 Lindenmayer systems
The following sections introduce the concept of Lindenmayer systems, a variation
of formal grammars widely applied to plant generation. They were first introduced
by Aristid Lindenmayer as a means of modelling the growth of algae, but were
later given a more thorough theoretical description and applied to many different
problems. The theoretical part of this section is based on Salomaa [1973].
Deterministic context-free Lindenmayer systems are described in a relatively
thorough way, while their modifications, which increase generative power, are only
described briefly.
Definition. A deterministic context free Lindenmayer system (D0L-system) is a
tuple < V, ω, P >.
1. V - is a set of symbols.
2. ω ∈ V - is the axiom or start symbol.
3. P ⊂ V × V ∗ : (∀a)(∃!p)((a, p) ∈ P ) is the set of productions.
Note that the right side of the production may be empty (erasable productions
are permissible) and that Lindenmayer systems do not differentiate between terminal
or non-terminal symbols. Also note that each symbol is the left side of exactly one
production (hence the determinism).
The defining feature of Lindenmayer systems will now be presented: the basic
relation that is used to generate words.
7
Definition. The arrow relation → ⊂ V + × V ∗ is defined as follows: P → Q iff P
can be expressed as a sequence of symbols P = p1, p2, ..., pn : pi ∈ V and Q can be
expressed as a sequence of (possibly empty) strings Q = q1, q2, ..., qn ∈ V ∗ such that
n > 0 and for each i there exists a production from pi to qi, i.e. (∀i)(pi, qi) ∈ P .
Note that the difference between ordinary grammars and Lindenmayer systems
lies in the fact that we substitute all symbols at once. Also note that, given a string
from V ∗, the concatenation of the transformations of each constituent letter of the
string is defined unambiguously and is trivial to compute. This is in strict opposition
to context-free grammars, where special care needs to be taken to avoid ambiguity.
In practical applications, we start off with the axiom and iterate the→ relation a
fixed number of steps. The number of steps is considered a parameter. Normally, this
parameter represents the ”depth” of simulation, for example the level of development
of the plant being modelled. Below, a simple example of a deterministic context-free
Lindenmayer system is presented. A more elaborate example, which can be used to
model plants will be given later.
V = {A,B,C}
ω = A
The set P is contains the following productions:
A→ BC
B → AC
Note that we have omitted the production from C. This is common practice, and
means that C → C. After three iterations, this system yields:
ω = A→ BC → ACC → BCCC
Definition. The relation ⇒ ⊂ V + × V ∗ is the reflexive transitive closure of →.
In short, P ⇒ Q for all Q which are obtainable (in the sense of → ) from P . We
will use this relation to define the language generated by a Lindenmayer system as
all strings obtainable form the axiom with an arbitrary number of iterations.
Definition. A language generated by a Lindenmayer system < V, ω, P > is defined
as {S : ω ⇒ S}. A language generated by a D0L system is called a D0L language.
Observation. For each string s in a D0L language, there exists an integer k, such
that the string s is obtained from the axiom ω of a D0L system generating this
language in exactly k steps (i.e. using the → relation exactly k times).
8
The preceding statement is obvious but needs to be mentioned explicitly be-
cause we will be using continuously in the reminder of this section. It will now
be attempted to relate this newly introduced concept co ”classical” levels of the
Chomsky hierarchy. Note, however, that although these properties are instructive,
they are only of secondary importance for the modelling of plants as we usually only
iterate the system a specific number of times and are not really interested in the
”limit” properties of the system.
Observation. There exist regular D0L languages.
Proof. Consider the language {A}, generated by the system ω → A.
Observation. There exist context-free D0L languages that are not regular.
Proof. Consider the language {s : s = A2nB2n , n ≥ 1}, generated by the system
ω → AB,A→ AA,B → BB.
Observation. There exist context-sensitive D0L languages that are not context free.
Proof. Consider the language {s : s = A2nB2nC2n , n ≥ 1}, generated by the system
ω → ABC,A→ AA,B → BB,C → CC.
Observation. There exist regular languages that are not D0L.
Proof. Consider the language {A,AA}. Assume it is generated by a D0L system.
Therefore, either A⇒ AA or AA⇒ A. The latter is impossible, because this would
mean that A ⇒ ε, and therefore the empty word ε would belong to the language.
Therefore A ⇒ AA. However, this means that the word AAAA belongs to the
language generated by the D0L system, which is a contradiction.
Observation. There exist context-free languages that are neither D0L nor regular.
Proof. Consider the language {A,AA} ∪ {s : s = A2nB2n , n ≥ 1}. Assume it is
generated by a D0L system, proceed as in the previous example.
Observation. There exist context-sensitive languages that are neither D0L nor
context-free.
Proof. Consider the language {A,AA} ∪ {s : s = A2nB2nC2n , n ≥ 1}. Assume it is
generated by a D0L system, proceed as in the previous example.
Theorem. All D0L languages are context sensitive.
9
Proof. We shall construct a context-sensitive grammar G that simulates deriva-
tion in an arbitrary D0L system < V, ω, P >. Consider the grammar G =<
{A,B,C,D}, V, A, PG >, where the set PG contains the productions listed below.(1) A→ BωB
(2*) Bv → BCv (one production for each v ∈ V )
(3*) Cv → RC (one grammar production for each D0L production (v,R))
(4) CB → DB
(5*) vD → Dv (one production for each v ∈ V )
(6) BD → B
(7) B → ε
It is easy to see how this grammar works: production (1) sets the initial state of
the simulation. The symbols B function as boundary markers. Using a production
of the form (2*) results in the creation of the symbol C, which traverses the word
and replaces the left side of each D0L-production with its right side using produc-
tions (3*). Once the end of the string is reached, production (4) creates a special
”return” symbol D that returns to the beginning of the word using productions
(5*). Production (6) is used to eliminate the symbol D. This corresponds to the
end of an iteration of the D0L-system. There are now two options, either to use the
production (7) and terminate the derivation or to use a production (2*) and start
one more iteration step.
Therefore, every D0L-language is generated by a context-sensitive grammar.
The facts outlined above give the following picture of how Lindenmayer systems
relate to the Chomsky hierarchy.
Figure 1.1: D0L-systems as compared to the Chomsky hierarchy. Source:
Prusinkiewicz and Lindenmayer [1996].
Below, three basic ways of extending Lindenmayer systems have been described.
They are used to increase the generative power of the formalism and consequently
10
to be able to model more intricate structures.
The first modification is quite obvious: we can add non-determinism by dropping
the requirement (∀a)(∃!p)((a, p) ∈ P ) on the set of productions and replacing it with
(∀a)(∃p)((a, p) ∈ P ). The motivation for this in practical approaches is that we want
to add variation to the generated model (for example to reflect the fact that plants
of the same species look alike but are not strictly identical). In fact, we usually
first create a deterministic system and then extend it by adding non-determinism
to certain productions. To facilitate this approach, a probability function may be
added which maps each production to a probability value (of course, probabilities
of productions with the same left side sum to 1).
Another way of increasing the generative power of Lindenmayer systems is to
add context-sensitivity. Systems where each production has both a left context and
a right context are called 2L-systems (the contexts contain only one symbol each).
The set of productions of context-sensitive systems is formally defined below.P ⊂ (V × V × V )× V ∗ (for 2L-systems)
P ⊂ (V × V )× V ∗ (for 1L-systems)Systems where either all productions have a left context or all productions have
a right context are called 1L systems. These classes are distinct (i.e. there exist
languages that are generated by 2L-systems but not 1L-systems). Likewise, there
exist languages generated by 1L-systems but not context-free systems. The practical
motivation of using context-sensitivity is the transmission of signals (for example,
from one part of the plant to another).
Yet another approach is through adding a real numerical value (or many such
values) to each symbol and then using parametric expressions and conditions. The
set Σ of formal parameters in introduced and the axiom is redefined as ω ∈ (V ×
R∗)+. The discussion of parametric Lindenmayer systems presented here is based on
Hanan [1992]. From the drawing perspective, parametric systems have the following
motivation: they allow plotting lines of non-rational length (like the diagonal of a
unit square) and allow for easy shrinking of plant segments that appear later in the
derivation process (through using a parameter that corresponds to segment length).
Productions of parametric Lindenmayer systems are of the form given below.
P ⊂ (V × Σ∗)× C(Σ)× (V × E(Σ)∗)∗
In the above formula, C(Σ) corresponds to the set of possible well-formed boolean
conditions operating on formal parameters from the set Σ, wile E corresponds to
the set of possible well-formed arithmetic expressions with formal parameters from
the set Σ. Note that each symbol may have any number of parameters, or not
11
parameters at all. The influence of these addenda on the process of derivation is
that: (i) values of parameters are evaluated for each iteration step, (ii) a production
may only be used if its condition evaluates to true. Conditions is productions with
the same left side have to be mutually exclusive, unless we also want to add non-
determinism. A sample parametric system that can be used to generate a plant will
be given in the next chapter.
Of course, these three approaches may be combined. In the program accompa-
nying this thesis, only the last of the mentioned modifications was used, i.e. deter-
ministic context-free parametric Lindenmayer systems have been implemented.
1.2 Triangulations within a plane
The discussion of Delaunay triangulations presented here is based on Goodman and
O’Rourke [1997]. They describe triangulations of arbitrary dimensionality, but the
plant generation algorithms described in this thesis only require two-dimensional
triangulations. Therefore, only two-dimensional triangulations will be described
here. Also, the algorithms used to compute the triangulations are not given (the
program used an external library, CGAL, to accomplish this task). In the program,
triangulations are used as part of two algorithms used by the program: the vein
growth algorithm, which uses Urquhart triangulation as an approximation of the
relative neighbourhood graph as well as the leaf deformation algorithm, which uses
a constrained Delaunay triangulation to create leaf mesh.
Definition. Given a set S of points within R2, three points A,B,C ∈ S are said
to form a Delaunay triangle iff the circumscribed circle of this triangle (A,B,C)
contains no point from S − {A,B,C}.
Definition. Given a set S of points within R2, a Delaunay triangulation DT (S) is
the set of all Delaunay triangles built of points from S.
Definition. Given a set S of points within R2, and a set of edges E connecting
some of the points from S, two points p, q are said to be visible from each other if
the line from p to q does not intersect any edge from E.
Definition. Given a set S of points within R2, and a set of constraint edges E with
endpoints from S a constrained Delaunay triangulation CDT (S,E) is the set of all
triangles built of points from S such that the circumscribed circle of each triangle
contains no point from S − {A,B,C} visible from the interior of the triangle with
respect to E.
12
Observation. A constrained Delaunay triangulation is not necessarily a Delaunay
triangulation.
Figure 1.2: Delaunay and constrained Delaunay triangulations of the same point set.
The constraint edge is dashed. Delaunay triangulation reproduced from Andrade
and de Figueiredo [2003].
Definition. Given a Delaunay triangulation DT (S), an Urquhart triangulation
UT (S) is a graph obtained by removing the longest edge from each triangle of DT (S).
Observation. UT (S) ⊂ DT (S).
Definition. Given a set S of points within R2, two points p, q ∈ S are relative
neighbours with respect to S iff
∀r ∈ S d(p, q) ≤ max(d(p, r), d(q, r))
where d(a, b) denotes Euclidean distance between points a, b.
A geometric interpretation of relative neighbourhood is given in the following
figure.
Figure 1.3: Points P,Q are relative neighbours iff there are no points in the grey
area (called a lune). Source: Andrade and de Figueiredo [2003].
Definition. Given a set S of points within R2, the graph RNG(S) is a graph such
that its vertices are points from S. Two points are connected in the graph if they are
relative neighbours with respect to S.
While introducing the relative neighbourhood graph, Toussaint [1980] showed
the following:
13
Theorem. RNG(S) ⊆ DT (S)
Observation. RNG(S) ⊆ UT (S). For some sets S, RNG(S) ⊂ UT (S).
Proof. First, we will show that RNG(S) ⊆ UT (S).
Indeed, consider a triangle (A,B,C) ⊂ DT (S). It suffices to show that the
longest edge of this triangle cannot belong to RNG(S). Assume the longest edge is
(A,B). Observe that point C belongs to the lune (corresponds to the grey are in
the figure) defined by points (A,B). Therefore (A,B) 6∈ RNG(S).
We still have to show that RNG(S) 6= UT (S). This is demonstrated in the
following figure (the edge E belongs to UT (S) but not to RNG(S).
Figure 1.4: Urquhart and relative neighbourhood graphs of the same point set.
Source: Andrade and de Figueiredo [2003].
In view of the previous observation, it seems interesting to know how many edges
of the Urquhart triangulation make it into the relative neighbourhood graph. It
turns out that a great majority does. In fact, Urquhart first proposed the Urquhart
graph as a way of fast evaluation of the relative neighbourhood graph. Empirical
tests on random graphs by Andrade and de Figueiredo [2003] show that on average,
the relative neighbourhood graph has only about 2% less edges than the Urquhart
graph.
Therefore, the Urquhart graph is a good way of approximating the relative neigh-
bourhood in application where accuracy is not critical. This is the approach taken
during the development of the program accompanying this thesis. This has the ad-
vantage that very fast library routines for computing Delaunay triangulations are
readily available and it is trivial to obtain the Urquhart graph from the Delaunay
graph. There exist algorithms for obtaining RNG(S) from DT (S) in time O(nlogn),
but these are very complicated. Also, Runions et al. [2005] have investigated the
effects of using this approximation while simulating leaf venation and found them
to be negligible.
14
1.3 Cardinal splines
This brief description is based on Salomon [1999]. It by no means exhaustive and
only describes the aspects of cardinal spline that have been important to the writing
of the program.
Definition. A cubic spline is a set of polynomials of degree 3 that pass through a set
of data points in such a way that they connect in a continuous way (i.e. the curves
meet and their tangents match).
Given a set of points, each polynomial in the spline built upon these points
should pass through two points and have certain tangent values at those points.
The following observation states that this defines the polynomial uniquely.
Observation. Given two points P0,P1 and two tangent vectors T0,T1, a polyno-
mial of the form f(t) = At3 + Bt2 + Ct + D f : [0, 1] → R × R is uniquely defined
by the conditions: f(0) = P0, f(1) = P1,dfdt (0) = T0,
dfdt (1) = T1.
Proof. This follows directly from substituting f for At3 + Bt2 + Ct + D in the
four conditions and solving the resulting equations for A,B,C,D, obtaining A =
2P0 − 2P1 + T0 + T1,B = 3(P1 −P0)− 2T0 −T1,C = T0,D = P0.
The question remains, however, how to pick the tangent values T0,T1. One way
of doing this is to require that the whole spline be second-order continuous (that
the second derivatives match at the connecting points). In this case the curve is
uniquely defined by the point locations and tangents at the endpoints. An obvious
advantage is that the curve is smoother. However, the resulting spline may change
along the whole length if just one point is moved, or the endpoint tangent is changed.
If the spline is to be used as an element of user interface, this is counter-intuitive for
the average user. Therefore, it seems adequate to sacrifice second-order continuity
for the “locality” property of the curve, i.e. for the fact that, if the user moves a
point within the curve, only a fixed number of curve segments closest to this point
change their shape. One way of doing this is through cardinal splines. With cardinal
splines, the tangents are defined in the following way.
Ti = (1− c)(Pi+1 −Pi−1)/2
In this formula, P−1 stands for the point that precedes point P0 within the curve,
and P2 is the point behind P1. Please not that endpoint tangents need to be either
specified explicitly or assumed to point into the direction of the next point (for the
start on the curve) and previous point (for the end of the curve). The parameter
15
c is corresponds to the curve tension. If c = 0, the spline is called a Catmull-Rom
spline. This is the default value used by Microsoft GDI+.
It is often necessary to calculate the length of the spline curve. In the leaf gen-
eration program, this is required by the algorithm that deforms the leaf along a
predefined curve. It follows from elementary calculus that for an arbitrary continu-
ous curve specified by a parametric equation f : [0, 1] → R × R, the length of this
curve is given by the following formula:
l =∫ 1
0g(t)dt, g(t) =
√√√√(dfdt
)2
x+(df
dt
)2
y
For cardinal splines, this integral has to be evaluated numerically. To do this, Gauss-
Legendre quadrature has been used. Using it, the curve length can be approximated
using the formula below (source: Wikipedia).
l ≈ 12
N∑i=1
wig
(12xi +
12
)
In this formula, xi and wi denote the quadrature abscissas and weights respectively.
For a given N , these are fixed constants. In the program accompanying the thesis,
it turned out that it sufficed to use N = 5 to achieve good results.
16
Chapter 2
Algorithms for plant generation
This chapter addresses the core issues related to plant generation. While the whole
process revolves around Lindenmayer systems, auxiliary mechanisms need to be
added to make the plants appear realistic. In the following subsections, a discussion
is given of the modules used for the generation of various aspects of plants.
2.1 Leaf venation
Modelling leaf venation is quite imperative to achieving the proper looks of a mod-
elled plant. This is due to the fact that the surface of plant leaves is usually bigger
and more prominent to the viewer than other features of the plant. Therefore due
care must be exercised to ensure that an adequate algorithm is employed. The most
widely used approaches to the modelling of venation patterns are discussed below.
Taulor-Hell and Baranoski [2002] provide a thorough list of methods used to
date, ranging from simple texture mapping of scanned leaves to modern procedu-
ral approaches. In particular, they evaluate the following methods (the list below
summarizes the authors’ findings):
1. Lindenmayer systems, which have the advantage of almost unlimited flexibility,
but need to be extended with a geometric formalism to provide realistic models
of plant organs,
2. implicit surfaces, applied to leaf venation by Bloomenthal [1995], who devel-
oped very intricate apparatus for modelling, modifying and blending surfaces
with the help of skeletons, which, however, does not solve the issue of getting
a flat leaf venation pattern in the first place (he used a scanned leaf),
3. particle systems, which are computationally expensive and complicated but
flexible,
17
4. cellular texture basis functions, on which it is impossible for me to comment
because literature on the subject is unavailable.
Couder et al. [2002] describe an interesting experiment aimed at establishing
new methods of reproducing venation patterns. They put special gel in moulds of
different shapes. The gel was then left to dry and cracks that appeared on the
surface due to the stress caused by the top layer of the gel drying faster and than
the lower layer. They concluded that the pattern of cracks on the surface of the gel
bears considerable similarity to venation patters of various leaves.
Figure 2.1: Similarity between venation patterns(above) and gel cracks (below).
Source: Couder et al. [2002].
Therefore, they proposed that venation patterns be reproduced using physical
fracture-modelling techniques. They also observed that this procedure is not without
justification from the standpoint of plant morphology, because different layers of
plant leaves are known to grow at different paces, which causes stress formation
between different leaf layers.
Notwithstanding the huge potential of this approach, it has been decided not
to implement it in the program accompanying this thesis for the following reasons
(which have been acknowledged by the authors):
1. The results obtained to date are reasonably good, but nowhere near photo-
realistic.
2. The implementation requires an in-depth study of fracture-formation algo-
rithms. There are no such algorithms that are readily available and geared
specifically at modelling leaf venation.
3. The method does not account for biochemical processes of vein formation,
which are proven to have a significant role in the development of real plants.
Rodkaew et al. [2002] describe a particle-system based approach that is very
appealing. It consists in the following basic steps.
18
1. A leaf shape is given and a special ”target” point on the shape boundary is
marked, which corresponds to the location where the leaf blade merges with
the stem.
2. Particles are scattered randomly within the shape.
3. Particles are iteratively moved on the leaf surface, in that they are attracted
by the source and by one another.
4. The simulation ends when all particles have reached the target.
This procedure has the advantage of being remarkably intuitive and simple,
which seems to make it a good candidate for solving the problem of generating
venation patterns. The quality of the output also seems adequate at first. I has,
however, one major disadvantage: it is difficult to tweak the used approach to achieve
true similarity with real leafs. While the results are good, they are not really photo-
realistic, and will never be unless the method is heavily modified. There are following
reasons for this.
1. The algorithm does not really account for the shape of the leaf. Of course,
the particles are scattered within the surface, which is essentially arbitrary,
but there is no visible connection between the location of the particle on the
surface and its path.
2. The algorithm does not take into account the growth of the leaf, nor does it
permit to model leaf growth.
3. The algorithm does not allow the modelling of closed venation patterns (pat-
terns whose veins loop).
4. The algorithm has no footing in the mechanisms real-world plants use to grow
their veins, which is not a disadvantage by itself, but which makes it even more
difficult to come up with solutions to previous problems.
Therefore, it seems that while the use of particle systems is a step in the right
direction, there is a need of a serious refinement of the idea to make it work for a
larger variety of plants.
Runions et al. [2005] provide a solution that is quite successful at addressing
the ills of the earlier attempts of using particle systems to model vein growth. The
authors, base their algorithm on the idea that venation patterns emerge due to a
special plant hormone, called auxin: “[...] auxin originates in the leaf blade and flows
19
toward existing veins, which transport it to the leaf base. During this flow, auxin is
canalized into narrow paths [...]. These paths gradually differentiate into new vein
segments. Experimental evidence suggests that auxin sources may be discrete.”
To account for this hormone, the algorithm uses two kinds of particles: source
particles, representing auxin and node particles, representing vein segments. The
algorithm is an iterative process that tries to reproduce the way in which the sources
and nodes relate to one another on the leaf surface.
It has been decided that the last algorithm is the most appropriate candidate for
implementation in the program accompanying this thesis. It is described in detail
in the following sections. First, a simplified version will be discussed that can only
model open (non-looping) venation patterns. Then it will be extended to account
for closed (looping) patterns. Please note that, unless otherwise noted, all the ideas
discussed in this context are taken from Runions et al. [2005].
The following list presents the inputs to the algorithm. For convenience it has
been assumed that x, y coordinates on the leaf surface are normalized to the [0, 1]
interval.
1. An initial shape of the leaf. It may be defined in an arbitrary way provided it
does not comprise disjoint regions.
2. A special point on the initial leaf shape, the leaf origin. It is considered to be
the first leaf node.
3. A growth function f(x, y, t) : [0, 1]× [0, 1]×N→ [0, 1]× [0, 1]. It tells us where
a particle, which is at location (x, y) at the moment t, will be at the moment
t+ 1.
4. A procedure of adding new sources at simulation step t. It will be explained
later on and does not really need to be formalised.
5. A value g, which corresponds to the distance by which a vein grows in one
iteration step.
6. A value d, which corresponds to the distance between a node and a source at
which we assume that the node has reached the source.
7. A value dSS , which corresponds to the minimum distance between a newly-
added source and existing sources.
8. A value dSN , which corresponds to the minimum distance between a newly-
added source and existing nodes.
20
9. A value s, which corresponds to the number of sources that are added at each
iteration of the algorithm.
10. A value i, which specifies the number of iterations of the algorithm.
The procedure is summarised in the following basic steps.
1. At a given point of time, the leaf has a certain shape and a certain number
of hormone sources is scattered within the shape. Each source has a specific
location. Also, node particles added during previous iteration steps appear on
the surface.
2. For each source, exactly one vein node is chosen, which is said to influence the
source. It is the node nearest to the source, or if there are many nodes at the
same distance, any one of them is picked at random. Note that one node may
by influenced by many sources or no sources at all.
3. For each vein node, which is influenced by at least one source, its growth di-
rection is calculated, which is the arithmetic average of the directions pointing
towards the sources that influence the node. The node then grows in the cal-
culated direction by distance g i.e. a new vein node is created and a logical
edge is created between the new node and the old node, which will later be
rendered as a vein segments. The old node remains on the leaf and may still
grow in further stages of the process.
4. Sources that have been reached by a node are deleted. A vein node is consid-
ered to have reached the source if it is within a certain distance d from the
source.
5. The leaf grows. This means that all particles on the leaf may change location
according to the pre-defined function f and that new sources may be added
to the leaf, in a way that reflects the kind growth of the surface we wish to
model. The leaf boundary also grows.
The algorithm returns the venation graph (in this case, a tree).
The described procedure needs some clarification as to the various ways in which
the leaf may grow. The authors of the algorithm list three most common possibilities:
1. Marginal growth: only the leaf boundary grows. The growth is homothetic
with respect to the leaf origin. Particles do not change their location between
steps.
21
2. Uniform growth: both the boundary and existing particles grow. The growth
is likewise homothetic with respect to the leaf origin.
3. Non-uniform anisotropic growth. This is the general case in which the leaf
surface changes its shape as defined by an arbitrary function.
This distinction is important because the authors report vastly different results
depending on the kind of growth function used and the speed of growth. However,
good results can usually be achieved without resulting to the most general case,
which is relatively difficult to implement.
It is also important to clarify the way in which new auxin sources are added to
the leaf surface. The authors describe two ways.
1. At each iteration step, a given number of sources s is placed on the leaf surface.
Thy are scattered all over the leaf.
2. At each iteration step, sources are added only to the area by which the leaf
shape has grown. This is best done by abandoning the use of the s parameter
and pre-computing the source distribution before the simulation begins.
In either case, the sources are added using a dart-throwing algorithm in such
a way that the distance between a new source and an existing source is not closer
than dSS and the distance between a new source and an existing node is not closer
than dSN (i.e. the program picks random locations until it satisfies algorithm re-
quirements).
Once the iterative process has completed, we have a graph representing the
generated venation pattern. What we would like to have, however, is the texture of
the actual veins. To get it, we need to account for one vastly important aspect of
leaf venation: the width of the veins. First, we observe that the venation pattern of
leaf generated using the described algorithm has the topology of a tree. This means
that the edges (vein segments) may be sorted with respect to their distance from
the tree root (leaf origin). Therefore, it is possible to mark the edges which are
the furthest from the root (the thinnest veins) as having width 1 . The with of the
remaining edges can then be assumed to follow from the formula rnparent =∑rnchildi
We calculate the widths of edges that are farther from the root first and then use
these values to calculate the nearer ones. The process is repeated till we reach the
root node. The authors of the algorithm note that while the formula has biological
footing for n = 3, it may also be treated as yet another user-specified parameter.
It may be deduced that the algorithm has the following shortcomings:
22
1. Vein nodes may grow outside of the leaf shape. This is due to the fact that
veins always grow by a fixed distance.
Figure 2.2: Nodes may grow out of the leaf boundary. Hollow points correspond to
vein nodes, dots correspond to sources.
However, it has been found out that this very rarely happens in practice.
Therefore, we do not lose any significant information if we just clip the node set
to the leaf boundary after the pattern has been generated. Theoretically, such
clipping may split the venation graph into several disconnected parts, having
a devastating effect on the procedure adding width to the veins. However, this
would only happen for highly unlikely leaf shape. To be on the safe side, it is
best not to clip the graph, but the ready bitmap.
2. The algorithm for adding new sources, which picks random locations and
checks if it satisfies the constraints is computationally expensive and seems
suboptimal. However, it has been observed that the running times of the
whole pattern-generation loop are acceptable (for reasonable parameters, less
than a minute). Also, it is not immediately apparent how to scatter sources
in a more efficient way. Therefore it has been decided to leave the inefficient
algorithm unchanged.
The discussed procedure only works for open patterns (patterns without loops).
However, plants with closed venation systems cannot be neglected, because there is
a great variety of plants that display such patterns. Therefore, the algorithm needs
to be extended.
The most significant modification concerns the process of determining which
source influences which node. Recall that in the previous variant, each source in-
fluenced exactly one node. This needs to be changed because we want the nodes to
meet. The authors of the algorithm defined the set of sources that influence a given
node v as {s : (v, s) ∈ RNG (NODES ∪ {s})}. In plain English, this means that
a node v is influenced by all sources who are neighbours of this node in a relative
neighbourhood graph constructed from all vein nodes and this tested source. Note
23
that we need a different graph for checking each source. In the program, UT is
used instead of RNG as described in the previous chapter. Once we identify the
influencing sources, we calculate the direction like we did previously.
The second modification concerns the deletion of sources from the graph. Pre-
viously, we just deleted the source as soon as a node came close enough. This has
to be changed, because when a closed pattern forms, one vein may reach the source
well ahead of the other. Therefore, once the first node reaches the source, the source
is not deleted, but merely tagged as being a candidate for deletion. The nodes ap-
proaching it (i.e. those which are influenced by the source) are also tagged. The
tags are inherited by the node that grows from the tagged node in the next itera-
tion step (of course, the parent node loses its tag). The source is only deleted if all
approaching nodes have either reached the source or moved a certain distance away
from it (this “forgetting” distance is an additional program parameter).
Once these modifications have been applied, there remains one more obstacle:
the calculation of vein width. This is not straightforward at all, and indeed Runions
et al. [2005] have left us with a vague statement that “child veins entering a vein
node contribute equally to the width of the parent nodes”. This does not address the
main issue, which is the fact that the graph representing a closed venation pattern
is an arbitrary graph and not a tree and this the edges cannot be sorted in a way
facilitating the generation of their widths. It has been decided to resolve this issue
by special treatment of the situation when two nodes attracted by the same source
meet. In this case, the nodes are not merged, but two logically distinct nodes are
added at the same location. They are then connected by an artificial edge of zero
length (see accompanying figure).
Figure 2.3: A new node reaches an existing node. Two coupled points have the same
coordinates.
This means that in fact, a tree topology is artificially imposed on a non-tree
graph with the effect of thinning out some edges in the final pattern. This is a big
disadvantage, but the author of the thesis knows of no better solution.
24
All aspects of the algorithm have been implemented in the accompanying pro-
gram, barring the simulation of leaf growth. Leaf growth is an important aspect of
the model, but it had to be omitted because of the limited time available to prepare
the program. Also, it was not the purpose of this thesis to model the process of
leaf development over time. A modification also needed to be made regarding the
initial conditions. Because results of starting the algorithm with only one initial
node, or only with the central axis of the leaf proved inadequate, it was necessary
to manually pre-set a good-looking initial vein configuration. The generation of this
initial configuration is controlled by several parameters left to the user (see figure
for details).
Figure 2.4: Initial leaf venation as generated by the leaf designer. Only half of
the leaf is shown. The user controls the following parameters: the bounding curve,
loop inclination, loop number, distance from loops to boundary and the sampling
resolution (loops are made of line segments)
2.2 Leaf texture
Once the geometry and topology of the leaf venation pattern have been generated,
there still remains the question of how to texture the areas of the plant leaf between
the veins. Ideally, the colour of the leaf surface in these areas should be dependent
on the surrounding vein pattern and on the shape of the leaf. However, it turns
out that satisfactory results may be obtained by using a simple technique of making
the background entirely independent of the venation pattern. Fuhrer [2005] gave
a recipe for doing this with Photoshop. He used the texture for ray tracing and
got high-quality results, so it seems that it would be overkill to try to implement
a more complex procedure designed with real-time rendering of the plant in mind.
The procedure includes the following steps. The list only describes the underlying
idea, Photoshop-specific information has been omitted.
1. First, a cloud pattern is generated.
2. Then, additional noise is added to the pattern.
3. The pattern is softened by adding Gaussian blur.
4. The pattern is converted to greyscale.
25
5. The pattern is used to make a saturated image, which is the result of in-
terpolating between two user-specified colours in such a way that one colour
corresponds to the lighter and the other colour to the darker part of the image.
6. A venation pattern, softened with Gaussian blur is superimposed on the pat-
tern.
7. The resulting image is cropped to match the outline of a leaf.
Fuhrer [2005] also gives a similar procedure that can be used to obtain bump-maps,
but the program developed for this thesis does not use any. Of course, the program
does not depend on Photoshop. Instead, the ImageMagick raster graphics library
is used to obtain equivalent results. In particular, the use of the Photoshop filter
that generates fractal clouds was replaced with the plasma fractal generator which
comes with ImageMagick (given appropriate configuration, they give visually similar
results).
The following figure compares the actual photo of a croton leaf with an artificially-
generated equivalent. As can be seen, considerable dissimilarities remain apparent.
Figure 2.5: Generated leaf vs. real leaf image (source: own photo).
2.3 Triangulation of leaf surface and deformation into
the third dimension
It is of course imperative to achieving the proper looks of the plant that the are
wrapped in a natural fashion. The best, most general solution, is the one employed
by Mundermann et al. [2003]. They have used sticky splines, a modification of spline
curves that maintains the topology of the modelled structure, to construct the leaf
skeleton and devised a special algorithm that is able to generate such skeletons
26
automatically. Naturally, the constructed skeleton corresponds directly to the leaf’s
venation pattern. This allows them to represent arbitrary leaf lobes and thus produce
high-quality renderings of the plants. This approach, however, is both complicated
and computationally expensive, since each primary or secondary leaf vein must be
given its representation in the form of an appropriate spline. Therefore, it is better
suited to plant rendering than to real-time display.
In search of a simpler solution, it became apparent that as long as we do not need
to model leaf deformation that is due to the venation pattern, it suffices to provide
just an arbitrary triangulation of a flat leaf shape, which can then be bent into the
third dimension. It is, however, important that the triangulation is accurate enough
near the brim of the leaf blade, so that jagged edges can be avoided. The program
uses the following procedure to obtain a workable triangulation:
1. a black-and-white mask of the leaf shape is generated form the leaf boundary,
2. a square gird is imposed on the mask, and points within the boundary are
marked,
3. points along the boundary are added, in such a way that they are more densely
spaced than the points within the leaf interior,
4. edges that follow the leaf boundary are constructed and an algorithm con-
structing a constrained Delaunay triangulation is run on the points (the pre-
generated edges serve as constrains in the algorithm),
5. triangles outside of the leaf shape are eliminated.
The last stage is necessary because unnecessary edges may be generated by the
triangulation algorithm if the shape of the leaf boundary that we begin with is
concave. A triangle is considered to be outside the leaf shape if its centroid is
outside the leaf shape. Observe that due to the constraints, no triangle can traverse
the boundary of the leaf shape (barring, of course, the effects of sampling the shape
at an insufficient number of points).
The procedure of obtaining the leaf mesh is outlined in the following figure.
27
Figure 2.6: Stages in the generation of leaf mesh.
Once we have the mesh, it has to be deformed to account for the bending of the
leaf. The program uses a simple, but relatively effective solution that assumes that
the deformation of the leaf surface into the third dimension is a function of only the
y coordinate of the flat leaf surface (the one that goes along the leaf axis). The user
defines the function in that they are asked to specify the deformation of the leaf as
a cardinal spline. The length of the specified curve is mapped to the length of the
leaf, and the vertices of the mesh are modified accordingly. More formally, the leaf
transformation is represented by the following formula.
f(x, y) : [0, width]× [0, height]→
[0, width]× [0, height]× [−height,+height]
f(x, y) =
x (x′)
splineu(y) (y′)
splinev(y) (z′)
The letters x, y denote coordinates in the flat space of the leaf before the modifi-
cation. The letters x′, y′, z′ denote coordinates in the three-dimensional destination
space. width, height correspond to the dimensions of the bounding rectangle of the
flat leaf area. splineu, splinev are functions that represent the shape of the specified
spline at a given point y along the length of the curve (see figure for clarification).
Please note the the distance the leaf is allowed to move into the third dimension is set
to ±height. This is essentially arbitrary. Please also note that the first coordinate
remains unchanged.
The figure shows an example of a user-specified curve illustrating the meaning
of the functions splineu, splinev, together with the resulting leaf shape.
28
Figure 2.7: The leaf deformation curve (above) and a schematic drawing of a de-
formed leaf (below).
The outlined way of modifying the leaf surface could be extended to achieve more
realistic results by eliminating the indifference of the process to the x coordinate of
the leaf. This would allow the leaf shape to vary with the distance from the leaf axis,
along a second user-specified curve. However, this would most probably still not yield
truly realistic shapes, as long as the displacement due to the two coordinates would
be independent of the other (and if they were dependent, we would get the general
question of how to model an arbitrary surface, which we want to avoid). Another
disadvantage of allowing the user to modify the shape of the leaf in reference to
the x coordinate is that it would have made the prevention of self-intersections more
difficult. Currently, the leaf will self-intersect only if the user-specified curve does so,
which means the user can easily prevent this form happening. It therefore appears
that the best way of achieving a really marked improvement in the results would be
following along the ideas of Mundermann et al. [2003].
2.4 Stem texture
While there seems to have been considerable research into the ways of generating
aesthetically appealing textures of tree bark, I could not find a ready algorithm
specifically geared at reproducing the outer looks of the stems of non-tree plants.
Because devising a new algorithm would be complex, I have opted to use a simple
bark-like pattern that is fast and easy to compute while delivering results of passable
quality. There have been quite a number of different approaches to obtaining the
texture of tree bark:
1. Bloomenthal [1985] used X-rays of real tree bark, which were later post-
processed to make the texture wrap,
2. Oppenheimer [1986] used a noise pattern run through a sawtooth function,
3. Hart and Baker [1996] use a specially-devised particle flow system that gen-
erates a texture for the whole tree in such a way that branching points are
29
properly accounted for,
4. Federl [2003], describes two physically-motivated approaches: the simulation
of mass-spring systems and a finite element algorithm for fracture formation
in stiff materials,
5. Wang et al. [2003] introduced complex software that can be used to gener-
ate photographic-quality bark of all kinds, but is heavily dependent on user
interaction and needs digital images of bark as input.
Because the procedural generation of textures is not the primary focus of the present
thesis, I chose the solution due to Oppenheimer [1986]. His algorithm takes three
inputs: a noise image, an integer N specifying the number of bark ridges and a
real R specifying the roughness of the bark. It generates the output bark texture
according to the following formula:
bark(x, y) = saw (N ∗ (x+R ∗ noise(x, y)))
bark(x, y) : [0, 1]× [0, 1]→ [0, 1]; noise(x, y) : [0, 1]× [0, 1]→ [0, 1]; N ∈ N;R ∈ R+
The sawtooth function is defined as follows:
saw(x) =
2 ∗ fraction(t) if fraction(t) < 0.5
2 ∗ (1− fraction(t)) if fraction(t) ≥ 0.5
It is immediately apparent form the formula that the texture bark wraps in both
dimensions as long as the input noise pattern noise wraps. The question remains
which noise pattern one should use. Oppenheimer [1986] used Brownian fractal
noise, which, however, requires a complex algorithm to compute. For simplicity,
I chose to instead use a fractal noise generator integrated into the ImageMagick
library, called plasma, which is easy to use and delivers acceptable results. Because
the noise generated by ImageMagick does not tile, the noise image is modified in
that four symmetric variants of the same generated image are averaged with equal
weights. Theoretically, this may disturb the properties of the noise, but the visual
effect of such modification on the generated bark is minimal.
The result of the described procedure is a greyscale image. To obtain colour,
the image is saturated using a gradient specified by two user-definable colours. The
first, dominant colour occupies the first half of the gradient, while the second half is
a linear interpolation between the two colours in the RGB colour space.
The following figures demonstrate textures generated using various parameters
30
Figure 2.8: Samples of stem textures generated by the described algorithm. From
left to right, the values of (N,R) are: (3, 0.3), (3, 0.8), (6, 1.1) .
2.5 Using the Lindenmayer system
The program provides an implementation of context-free parametric Lindenmayer
systems. It has been decided that these provide enough flexibility to model an
adequate scope of plants. The plant is constructed in that the string resulting
from iterating a Lindenmayer system a specified number of times is scanned for the
symbols listed below (all other symbols are ignored). The drawing takes place in
a turtle-like manner in that the drawing turtle has a state at any given time. The
state comprises location and rotation (which is represented as a 4×4 transformation
matrix). Therefore, turtle state can be viewed as an alternative reference frame
embedded into the 3d scene.
Symbol Action
F (l, r) Draws a stem segment(cylinder) of length l and radius
r. The cylinder follows the Z axis. Its base matches
the XY plane.
L(l) Draws a leaf. The length of the main axis of the leaf
equals l.
[ Puts current turtle state onto the stack.
] Discards current turtle state and pops the new state
from the state stack.
+(α) Rotates the turtle by α degrees around the X axis.
&(β) Rotates the turtle by β degrees around the Y axis.
/(γ) Rotates the turtle by γ degrees around the Z axis.
If a special symbol is used with more parameters then required, the remaining pa-
rameters are ignored. If it has too few parameters, an error occurs.
31
While the described drawing framework is reasonably simple (and indeed, it
would not become much more complicated if we added new geometric possibilities),
the central question remains of how to devise a system that models the plant we
want to reproduce. There is no general solution, but Prusinkiewicz and Lindenmayer
[1996] describes several useful techniques. They are outlined below.
1. Trying to explain the shape of the plant with parent-child relations. It is easy
to transmit a signal from a parent node to a child node: one parameter suffices.
A signal may mean anything, for example the beginning of a new stage in plant
development.
2. Trying to explain the shape of the plant with sibling relations. Transmit-
ting signals to siblings is more difficult because it requires the use of context-
sensitivity.
3. Delaying and counting. Sometimes, certain transformations within a plant
should only occur a certain number of times. Prusinkiewicz and Lindenmayer
[1996] cites a certain species of flowers, which always produce the same number
of leaves before producing the flowers. Counting is easily implemented using
one parameter and a conditional expression. This is demonstrated with the
two productions below:
A(i) : i < N → A(i+ 1)
A(i) : i = N → B
Of course, these approaches will usually be mixed.
Sample plants, together with the systems used to generate them are given at the
end of this chapter.
As could be observed from the preceding sections, the use of Lindenmayer sys-
tems is not without disadvantages. The following seem to be the most noticeable:
1. They are difficult to comprehend without actually running the simulation.
2. The process of system development is largely based on trial and error.
3. If we want to improve the looks of the plant by using generalized cylinders
(defined later on), or other fancy surfaces, these have to be kept external
to the system, which implies loss flexibility and the ability to model plant
development,
32
4. Beyond what has been described in the first chapter, they are not easily ex-
tensible in a way that would be beneficial to their use as a tool for modelling
plants.
However, they do not appear to have a reasonable alternative. All other solutions
the author of the thesis is aware of either boil down to using an artist to model plant
shape with of predefined surfaces or to the processing of photos of real plants. This
goes against the main idea of the present thesis, which is to keep the approach
as procedural as possible. In fact, the only aspects of the plant that are directly
controlled by the user are: the leaf shape, veins initially put on the leaf, and leaf
deformation.
2.6 Modelling the shape of the plant’s stem
The issue of how to model a plant’s stem so as to achieve adequate results is a
difficult one because optically-pleasing solutions usually require complex algorithms
to generate the mesh. The problem can be divided into two separate issues:
1. The modelling of a single separate segment of the branch.
Bloomenthal [1985] used the notion of generalised cylinder to model the maple.
He defined it as a surface generated by sweeping a disk along a spline curve, but
others have later extended the definition by using another spline (or any other
curve) instead of a disk. The curve must not necessarily be closed and may
change along the sweep length. Snyder and Kajiya [1992] delivered a formal
analysis of the general case of applying operators from a pre-specified set to
arbitrary continuous partially differentiable functions as a way of modelling
any object. Generalised cylinders are special cases where the sweep operator is
applied to functions corresponding to 2D curves. More recently, Prusinkiewicz
et al. [2001] used generalised cylinders to model plant organs, implementing
them using the turtle approach. Examples of generalised cylinders are shown
in the following figures.
2. The modelling of branch intersections.
Prusinkiewicz et al. [2001] ignored the issue and used a simple OR of the cylin-
ders corresponding to various plant organs. This was not a problem because
they modelled plants with a relatively large number of thin branches, in which
the lack of smoothness at branch intersections is hardly observable. Bloo-
menthal [1985] manually constructed the solid that connects three branches
33
Figure 2.9: Examples of generalised cylinders.
from surface that span along splines. This had the implication that only three
branches were allowed to meet at a given point, which may not have been
an issue with modelling the maple, which was what he tried to do, but may
constitute a considerable obstacle in modelling other plants. Bloomenthal and
Wyvill [1990] use skeletons to model surfaces, and provide a blend of general-
ized cylinders (albeit with fixed radius) as an example. Hart and Baker [1996]
extended this approach to account for the blending of cones.
Whatever the advantages of generalised cylinders may be, they severely compli-
cate the generation of the plant with Lindenmayer Systems. Prusinkiewicz et al.
[2001] uses additional, predefined functions that are external to the system to in-
tegrate the cylinders into their modelling framework. One might argue that this
undermines the primary motivation of using Lindenmayer systems in the fist place,
which is the fact that they work best when applied to the whole process of plant
modelling. If they are not, we lose the ability to exploit them where they have the
greatest potential: in the adaptation of ordinary plant models to account for plant
growth and variations within specimens of the same plant species.
For lack of time, and because of the said difficulties in integrating generalised
cylinders into an application based on Lindenmayer systems, it has been necessary
to give up the use of these fancy algorithms to model the stem. Ordinary (not
generalised) cylinders have been used as a replacement.
2.7 Possibilities of further development
As could be concluded from the preceding sections, almost every aspect of the plant
could be improved on. The list of possible improvements that are most adequate is
presented below.
1. Account for leaf growth in the generation of venation pattern.
This would possibly reduce the reliance on manually pre-set vein configurations
34
as well as allow the user to try out different combinations of leaf shapes and
growth types.
2. Use a morphologically-motivated triangulation of leaf surface.
This would allow for easy modelling of leaf lobes adding another dimension
to the model. It would also reduce the reliance on pre-set leaf deformation
patterns as the degree to which the leaf is lobed and the kind of lobes could be
controlled with additional parameters of tokens in the Lindenmayer system.
3. Find a better algorithm to reproduce stem texture.
The present algorithm is hardly satisfactory. It is a tree bark algorithm and
it models, well, tree bark. While there exists some visual correlation between
tree bark and stem texture, it is vague at best.
4. Apply generalized cylinders to the modelling of plant stem, possibly with
blending.
The current use of ordinary cylinders makes branch intersections very rigid.
Also, branch segments are currently straight, which means the whole plant
has an unnatural look. They are textured independently, which means vi-
sual artefacts appear in places where they meet. A comprehensive modelling
framework based on generalized cylinders would resolve these problems.
5. Prevent self-intersections
The current implementation of both leaf deformation and Lindenmayer system
does not prevent self-intersection. This may be a problem because sometimes
such self-intersections severely deteriorate the plant’s appearance. However,
the only method the author of the thesis is aware of would be a division of
the three dimensional space into tiny cubes and checking whether more than
one primitive contains the centre point of each cube. This would be very slow.
It appears to be very difficult to detect self-intersections in the productions
specifying the Lindenmayer system, without actually iterating it the required
number of steps.
2.8 Sample plants
1. The following system, heavily adapted from Prusinkiewicz and Lindenmayer
[1996], has been used (the system is given in the form used by the program).
35
axiom -> A(100,5,200)
A(s,t,l) -> [&(22.5)F(s,t,l)L(l)A(s,t/2 + 2,l)] /(5*22.5)
[&(22.5)F(s,t,l)L(l)A(s,t/2 + 2,l)] /(7*22.5)
[&(22.5)F(s,t,l)L(l)A(s,t/2 + 2,l)]
F(s,t,l) -> S(t,s,l) /(5*22.5) F(s,t,l)
S(s,t,l) -> F(t,s,l)
Figure 2.10: Plant generated from the system above (3 iterations).
The way the system works is centred around the A token. This token has three
parameters, which stand for the following: the length of a single stem segment,
the width of the stem segment and the length of the leaf. In each iteration,
the A token produces three branches using the [ and ] stack operators. They
protrude from their base at different angles (the / operator). Each branch
consists of an appropriately rotated (&) stem segment (F), a leaf (L) and the
token A which allows it to split further and form child branches in subsequent
iterations. Note how the stem width is decreased as the plant grows. It
is guaranteed to be at least 2 so that the stem remains visible. Note also
how the last two productions account for the growth of already-formed stem
segments. When this production is used, the segments will already have been
in the model for at least one iteration, they are therefore ”older” and thus
need to be more pronounced. Also, the production introduces the rotation
around the central axis to prevent the resulting structure form appearing too
symmetrical.
2. Below is presented a system that reproduces a yucca plant
axiom -> A(175,25,250)
A(s,t,l) -> F(s,t) B(7,6,l,60,s,t)
36
B(h,v,l,d,s,t) -> BN(h,v,v,l,d,s,t)
BN(h,v,i,l,d,s,t) -> LR(h,l,d*v/i) /(13) F(s/10,t) BN(h-0.4,v-1,i,l,d,s/2,t)
LR(n,l,d) -> LRN(n,n,l,d)
LRN(i,n,l,d): i == 0 -> eps
LRN(i,n,l,d): i > 0 -> [+(d)L(l)] /(360/n) LRN(i-1,n,l,d)
Figure 2.11: A real yucca photo (source: www.pyraflora.co.za) together with models
generated with 100 (centre) and 10 (right) iterations of the system above.
This model was been inspired by a photo of a real yucca plant. First, look at
the last three productions below: they represent a ”procedure” ”invoked” by
using the LR(n,l,d) token. It draws n uniformly distributed leaves of length
n and inclination d. The two productions from B and BN generate a num-
ber of such concentric leaf groups (once group is added for one iteration). The
parameters of the leafs are varied to achieve a less symmetrical look. In partic-
ular the inclination change reproduces the dome-like shape of the whole plant.
After each group of leaves has been drawn, the coordinate system is rotated so
that the leaves of the next group do not protrude from the plant at the same
angles. Also, a short stem segment is added. The token A is used to add the
first, long stem segment and initiate the generation process.
3. This system reproduces a fern leaf. It is a heavily modified version of a system
proposed by Prusinkiewicz and Lindenmayer [1996].
axiom -> S
S -> F(2,1) [ +(40) /(90) L(11,1) ] [+(-40) /(90) L(11,1) ]
+(9) F(2,1) [ /(90) L(11,4) ]
F(s,t) -> F(s*1.2,t)
L(l,i) : i< 4 -> L(l*1.2, i+1)
37
L(l,i) : i==4 -> [ / (270) S ]
Figure 2.12: A real fern photo (source: Wikipedia) together with a generated model
(20 iterations).
The basic idea of this system is based on the fractal-like structure of a fern
leaf, where smaller elements have the same structure as larger elements. The
basic building block of the fern leaf is represented with the production from S:
two branches (L) protrude from a stem made from to segments. The rotation
before drawing the leaves is necessary so that the surface of the leaves is aligned
with the surface of the whole leaf. The rotation +(9) before the creation of
the second stem segment is used to make the whole leaf bend. Note how
the L symbol, whose main purpose is the creation of leaves is used to create
branches. Its second parameter is used in a timer, which converts the leaf to
the basic building block after a fixed number of iterations (this is done .using
the two last productions). This way, the youngest generation of created objects
is rendered in the form of leaves. The disadvantage is that this has absolutely
no biological motivation, but it looks good enough. The production from F is
used to elongate the existing stem segments so there is enough place for the
emergence of new ones in the following iteration steps.
4. This system reproduces a cabbage head.
axiom -> B(4,100,75)
B(h,l,d) -> LR(h,l,d) /(13) B(h-0.3,l,d/2)
LR(n,l,d) -> LRN(n,n,l,d)
LRN(i,n,l,d): i == 0 -> eps
LRN(i,n,l,d): i > 0 -> [+(d)L(l)] /(360/n) LRN(i-1,n,l,d)
38
Figure 2.13: A real cabbage photo (source: www.hort.purdue.edu) together with a
generated model (10 iterations).
The idea of the system arose when working on the yucca plant, and indeed the
two systems are similar, and the leaf-drawing procedure represented by the
symbol LR is even identical. This is an excellent example of how a seemingly
small modification to the system yields a completely different plant (although
other aspects of the plant have been modified as well). The key difference is
in the way the inclination of the leaves in controlled: with the yucca plant,
the inclination changed linearly with respect to the iteration step, here it
decreases exponentially (the d/2 parameter in the second production). This
has the effect that the concentration of leaves near the plant centre is much
higher than on the boundary. Also, the leaves near the plant centre begin to
self-intersect, which of course is not realistic as such, but creates a visually
pleasing filled area near the centre of the plant.
39
Chapter 3
Implementation
This chapter summarizes technical decisions taken during the development of the
program accompanying this thesis.
3.1 The choice of the technology
It was immediately obvious that the program had to be implemented in a managed
language to facilitate its primary function a test field for algorithms. Managed lan-
guages make it easy to create flexible designs at the cost of code speed. However,
code speed is not that important while researching algorithms. In fact, it turned
out that the program runs quite fast (less than one minute for the most complicated
algorithm, generating the venation pattern of the leaf). Also, IDE automation (sup-
port for refactoring, unit testing etc.) is better with managed languages. Therefore,
there remained the following choices:
1. Sun Java
2. Microsoft C# / .NET
3. Adobe Flex
It has been decided to use the C# language (version 2.0). This decision was made
because of easy interoperation with unmanaged code (the program uses external
unmanaged libraries, which do not have ready bindings for any of the said solutions),
because the tools for user interface design are better as well as because Microsoft
delivers a ready Managed DirectX component, which seems to be easier to use than
the Java3D API delivered by Sun.
Of course, the main difficulty of this thesis is in the assembly of the toolchain
algorithms, which is essentially independent of the choice of language, so most prob-
41
ably any of the said solutions would work well enough.
3.2 The design and structure of the program
The program has a modular architecture, which means that modifications to the way
various aspects of the program are implemented can be done in a way independent of
one another. The following list gives a brief description of each module and presents
the most important implementation decisions take during its development.
1. The toolchain controls
The program consists of several controls, each responsible for a stage of the
toolchain described in the previous chapter. They include controls for: design-
ing leaf shape, designing leaf veins, specifying leaf deformation, leaf texture,
stem texture and the Lindenmayer System. These controls are not created
each the user invokes a given option, but only once, during the initialization
of the program. This allows for a more responsive interface.
2. Data module.
This module serves as a central database of the aspect of the plant that a user
can modify. The data module maintains a collection of the toolchain controls
and enables each part of the program to access data stored in other parts.
For example, the algorithm that generates plant mesh once the user clicks
the View Plant button has to access, among others, the stem texture, which
is stored in an object of type StemTextureGeneratorControl. To do this, it
simply retrieves a reference to the control responsible for the texture from this
central database. This is done like this:
[C#]
StemTextureGeneratorControl stcg = (StemTextureGeneratorControl)
ComponentStorage.Instance.GetControl(
typeof(StemTextureGeneratorControl)))
In this code, the static property ComponentStorage.Instance returns the one
and only object that holds references to the stored data. Please note that the
design idea of having all data in the same place, and accessible through a fixed
interface has the added benefit of making it very easy to save plants to files.
Moreover, it makes it easy to support the possibility that the user cancelled
the changes done in the control. This is not trivial, because these changes may
42
concern a huge load of data (for example, the venation graph). As could be
observed in the above snipplet, all toolchain controls share a common parent
class, AcceptCancelControl. This class has the following methods, which the
child controls then can override:
[C#]
public class AcceptCancelControl : UserControl {
public virtual void AcceptChanges() { }
public virtual void CancelChanges() { }
public virtual void SaveToStream(Stream s) { }
public virtual void LoadFromStream(Stream s) { }
[...]
}
Their names are self-explanatory: they make it easy to save and retrieve the
state of the settings within the control tat a user can change. It also provides
two convenience methods: AccepthChanges() and CancelChanges() to easily
support OK and Cancel buttons. The serialization of controls’ contents had
to be implemented manually, because Windows Forms controls are not serial-
izable. This is hardly surprising since they wrap around unmanaged objects
that depend on the Windows resource allocation scheme: for example, each
window (and every visible control is in fact a window) has a unique HWND
identifier, which cannot be serialized because it is allocated by Windows when
the window is created. Therefore, each control has a corresponding settings
class, which is used to persist the control’s state. For example, the LeafTex-
tureControl has an inner class LeafTextureControl.FormSettings, which stores
the values of the settings set by the user.
All data in the program is stored in such FormSettings objects, apart from
two special cases, which are noteworthy because of their importance to the
algorithms employed: the leaf venation graph and the leaf boundary, which
have dedicated classes. The leaf boundary class stores a spline curve and
provides methods for providing a mask and the bounding rectangle of the
enclosed shape as well as determining whether a point is inside the shape.
The venation graph is represented as an object graph (i.e.. each graph node
is an object which stores references to the “child” and “parent” nodes). This
approach makes it easy to traverse and paint the graph.
3. Algorithm module
43
This module provides an implementation of the algorithms described in the
previous chapter. Only the non-trivial aspects of the implementation are dis-
cussed here.
In the algorithm that generates the venation pattern, a data structure was
needed to account for the tagging of sources that have been reached by one,
but not all nodes. This structure had to support the basic operations listed
below.
(a) Insertion of a pair (vein node, source). This is needed when the nodes
are tagged.
(b) Removal of a pair (vein node, source). This is needed when a node reaches
the source, or ventures too far from the source.
(c) Retrieval of all pairs contacting a given vein node. This is needed to
update the tags when the vein grows.
(d) Retrieval of all pairs containing a given source. This is needed to check
if the source should be deleted.
This interface directly corresponds to a simple database-table. Therefore, a
.NET DataTable has been used to sore the tags. Please note that, in addition
to the said structure, a set is required to hold the sources which are considered
for deletion to implement the tagging. This is because if no pair with a given
source exists in the table, it may both mean that no nodes have yet reached
it, or that every node that could have reached it has already done so.
In the algorithm that generates the leaf texture, a mix of Windows GDI+ and
ImageMagick APIs has been used. GDI+ is used to generate the initial vein
pattern and for clipping, while ImageMagick is used to generate the leaf back-
ground and blend it with the veins. This combination allows the program to
profit from the advantages of both solutions, which is the ability to easily draw
geometric primitives for GDI+ and the ability to quickly complete expensive
raster operations for ImageMagick.
4. Parsing Lindenmayer Systems
A simple Lindenmayer system parser has been written with the help of the
GPLEX lexer for C#. Parsing context-free parametric Lindenmayer systems
is simple, apart from the evaluation of arithmetic expressions and conditions.
It turned out that there is a simpler solution of doing this than using a parser
44
generator: .NET provides a handy toolkit for run-time compilation. Therefore,
for each expression a class can be generated that contains a function, which
evaluates the expression for the given parameters. Conditions are handled
likewise. The class is generated from a string with C# source code like this:
[C#]
public Assembly GetAsseblyFromSource(string source) {
CompilerResults cr = provider.
CompileAssemblyFromSource(compParams, source);
foreach (CompilerError ce in cr.Errors) {
//handle errors
}
return cr.CompiledAssembly;
}
The class can be then instantiated and the function evaluated:
[C#]
[...]
IParamEval ip = (IParamEval)GetAsseblyFromSource(source).
CreateInstance("ParamEval");
double param1, param2;
double result = ip.Param(new double [] { param1, param2 } );
[...]
public interface IParamEval {
double Param(double [] __p);
}
IParamEval is the interface implemented by all generated classes (there is a
similar IBoolEval interface for evaluating conditions).
5. The GUI
The program uses a simple Windows Forms user interface. It is easy to build
and has excellent documentation. It has been decided that it is functional
enough and that the use of fancy toolkits like WPF would not add value to
the main purpose of the program: the evaluation of algorithms for various
aspects of plant generation.
45
6. Visualization with DirectX
Although the author of this thesis has a personal preference for OpenGL,
it has been decided to use DirectX as a foundation for the 3D visualization
control because Microsoft provides reasonably complete bindings in the form
of a ready component, which is a part (albeit an optional one), of the popular
DirectX distribution. Unfortunately, it was necessary to stick with the obsolete
Managed DirectX 1.1, because the new 2.0 version was abandoned by Microsoft
in favour of the XNA technology.
To render the plant, the following features of DirectX have been used:
(a) Leaves are represented with Mesh objects, which are created from trian-
gles obtained in the way described in the toolchain section. Of course, the
triangles are adorned with texture coordinate information beforehand.
(b) Stem segments (cylinders) are also represented by Mesh objects, but they
are created by DirectX’s internal facility for creating 3D primitives. Tex-
ture wrapping in the horizontal dimension is applied during the mapping
of stem texture onto the cylinder to achieve continuous visual appearance.
The objects can then be displayed either as wireframe skeletons, or as solids
only lit with ambient light.
3.3 The use of external libraries
During the work on this thesis, it has been decided that some portions of work need
to be “outsourced” to external libraries. This saved both development time, allowing
more to be spent on the actual study of generating the plant. Also, external libraries
save computation time, because they are implemented unmanaged code, and usually
in a highly optimal way.
The following two libraries have been used.
1. CGAL
This library provides excellent routines for computing unconstrained and con-
strained Delaunay triangulations of arbitrary point sets. It makes heavy use
of template metaprogramming and is thus very fast. In fact, the program
only uses a fraction of the capabilities that this library offers. Also, it is very
extensible. For example, in the process of writing the program, it became
apparent that the points being triangulated needed to be give unique indices.
46
The library was designed well enough that it provided the option of inserting
a custom point class, which solved the problem.
While the way it is used to triangulate point sets is quite straightforward,
it deserves a mention how Urquhart triangulation was obtained. The follow-
ing code stores the indices of points incident to point (x, y) in an Urquhart
triangulation of set S ∪ {(x, y)}, where S is a set of points that has already
been triangulated once this function is run. To avoid cluttering the code with
unnecessary details, a simplified version of the code is printed.
[pseudocode adapted from C++]
//Delaunay triangulation, already contains some points
Triangulation T;
void InsertPoint(int x, int y) {
vector adjacentPoints;
PointHandle ph = T.Insert(new Point (x,y) );
foreach (PointHandle p adjacent to ph in T) {
if (IncludeEdge(previous(p), p, next(p), ph))
adjacentPoints.Add(p);
}
T.Remove(ph);
}
bool IncludeEdge(PointHandle left, PointHandle x,
PointHandle r, PointHandle np);
The function IncludeEdge() returns false if (np, x) is the longest edge of the
triangle (np, x, left) or (np, x, right), otherwise it returns true. Therefore, we
only add those vertices adjacent to the new vertex in a Delaunay triangulation,
which are also adjacent to it in the Urquhart triangulation. The reason for
this is explained in greater detail in the first chapter.
The used version of CGAL was 3.3.1, the most recent at the time of writing
the program.
2. ImageMagick
This library facilitates fast processing of raster images. The following features
of the library were used: plasma generator (generates an image of fractal
47
noise), two filters (“Gaussian blur” and “add noise”) and the clut operator.
The clut operator transforms a greyscale image in that it takes a gradient and
saturates the image according to the gradient. An example of how it work is
provided in the figure below.
Figure 3.1: The clut operator at work (source: ImageMagick manual)
There have been problems with using ImageMagick, because Magick.NET, the
binding library for .NET is very poorly documented. It also lacked the support
of the clut operator, and did not work with the latest version of the library.
Therefore, it was necessary to modify the source code of the wrapper to make
up for these shortcomings.
The used version was 6.3.8, the most recent at the time of writing the program.
3.4 Possibilities of further development
It should be obvious from the preceding sections that several issues could be im-
proved upon in the program implementation.
• Run-time noise and texture generation. Both algorithms that generate textures
are really based on noise, which is then transformed to achieve the desired look.
This could be exploited and pixel shaders could be used to generate the noise,
and the corresponding texture, at run-time. This would allow a very high
level of detail, since a more precise version of the noise, and the texture, could
always be generated as the user zooms in. There would also be no need to
store the textures, barring the venation pattern, which would still have to be
pre-computed.
• More differentiated light. New light sources could be added to enable the
leaves to be shaded in a more realistic way.
• Leaf distortion along veins. Currently, the veins have no influence whatsoever
on the way a leaf bends. This would make light appear unnaturally. Therefore,
it would be necessary to at least generate a bump map for the venation pattern
(a good procedure is given in Fuhrer [2005]). A yet better way would be to use
48
a geometry shader to generate real new vertices on the leaf surface, that would
make it trace the veins. Note that it would be difficult, because we would have
to account for the leaf volume to make it look good from both sides.
3.5 User’s manual
Because of the implementation decisions taken in the course of program development,
the following prerequisites must be met to run it:
1. .NET Framework 2.0 (or newer)
2. Microsoft C/C++ Runtime Libraries for Visual Studio 2005 SP1
3. DirectX 9.0c (from November 2007)
All of these are freely available for download from Microsoft.
1. Main Menu
The main menu of the program is presented in the figure below. Each of the
big buttons corresponds to one stage in the toolchain of plant generation.
Figure 3.2: The main menu of the program.
(a) Leaf Veins and Shape Use this to edit the leaf bounding curve, move leaf
veins around the leaf and generate leaf veins procedurally.
(b) Leaf Deformation. Use this to determine how leafs bend into the third
dimension.
(c) Leaf Texture. Use this to set parameters used to generate leaf texture
(background on which veins are painted).
(d) Stem Texture. Use this to set parameters used to generate bark pattern
used to texture the plant stem.
49
(e) L-System input. Use this to enter an L-System that defines the general
shape of the plant.
(f) The View Plant button activates a DirectX window that visualizes the
generated plant.
(g) The Load and Save buttons are used to save a plant to, or load it form a
file.
2. Leaf Veins and Shape
Figure 3.3: The dialog window for generating veins and manipulating leaf shape.
Use the Design Leaf Shape button to create a rough approximation of the leaf
shape and veins.
Then use the preview pane on the left to move around veins and/or add new
nodes. Nodes are added and removed using the context (right-click) menu. To
add a new vein node you first need to set it’s parent node, likewise with the
context menu.
The settings in Growth and Sources panes are used by the leaf-growth algo-
rithm. They work as follows:
The basic idea of the algorithm is that veins grow towards sources, which are
scattered on the leaf surface of the leaf beforehand. Once all veins growing
towards a given source reach the source, the source is removed and a new one
is added at a random location on the leaf.
(a) Grow distance: the distance (in pixels) by which a vein grows towards a
source in one algorithm step.
(b) Reach distance: the distance (in pixels) that is used to determine if a
vein has reached the source.
50
(c) Forgetting distance: nodes that have moved further than the forgetting
distance from a source are considered irrelevant to the source. Therefore,
they source may be removed even if they have not reached it.
(d) Number of sources: the initial number of sources scattered on the leaf
surface. If it is too large, and it is impossible to scatter the sources in
a way that satisfies the constrains set by 5. and 6., a smaller number of
sources is used.
(e) Minimum node distance: the minimum distance from a newly-added
source to existing vein nodes.
(f) Minimum source distance: the minimum distance from a newly-added
source to existing sources.
(g) The Run Button starts the vein-growing algorithm.
(h) The number of steps is determined with the Steps setting.
3. Leaf Shape Designer
Figure 3.4: The dialog used set leaf shape and initial vein loops.
Use the leaf display to modify a curve that bounds the leaf surface.
Drag points to edit curve. Double-click to add new curve points. Right-click
to delete points.
The set the following options that specify the way the inner vein loops are
generated.
(a) Node distance: the resolution of the loops. The smaller the distance, the
more nodes are added.
(b) Loop number: the number of vein loops that the program tries to add.
A loop will not be added if it does not fit into the bounding curve.
51
(c) Border distance: the distance between the loop’s ending and the leaf
boundary.
(d) Angle: inclination of the loops.
4. Leaf Deformation
Figure 3.5: The dialog used to deform the leaf into the third dimension.
Use this display to modify the way in which the leaf is displaced into the third
dimension.
The leaf is displaced in such a way that it’s central axis is mapped to the drawn
curve. The curve’s length may change, but he leaf will always be mapped to
the whole curve.
Drag points to edit curve. Double-click to add new curve points. Right-click
to delete points.
This feature does not prevent self-intersections.
5. Leaf Texture
Figure 3.6: The dialog used set parameters for the generation of leaf background.
52
This display is used to generate the bitmap used to texture the leaf background.
The texture generation algorithm works in that it generates a greyscale plasma
fractal and than saturates it using the two specified colours. The resulting
image is then blurred.
The following settings are available:
(a) Blur sigma / radius: the parameters used to blur the image. The blur
is a convolution determined by a two dimensional Gaussian distribution
with the specified sigma and radius.
(b) Colours: the colours used to saturate the fractal
6. Stem Texture
Figure 3.7: The dialog used set parameters for the generation of the stem texture.
This display is used to define the texture of the plant’s stem. The following
settings are available:
(a) Ridges: defines the number of vertical ridges in the texture.
(b) Roughness: defines the amount of noise in the resulting texture.
(c) Dominant colour / additional colour: sets the two colours used to saturate
the texture. The dominant colour is more prevalent.
(d) Texture size: sets the final size of the texture.
7. L-System settings
53
Figure 3.8: The dialog used to input the L-system.
This display is used to specify the formula used to generate the general shape
of the plant.
The program implements context-free parametric Lindenmayer systems.
The Wrap button turns line wrapping on and off.
The first production must start with the symbol axiom. This symbol is used
to start the generation.
Productions have the following format:
symbol : condition -> symbol1 symbol2 ... symboln
Symbols may have parameters, which are included in parentheses. The pa-
rameters may be used to specify conditions.
Example: A(t,s) : t>5 && s==3 -> B(t+4,s/2) F(t,s-4)
All symbols are treated in the same way while the system is used to generate
the output sequence. In the output sequence, all symbols are ignored except
the special symbols used to draw the plant (listed in the toolchain chapter).
8. 3D Viewer
54
Figure 3.9: The 3d viewer window.
This window uses DirectX to provide a visual representation to the generated
system. The drop-down box is used to select the wireframe or solid mode. Six
buttons above are used to zoom and to move the camera.
55
Concluding Remarks
Work on this thesis led to many an interesting observation throughout the spectrum
of issues associated with the generation of plants. A large number of topics has been
covered that span over the whole plant generation toolchain. Here, thoughts arising
from these endeavours are given.
It is quite obvious that the issue central to the whole process is the question
of how to get the utmost use from the formalism of Lindenmayer systems. Sadly,
it seems adequate to conclude that the promised biologically-motivated means of
modelling organic structures in a fast and easy way has yet to come into being.
The problem with Lindenmayer systems is inherently tied to one of their main
virtues: simplicity. True, it is possible to express complex structures using only a
few productions. True, it is easy to obtain images of the same plant at different
developmental stages if the system is appropriately constructed. This does not
change the fact, however, that it is extremely difficult to extend this formalism to
cover a broad spectrum of objects. Lindenmayer systems are good at describing tree
structures, which is hardly surprising because trees are simple. As soon as more
complexity is required, they fail. One may argue that most plants do have a tree
topology and thus the added complexity is not required. The simplest example of
this limitation it the one that has been encountered while researching leaf venation:
originally, the venation pattern of the leaf was intended to be modelled using an
auxiliary Lindenmayer system. However, it proved impossible to construct a system
that would model a reasonable variety of such systems adequately as it was very
difficult to make the separate veinlets grow together. Consequently, a separate
algorithm had to be introduced. Plants may be tree like in the macro scale, but
they are certainly not so in the micro scale, nor in the scale of the whole ecosystem.
A similar argument applies to other plant features. If one wants smooth branches,
it is necessary to add a generalised cylinders to the model, which is external to
the system. If one wants flowers, another structure has to be added. This has
the effect that once we add everything that is necessary to construct a well-looking
57
plant, the whole model loses its flexibility because these addenda do not have the
developmental potential that a raw Lindenmayer system boasts: we can no longer
trace the way a plant develops. Indeed, during the development of productions, one
is fast tempted to fall into the pitfall of merely viewing the Lindenmayer system
as an exotic variation of programming in LOGO and thus lose whatever biological
founding the model might have had. Naturally, this does not mean that Lindenmayer
systems are out of place. As of now, there exists no better solution for generating
arbitrary plants.
Another aspect of plant modelling that needs to be stressed here is the huge
potential of particle systems. In the effort described in this thesis, they have been
used to model the leaf venation pattern. Their main advantage is the relatively
straightforward way of implementation, at least compared to attempts to tackle the
same issues using a more prescriptive approach. It is also easy to introduce variation
in the generated structures, because the sources are scattered randomly as well as
to model two- or even three-dimensional structures. Actually, attempts have been
made (Rodkaew et al. [2002]) to use them for modelling whole plants, but initial
results were modest at best. In the future, it will probably be possible to improve
on these results and maybe obtain a workable variation of particle systems that
works good for the modelling of the whole plant. It would also be interesting to
see how the proposal to account for stress formation in the leaf made by Couder
et al. [2002] can be used to make the particles move in a more realistic way. In this
context, it seems appropriate to note the analogy between particle and Lindenmayer
systems: if we allow the particles to have arbitrary parameters and the rules that
govern the behaviour of a particle (which may mean both modifying an attribute
of the particle or splitting it into smaller particles) to be based on an arbitrarily
defined neighbourhood of the particle (which may extend to the whole system),
then a Lindenmayer system is just a special case of a particle system constrained to
one dimension and one notion of proximity, where tokens correspond to particles. It
would be interesting to see in what practical ways the use of particle systems may
be beneficial to the modelling of plants.
In summary, it does not seem very original or innovative, but needs to be stated
that plants are inherently complex. Complex objects require complex models, which
usually require complex implementation. This thesis outlined some endeavours on
the way to a better model. It remains to be seen how fast the evolution of computer
graphics leads us to an algorithm that produces truly satisfying results.
58
Bibliography
Diogo Vieira Andrade and Luiz Henrique de Figueiredo. Empirically good approx-
imations for the relative neighbourhood graph, 2003. URL citeseer.ist.psu.
edu/vieiraandrade02empirically.html.
Jules Bloomenthal. Modeling the mighty maple. SIGGRAPH Comput. Graph.,
19(3):305–311, 1985. ISSN 0097-8930. doi: http://doi.acm.org/10.1145/325165.
325249.
Jules Bloomenthal. Skeletal Design of Natural Forms. PhD thesis, University of
Calgary, Calgary, Alta., Canada, Canada, 1995. Adviser-Brian Wyvill.
Jules Bloomenthal and Brian Wyvill. Interactive techniques for implicit modeling. In
SI3D ’90: Proceedings of the 1990 symposium on Interactive 3D graphics, pages
109–116, New York, NY, USA, 1990. ACM. ISBN 0-89791-351-5. doi: http:
//doi.acm.org/10.1145/91385.91427.
CGAL. Computational Geometry Algorithms Library. URL http://www.cgal.org.
Yves Couder, Ludovic Pauchard, Catherine Allain, Moktar Adda-Bedia, and
Stéphane Douady. The leaf venation as formed in a tensorial field. The European
Physical Journal B - Condensed Matter and Complex Systems, 28(2):135–138,
2002. ISSN 1434-6036. doi: http://doi.ieeecomputersociety.org/10.1140/epjb/
e2002-00211-1.
Pavol Federl. Modeling fracture formation on growing surfaces. PhD thesis, Uni-
versity of Calgary, Calgary, Alta., Canada, Canada, 2003. Adviser-Przemyslaw
Prusinkiewicz.
Martin Fuhrer. Hairs, textures, and shades: Improving the realism of plant models
generated with l-systems, 2005. Adviser-Przemyslaw Prusinkiewicz.
Jacob E. Goodman and Joseph O’Rourke, editors. Handbook of discrete and compu-
59
tational geometry. CRC Press, Inc., Boca Raton, FL, USA, 1997. ISBN 0-8493-
8524-5.
GPLEX. The Gardens Point Scanner Generator. URL plas.fit.qut.edu.au/
gplex/.
James Scott Hanan. Paramteric L-systems and their application to the modelling and
visualization of plants. PhD thesis, University of Regina, Regina, Saskatchewan,
Canada, 1992. Adviser-Przemyslaw Prusinkiewicz.
J. Hart and B. Baker. Implicit modeling of tree surfaces, 1996. URL citeseer.
ist.psu.edu/hart96implicit.html.
ImageMagick. The ImageMagick Software Suite. URL www.imagemagick.org.
Lars Mundermann, Peter MacMurchy, Juraj Pivovarov, and Przemyslaw
Prusinkiewicz. Modeling lobed leaves. cgi, 00:60, 2003. ISSN 1530-1052. doi:
http://doi.ieeecomputersociety.org/10.1109/CGI.2003.1214448.
Peter E. Oppenheimer. Real time design and animation of fractal plants and trees.
SIGGRAPH Comput. Graph., 20(4):55–64, 1986. ISSN 0097-8930. doi: http:
//doi.acm.org/10.1145/15886.15892.
Przemyslaw Prusinkiewicz and Aristid Lindenmayer. The algorithmic beauty of
plants. Springer-Verlag New York, Inc., New York, NY, USA, 1996. ISBN 0-
387-94676-4.
Przemyslaw Prusinkiewicz, Lars Mündermann, Radoslaw Karwowski, and Brendan
Lane. The use of positional information in the modeling of plants. In SIGGRAPH
’01: Proceedings of the 28th annual conference on Computer graphics and in-
teractive techniques, pages 289–300, New York, NY, USA, 2001. ACM. ISBN
1-58113-374-X. doi: http://doi.acm.org/10.1145/383259.383291.
Yodthong Rodkaew, Prabhas Chongstitvatana, Suchida Siripant, and Chidchanok
Lursinsap. Modeling and visualization of leaf venation patterns. In International
Conference on Computational Mathematics and Modeling, 2002.
Adam Runions, Martin Fuhrer, Brendan Lane, Pavol Federl, Anne-Gaëlle Rolland-
Lagan, and Przemyslaw Prusinkiewicz. Modeling and visualization of leaf venation
patterns. In SIGGRAPH ’05: ACM SIGGRAPH 2005 Papers, pages 702–711,
New York, NY, USA, 2005. ACM. doi: http://doi.acm.org/10.1145/1186822.
1073251.
60
Arto Salomaa. Formal languages. Academic Press, New York and London, 1973.
ISBN 0126157505.
David Salomon. Computer Graphics and Geometric Modeling. Springer-Verlag New
York, Inc., Secaucus, NJ, USA, 1999. ISBN 0387986820.
John M. Snyder and James T. Kajiya. Generative modeling: a symbolic system for
geometric modeling. SIGGRAPH Comput. Graph., 26(2):369–378, 1992. ISSN
0097-8930. doi: http://doi.acm.org/10.1145/142920.134094.
Julis Taulor-Hell and Gladimir Baranoski. State of the art in the realistic simula-
tion of plant leaf venation systems. Technical Report CS-2002-17, University of
Waterloo, Departament of Computer Science, Waterloo, Ontario, April 2002.
G. Toussaint. The relative neighbourhood graph of a finite planar set, 1980. URL
citeseer.ist.psu.edu/toussaint80relative.html.
Xi Wang, Lifeng Wang, Ligang Liu, Shimin Hu, and Baining Guo. Interactive
modeling of tree bark. In PG ’03: Proceedings of the 11th Pacific Conference
on Computer Graphics and Applications, page 83, Washington, DC, USA, 2003.
IEEE Computer Society. ISBN 0-7695-2028-6.
Wikipedia. Wikipedia, the free encyclopedia. URL wikipedia.org.
61
Warszawa, dnia 11. 03. 2008 r.
Oświadczenie
Oświadczam, że pracę inżynierską pod tytułem: ”Generating 3D Plants” (”Gene-
rowanie trójwymiarowych modeli roślin”), której promotorem jest Dr. Paweł Ko-
towski wykonałem samodzielnie, co poświadczam własnoręcznym podpisem.
.............................................