Here is a simple animation (QuickTime, 6Mb)
with code , which simulates the `enviroment
sensitive automata', using timed L-System to alter the shape of objects
and ray-casting to realize `obstacles avoidance'.
RayTraced Evolution is a programable scenes-generator
for raytracers/renderers, using spTOL(stochastic, parametric, contex-free
and table-oriented Lindenmayer- System:) and C-like functions.
2.FEATURES:
Interprets C-like statments in RTEvol's functions, which
can be used as stand-alone routines, or as nodes to rewrite in a L-string.
The possiblity of easy but powerful programming w/ L-Systems
is one of the main feature of RTEvol. It combines the paralell rewriting
concept of L-System with procedural elements of the highlevel language
C.
Collision detection for turtle's movements is solved
by using the GX/GENERIC raytracing-kernel. There are several ways to controll
the reaction of the turtles at the collision position (die, reincarnation,
reflection, refraction etc.)
The programming-language is very similar to POV's decription
language, except the constructs for L-grammar's description and executeable
functions. In fact, POV2.0 sources can be read and reformated w/o any problems.
Programable output drivers. See the POV- and NFF-drivers
for examples.
Supports math.h's functions, Gaussian random numbers,
mixed float/vector/matrix oprerations.
3.ALGORITHM:
It is important to understand how RTEvol works, when you
wish to use it intensively. Here is an overview of the internal life of
RTEvol:
RTEvol works in 3(!) stages:
First, it reads the input-file, checking for syntax errors.
If no syntactical error was found, it tries to evaluate/simplify all expressions
in the description-file. All expression, which cant be evaluated at this
time (this is the case of expressions w/ variables) are saved for further
processing. Functions w/ constant arguments can be executed here .
At the second pass, the L-systems are executed, applying
the appropiated rules-sets(growth-rules) to generate the final L-strings.
After that process, all expression/functions/macros should have constant-arguments.
The last stage is interpreting the L-strings and executing
functions. The results are passed to the output-driver to generate the
final scenes.
All comments and bugs reports are welcome, but dont ask
me for the sources. Also, dont ask me about POV-stuff, because i only use
it to test the generic driver. I have not enought times to make some 'good-looking'
examples, but i'm sure there are some others who have skills(and times,
too) to do it with RTEvol.
5.DISCLAIMER
This software is provided as is without any guarantees
or warranty. Although the author has attempted to find and correct any
bugs in the package, he is not responsible for any damage or losses of
any kind caused by the use or misuse of the package. The author is under
no obligation to provide service, corrections, or upgrades to this package.
6.HISTORY
### 1.0Beta PatchLevel 2 ###
- RTEvol doesnt support macros anymore .
- Nested function calls are possible now, but RTEvol
will not support recursive function calls (Recursions w/ L-Systems are
much easier!)
- Remove all drawing commands (i.e. F, {.}) from L-System's
alphabet. Only turle's movements are controlled by L-Systems, not its drawing
interpretation. Drawing operations can be implemented in a more flexible
way: All turtle's states (Position, Head-,Left- and Up-vector) can be pushed
to a particular stack, which is accessed by drawing- functions. Therefore,
it is easy to implement 'advanced' drawing-operations, such as drawing
a B-spline w/ the control points given by the stack.
- Add a lot of useful math-routines, all written as RTEvol-functions
:
- transfrm.lib -> vector-operations, transformation
matrices etc. In fact, one can convert his C-utilities to RTEvol-format
w/o any problems. (All vector/matrix-utilities comming from GGems were
adapted in about 15 minutes.)
- bezier.lib -> simple implementation of Bezier-Curve's
generation. Frenet-frames can be created and corrected(To avoid the abrupt-twisting
at inflextion points). One can use L-systems to generate the controll points
and the routines in this lib for curves-drawings or sweeping. I find this
technique to be useful for the generation of curved tree-branches.
- No OUTput-drivers are needed: "What you 'print()'
is what you get" ! I have tried to write the results of the same RTEvol
file to several ascii-formats : NFF, POV, Rayshade, VRML, BlobSculptor
etc. It works.
- Improved docs
- Several bugs, i.e: the GNU-assembler mips.irix5.3's
bug, the Ctor-bug etc. are fixed.
### 1.0Beta PatchLevel 1 ###
- Add constructors for mutations after OOP-concepts:
mutation <-> class
ctor <-> class's CTor
production <-> class's method
axiom <-> class's member data
All variables defined in the Ctor of a mutation are automaticaly defined
as its *member-data*. These variables become transparent for all productions
inside the mutation.
- Mutations have now pararameters for CTors.
- Replace local-consts & global-consts throught local-variables
and global-variables. (It is possible to modify a #declared value. See
randsphs.rte)
- Hull-shapes can be spheres, box, cones, cylinders and
CSG-objects . (blobs will be supported in the final version )
- New command : sp <(%v)> -> Set the turtle's
position to the given point. This command is very useful for hull-controll
: Sometimes, you want to bound the growth-structures throught a solid by
setting the initial position of the turtle to any point inside this solid.
Without this command, you must write a lot of other commands in the axiom.
- A lot of bugs fixed.
- Add the GX/GENERIC NFF-ray
tracer to the package ( no special FX and textures, but *MUCH* faster than
POV. Visits GX's WWW-page for more infos. Can be used as RTEvol-preview)
