INTERPRETER SOFTWARE COMING SOON ...

Release Notes
~~~~~~~~~~~~~
Table of Contents
-----------------

a) Parser vs. Interpreter / Contacting the Author
b) Perl-based L-systems
c) The Parser
d) The Interpreter / L-system Extensions
e) Pre-defined Models

Parser vs. Interpreter
~~~~~~~~~~~~~~~~~~~~~~
When I first started to work with the available L-system software, I
noticed one major problem: there are good interpreters for creating
models of parsed L-systems, and there are fairly good parsers.

Unfortunately, because all the parsers use somewhat proprietary languages
and small subsets of the entire L-system "vocabulary", none of them had
the power to produce everything in the Algorithmic Beauty of Plants (ABOP)
book. Since L-systems are primarily self-rewriting and since compiled code
is almost completely un-self-modifiable, I decided that a scripting language
was necessary. Perl seemed the obvious choice since it is not only
cross-platform, but because it excels at string handling, another important
factor of L-systems. On top of this, Perl is very similar to C and will
therefore be somewhat familiar to most programmers.

The interpreter software takes the data from the parser and interprets
it into a complete multi-layer model and allows some editing of the model
before export as a DXF. It also controls pre-defined DXF model scaling and
placement.

The author:

  Sean O'Malley
  http://www.geocities.com/~ffrog
  July, 2000


Perl-based L-systems
~~~~~~~~~~~~~~~~~~~~
Perl-based L-systems are a cheap and easy way to interpret parametric,
stochastic and context-sensitive L-systems. Unlike other interpreters
which rely on proprietary (and often extremely limited) language sets,
Perl L-systems give the benefit of a familiar-looking language (it's
very similar to C), L-systems which retain some similarity to the
original even when converted to Perl code, and virtually limitless
expandability.

See the "Parser" and "Interpreter" sections below for more information.


The Parser
~~~~~~~~~~
The Parser is the Perl implementation that actually creates and processes
the L-system, producing an L-system data file (LSD) containing information
such as the color table, tropism, the final L-string, etc. It is responsible
for creating a complete L-string with only numeric parameters; defined
constants are not exported to the L-system data file (LSD) and are only
used internally for calculations. With only some simple C-like commands,
it is possible to create complex parametric and stochastic L-systems.
A possible extension could be context-sensitive L-systems. This is left
as an exercise for the reader. :-)

Some warnings, however:

1) Be careful when using meta-characters ("dangerous" characters) in
   Perl. Characters that are part of the L-system character set yet are
   meta-characters in Perl include $, \, and %. There are two ways to make
   sure Perl does not attempt to interpret these meta-characters: quoting
   and using single-quoted strings. Quoting is putting a \ character before
   them in a double-quoted string. Using single-quoted string ensure that
   all characters between the single-quotes won't be interpreted. (This
   differs from C where single-quotes refer to characters.) These are
   equivalent: '$$Hello, world!!%%' and "\$\$Hello, world!!\%\%"

2) For using non-alphabetic function names (L-system rules), special steps
   need to be taken. See "template.pl" for more information on this.


The Interpreter / L-System Extensions:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The interpreter is a 32-bit Windows-based application using OpenGL for
rendering. It is currently under extreme construction, as I was attempting
to program both the parser and interpreter simultaneously (this
involves 3 different languages: Perl, VB, C++). At the time of this
writing, it allows you to open and modify L-system models created by
the parser...and that's about it. It also allows pre-defined objects (see
section below).

One of the problems I've encountered with pre-defined object L-systems
is that, because the L-system and the object are defined mathematicalyl,
there is no sense of scale between the two. That is why the interpreter
gives the ability to change the scale of three things: the length the
turtle moves, the width of the connected cylinders, and the scale of the
pre-defined DXF objects. With these three parameters, the complete model
can be tweaked before being exported as the final DXF.

Linked cylinders are used for the actual turtle path, or if the number
of cylinder segments falls below 2, simple lines will be used.

All DXFs *exported* by the interpreter will either contain 3DFACEs only
or 3DFACEs and LINEs (depending on whether cylinders or lines are used).

L-SYSTEM EXTENSIONS:
--------------------
These L-system extensions refer to the Interpreter (if included with
this archive). Any interpreters written to support the data files
created by the Parser may wish to follow these guidelines as well.

The '!' command does not "decrement" the current width of segments;
I found this too arbitrary. Instead, it multiplies the width by 3/4.
For better accuracy, use the ! command parametrically to set the width
algorithmically as the L-system is processed. When using the ! command
at all, it is best to state the width explicitly at least initially (in
the constructor for instance).

Layers in the exported DXF file are based (and named after) the current
color when a particular primitive is rendered. To place one or more
objects on the same layer, make sure they have the same color; similarly,
changing the color of two objects will place them on different layers.
(Use the "color table" to do this.) In this way, even imported objects
can be given different layers so that, when exported as DXF, they can be
textured differently in a 3-d editor or renderer.

Imported object scaling can be achieved by putting a parameter between
the ~ and the object tag. For example, if there is an object designated
"A" and it should be scaled to half its size, the command would be ~(0.5)A
This allows at least a quasi-realistic scaling for fruit, flowers, etc.
Objects of different sizes can be given different colors as well so they
will be exported as separate objects; in this way "younger" or "older"
fruits or flowers can be given different colors/textures. A space is
NOT allowed between the final parenthesis and the object tag.

Use a parameter with the ` or ' commands (color index decrement and
increment) to set the color index explicitly. `(5) and '(5) are
equivalent: they will both set the current color table index to 5 (first
color index is 1).

Support for tropism is currently in a rather primitive state. Also,
the strength of the tropism ("e") is computed differently than in the
ABOP book, so different values may need to be used. The book doesn't seem
to state an explicit algorithm. The one I came up with computes the
rotation angle by taking the length of the vector that is the cross
product of the heading and tropism vectors. It multiples this length by
the tropism "e" value and PI, giving a (somewhat arbitrary) rotation angle.
Then, it rotates the current heading around the cross product vector by
this rotation amount. This ensures that when the heading is directly
opposed or nearly equal to the tropism vector, the heading will not change
much. (Similarly, when the heading is perpendicular to the tropism vector,
it will turn the most, which is physically valid.)


PRE-DEFINED MODELS
~~~~~~~~~~~~~~~~~~
Pre-defined DXF models are also allowed, but currently the
maximum size of the model is 5000 faces (5000 quads or 5000 triangles),
although with most L-systems where pre-defined objects are repeated
hundreds or thousands of times, it is not recommended that a model ever
get near this size!

DXF Limitations: DXFs used as pre-defined models must use 3DFACE elements
only. As an example, when exporting a DXF from the modeller Rhinocerous,
select the earliest DXF version as possible, select "3DFACE" output and
an "ENTITIES-only" file. Any spline-based objects will need to be
converted to quads before being used.
