Visual Comput (2005) 21: 397–405 DOI 10.1007/s00371-005-0295-1

Daniel Wessl´en Stefan Seipel

Published online: 14 July 2005 © Springer-Verlag 2005

D. Wessl´en (u) · S. Seipel University of G¨avle, Sweden [email protected] S. Seipel Uppsala University, Sweden

ORIGINAL ARTICLE

Real-time visualization of animated trees

Abstract Realistic visualization of plants and trees has recently received increased interest in various fields of applications. Limited computational power and the extreme complexity of botanical structures have called for tradeoffs between interactivity and realism. In this paper we present methods for the creation and realtime visualization of animated trees. In contrast to other previous research, our work is geared toward near-field visualization of highly detailed areas of forestry scenes with animation. We describe methods for rendering and shading of trees by

1 Introduction Simulation of plants and trees has received increased attention during the last decade as processing speeds have reached levels where such complex objects can be managed within a reasonable amount of time. The performance of widely available consumer systems are now passing the threshold where botanical objects can be handled, making much higher fidelity images possible in end-user applications. Plants are incredibly complex objects in their own right, hence when combined to form even relatively small areas of forest or parkland the result is a scene that would ideally have to be rendered using billions of primitives [1]. Obviously, in order to achieve acceptable performance, representing a scene using that level of complexity is not a passable solution. When aiming toward real-time performance, a full detailed description of a forest scene is unfeasible, and consequently an efficient level of detail

utilizing the programmable hardware of consumer-grade graphics cards. We then describe a straightforward technique for animation of swaying stems and fluttering foliage that can be executed locally on a graphics processor. Our results show that highly detailed tree structures can be visualized at real-time frame rates and that animation of plant structures can be accomplished without sacrificing performance. Keywords Forest visualization · Point rendering · Vertex animation · Tree modeling

algorithm is indispensable. Still, the large number of vertices naturally brings a large number of calculations per frame, which are best offloaded to the graphics processor. This is especially true when animations are intended. Targeting an application for consumer hardware brings its own set of restrictions: The program will be run on a more diverse set of platforms than if limited to a research lab, and, while modern graphics processors have high processing rates, the system bus generally cannot keep up, making it important to store the geometry locally on the graphics card. This precludes animation by modification of the base model, which would require continuous uploads of new geometry. Instead, all animation has to occur in the graphics processor. 1.1 Previous research Tree generation algorithms may be divided into two main categories—those based on botanical principles and attempting to accurately simulate the growth of trees [2]

398

D. Wessl´en, S. Seipel

and those taking a geometrical approach [1, 3–9]. Since all methods ultimately aim to produce as realistic trees as possible, they all have to consider growth and environmental effects to some extent. This results in a gray area in the classification of algorithms that do not fully attempt to simulate the growth of a tree but are sophisticated enough that they cannot be considered geometric [10]. Growth algorithms potentially yield more realistic results, but since a greater understanding of botanical principles and the structure of trees is required, they do so at the cost of increased complexity both for the implementor and for the tree modeler. Geometrical algorithms are most common by far. Algorithms may also be classified as environmentally sensitive or freestanding. Most algorithms only consider freestanding trees, though recent papers have presented methods for constructing trees that are more accurately heliotropic [11, 12], cling to obstacles [11], and support complex pruning [13]. Research efforts in rendering of plants have mostly been focused on offline and 2D rendering [1, 3–5]. Although real-time 3D rendering is less common, very pleasing results have been presented by Weber and Penn [9]. Sophisticated real-time animation has been presented by Sakaguchi et al. [7], though this was only achieved for a single tree. The gaming industry has recently started using somewhat detailed trees, but these are still handmade low-detail models where branches or large clusters of leaves are represented with a few textured polygons. Weber and Penn describe a method for generating trees for use as background objects in real-time simulations in their paper “Creation and rendering of realistic trees” [9]. Apart from simple heliotropism the algorithm is strictly geometric. Their creation algorithm is recursive and largely self-similar, but not fractal. Trees are created randomly from a set of parameter values describing the typical geometrical structure and allowed variations from the average. Each recursive level uses a different set of parameters. Thirty parameters control the shape of the tree. Most of these are fairly generic, controlling length, width, curvature, etc. Special-purpose interpretations are often implemented for negative values, supporting the more esoteric shapes required for palm trees, cacti, and some “regular” trees. Very lifelike trees have been produced with the algorithm, which requires some amount of artistic control but in return is very flexible and relatively intuitive.

dle for the tree designers and application developers. The visually most obvious improvement is that leaves are modeled using textured and stenciled primitives, making far shorter observation distances feasible. Trees are built from two basic building blocks: stems and leaves. The trunk and the branches are considered stems, with the only difference that the trunk has no parent and grows from the ground. Creation of a tree starts with the trunk; then, any branches or leaves growing from the trunk are created, followed by the recursive creation of their children. Like the original algorithm, ours uses a set of parameters per level in the tree to determine the appearance and further growth of the tree. Unlike the original, we have no global parameters, and most special interpretations of negative values have been removed. We compensate for the loss of functionality from special interpretations by introducing a few new parameters and by allowing random variation in existing ones. A major, albeit simple, improvement is the addition of a health parameter, which makes it possible to create trees with missing branches and leaves for visualization of damages and poor living conditions. This is essential for modeling realistic pine trees.

2 Creation

3.1 Animation and vertex packing

Our tree creation algorithm started as an implementation of the one used in “Creation and rendering of realistic trees” [9], which was then adapted to better support nordic spruce and pine trees, less healthy trees, and to make the parameters and general structure of the trees easier to han-

Animation is used to bring life to the scene. While trees are mostly static, leaves will flutter in slow winds and stronger winds will cause branches to sway. Incorporating these effects into the simulation will add greatly to the realism of any scene.

3 Rendering During rendering, leaves are handled uniformly. Stems are classified into one of two groups, stems or needle stems. Needle stems are stems covered with needles growing directly from them, by far most commonly found on spruces. Points and lines are used for rendering when possible. At close ranges quads and triangle strips are used. Leaves are rendered as single textured quads as this is far less costly than more detailed geometry. The desired detail is stenciled from the quad using alpha testing, leaving only the restriction that all leaves must be flat. Ordinary stems representing the trunk and branches are rendered either as polygonal tubes or as lines, depending on the required level of detail. Both leaves and needle clusters are rendered as single textured, stenciled quads in full-detail mode, and as single points in low detail mode. Stems covered in needles are rendered as two long quads arranged orthogonally across in full-detail mode; these are textured and stenciled just like leaves. In low-detail mode, needle stems are rendered as untextured lines.

Real-time visualization of animated trees

Since the geometry is to be stored on the graphics card, all animation must occur there; this is also substantially faster than host-side animation in most cases. Complex animation requires information about the structure of the tree, meaning that such information would have to be available to the vertex shader. While certainly possible, this would currently require considerable duplicate data and repeated calculations. Additionally, animation complexity is limited by the maximum allowable vertex program length of the graphics card, which is quickly exceeded when performing sophisticated animation on previous-generation hardware. We use two simple methods of animation—swaying and fluttering. Swaying is a periodical rotational motion around the origin of the trunk, with the rotation amount relative to the distance to the base of the tree. Fluttering leaves are animated by a quick rotation around the spine of the leaf. All trees with fluttering leaves sway as well. Swaying is uniform over the tree, so branches do not move independently of each other. Figure 1 illustrates the animation methods. Animation is closely linked to vertex packing since the animation to be performed affects which parameters are required by the vertex program. Often, parts of the calculations required for animation can be performed offline and passed through vertex attributes instead of the original data. Sway animation performance is improved by storing positions in polar coordinates for animated vertices; the animation can then be expressed as a simple perturbation of the angle. Also, fluttering requires information about the vertex location relative to the leaf spine. The large number of leaves in a tree naturally brings high storage requirements, but video memory is a limited resource, so these requirements must be counteracted. Memory usage can most effectively be reduced in four ways—by reducing the number of tree models per scene, leaves per tree, vertices per leaf, and bytes per vertex. We only handle moderately sized forested areas, so the number of trees is not a major issue. Additionally, our models have fewer leaves than real trees, compensated by slightly larger size. Leaves are drawn using a single quad per leaf and thus only require four vertices; also, clusters of needle-shaped leaves are drawn as a single unit, and

399

needles growing directly from stems are represented in the stem’s texture. These are simple measures that have always been available, but programmable graphics processors have given us more options. It is now possible to define novel vertex formats that can be made more compact than the general-purpose formats used by the fixed function pipeline in traditional hardware. In addition to reducing the number of bytes per vertex, this gives us the tools required to further reduce the number of tree models— vertex shaders may be used to create more diverse instances from a single base model, thereby reducing the need for tree models. This is achieved by adding perinstance parameters controlling the appearance of trees, such as color, scale, animation parameters, and health. We have defined six classes of vertices requiring different sets of parameters—textured and untextured versions of static, swaying, and fluttering. All vertex modes store a leaf brightness parameter per vertex. All modes also share a set of parameters that are defined per tree; these include sway amount, animation time, color modulation, selection color, and tree position and scale. Not all of these are actually used by all shaders, but setting per-tree parameters implies no significant cost compared to the rendering of the tree. In addition to the common parameters, swaying modes store an animation time offset, the vertex position in the yz-plane in polar coordinates, and the cartesian x coordinate. The animated position is found by converting all coordinates to cartesian, factoring in sway amount scaled by polar distance, r, as an offset to the angle, θ: posvertex = (x, r cos α, r sin α)t ,

(1)

where α = θ + r · sway amount · sin(frequency · time).

(2)

The motion of trees swaying in the wind can be modeled by considering tree stems as an upside down pendulum [14], where the sway frequency can be calculated from the height of the tree: frequency = A · heightB ,

(3)

where A = 2.55 and B = −0.59 are metrically justified parameters based on the experimentally derived values by Coder [14]. Fluttering modes store the animation time offset, the leaf origin polar coordinate in the yz-plane, the leaf origin cartesian x coordinate, and the local axes of the leaf, premultiplied by the leaf-local vertex coordinates. Sway animation is handled per leaf, the same way as described above. The final vertex position is then found by adding the local vertex position to that of the leaf stem: Fig. 1. Animation illustration

posvertex = posleaf + localx cos β + local y sin β ,

(4)

400

D. Wessl´en, S. Seipel

where β = max flutter · sin(global offset + local offset).

Table 1. Vertex packing examples. Textured fluttering, untextured swaying, and parameters shared by all shaders

(5)

3.1.1 Vertex format caveats Per-vertex parameters are passed to vertex programs through vertex attributes defined by the implementor. Theoretically, just about any attribute configuration will work, but our goal is to identify compact configurations that at least work on the last few generations of graphics cards from the main manufacturers. A few caveats must be considered for a real-world implementation today. Vertex processors work with floating point numbers internally, so any attributes passed in other formats have to be converted first. Only a limited set of conversions are natively supported, so the others must be performed by the driver. Since we aim to keep vertex data stored in video memory, values that cannot be converted in hardware must be passed from video memory to system memory, converted, and passed back again. This situation is to be avoided at all costs. Not all data types are equally supported in the various attribute slots, making the design of a good vertex format somewhat of a jigsaw puzzle. In order to ensure some level of portability of vertex formats and to avoid performance problems on some cards, we only use the standard OpenGL vertex attributes, and only with data types commonly used for the respective attributes. By quantizing and storing separate parameters in different attribute components it is possible to reduce the storage requirements. Table 1 contains an example of two vertex formats and describes how the vertex attributes are used. The shared parameters listed in Table 1 could just as easily have been passed through uniform variables and by modifying the modelview matrix. Doing so can be quite costly on some graphics cards, and passing these parameters can then consume a significant amount of time for each frame when trees are rendered at low-detail levels. By passing them as texture coordinates instead, we increase the vertex processing load and decrease the overhead for each tree. This tradeoff has resulted in a performance increase in all interesting cases on GeForce cards. The problems and workarounds mentioned above are implementation dependent and may not be applicable if a single platform is targeted. 3.2 Level of detail Automatic level of detail selection is at the very heart of the rendering system. There is no way we could render all trees in full detail, and reducing detail globally will not produce desirable results.

Attribute Position float3 Color byte4

Parameter (textured flutter, per vertex) x yz r g ba

Texcoord 0, 1 float3 Attribute Position float4

Parameter (swaying, per vertex) x yz w

Attribute Texcoord 2 float4 Texcoord 3 float4 Texcoord 4 float4

Cartesian x coordinate of leaf polar y, z coordinates of leaf Brightness Local offset for fluttering Texture coordinates Local x-, y-axis · distance from leaf origin

Cartesian x coordinate of vertex Polar y, z coordinates of vertex Brightness Parameter (shared, per tree)

xyz w xyz w xyz w

Selection highlight color Sway amount · sin (frequency · time) Tree color modulation Global offset for fluttering Tree position Tree scale

A fortunate consequence of the complexity of foliage is that individual leaves can rarely be seen clearly, mostly due to their small individual sizes. This makes point-based rendering a viable alternative. Before rendering, the width of a stem or leaf projected onto the screen is calculated. If it is smaller than a user-defined limit, a point or line is rendered instead. As the plant moves further away from the observer, the average projected size will drop below one pixel. When this happens, primitives will simply be omitted from rendering in order to maintain a constant coverage. The original algorithm by Weber et al. [9] contains a complex method for determining when and how the different rendering methods are to be used in an attempt to ensure that the most prominent features of the tree are kept as long as possible and that level of detail switches occur uniformly across the tree. While this method works, it is complex and assumes that trees have a certain fixed structure which we do not enforce. Also, it requires a traversal of the entire tree since primitives are selected for rendering from all parts of the tree. We aim to offload as much as possible onto the graphics processor and therefore want to keep the number of render commands to a minimum. One very effective way to do this is to arrange the stems and leaves in advance. Two vertex buffers containing all required geometry for the full detail and reduced detail modes are prepared for each tree component, i.e., trunk, branches, and leaves. The buffers are arranged in random order, with geometry representing each branch and leaf put in the same order in both buffers so that detail transitions will not change which parts of the tree are rendered.

Real-time visualization of animated trees

3.3 Materials and lighting

Table 2. Tree and geometry creation time

Primitives are textured using simple photographs from actual trees and lit using precomputed lighting information stored in the vertex buffers. Only diffuse lighting is considered. Lighting is calculated during preprocessing, using a directional light and plenty of ambient illumination. Self-shadowing is approximated by reducing the intensity of vertices near the center of the tree, offset somewhat along the direction of incoming light. For fluttering leaves, the precomputed lighting information is modulated by a scalar based on the current stage in the animation. Swaying is usually subtle and does not influence diffuse lighting enough to justify similar treatment. Additionally, we simulate the reduction of light reaching trees in densely populated areas by a cheap trick. We draw a transparent, barely visible black polygon across the bounds of each tree. For isolated trees the polygon will be too faint to be visible, but when trees are grouped together the combined effect will darken the area around the trees subtly. Figure 5 shows the scene rendered with light attenuation (Fig. 5b) as compared to the the nonattenuated lighting conditions (Fig. 5a). The difference is hardly perceivable in the printed media. Figure 5c shows the subtraction image, which emphasizes the attenuation effect. Since the large number of primitives keeps the vertex processor occupied most of the time, albeit typically resulting in little being rendered, the fragment processor is kept idle in the meantime. The shade approximation requires very little vertex processing and lots of rasterization, making it essentially free when combined with the tree rendering. One problem with this approach is that when looking at a group of trees horizontally, the background and any objects behind the trees will be darkened as well. Nevertheless, the shade adds to the perceived realism of the scene at virtually no cost.

Species

Tree

Geometry

Quads

Pine Spruce Birch Young birch Young pine Young spruce Bird cherry

170 ms 250 ms 120 ms 4 ms 10 ms 10 ms 6 ms

4 ms 10 ms 5 ms 2 ms 3 ms 4 ms 2 ms

52 000 33 000 33 000 4700 5400 4200 3000

4 Results

401

frames per second (31 ms per frame) on a dual Intel Xeon 1.5 GHz computer with an ATI Radeon 9800 XT graphics card. Animation. The cost of animation depends largely on the scene used—the most complex vertex program is used for fluttering leaves at close range, while simpler programs are used for coniferous trees and at lower-detail levels. Figure 2 plots the number of rendered frames per second as it depends on the total number of rendered trees in a set of scenes where young birches are added further away from the camera in each scene. The lower (diamond) values are from a Xeon 2.8 GHz computer with a Radeon 9800 Pro graphics card, while the higher (cross) values are from a Xeon 1.5 GHz computer

Fig. 2. Rendered frames per second with animation enabled and disabled on two different computers

Screenshots illustrating typical tree models and scenes are provided in Figs. 4, 6, and 8. Figure 9 lists the datafile used for all young birches seen in this paper. Creation. Table 2 lists the average time taken to create a tree and to generate geometry from that tree for each species. Parameters are taken from the scene used in Fig. 6, except for grown pine trees, which are not used in that scene. Rendering. Figure 6 depicts a small forest containing 139 trees instanced from 49 base models of 6 species. For this picture 98 000 points, 21 000 lines, and 271 000 quads were rendered to a 1600 × 1200 framebuffer at 32

Fig. 3. Ratio between frame rate with animation enabled and with animation disabled on two different computers

402

D. Wessl´en, S. Seipel

Fig. 4. Pine, spruce, birch. Young pine, spruce, birch, bird cherry

Fig. 6. Small forest containing 139 trees, instanced from 49 base models of 6 species

Fig. 5. a Forest scene without attenuation. b With attenuation. c Contrast-enhanced difference

Fig. 7. Animation benchmarking scene: 1210 young birches

with a GeForce 6800 GT graphics card, both rendering to a 1280 × 1024 framebuffer. Strong lines connect measurements with animation enabled and weak lines are used for disabled animation. A screenshot from the last scene in the series is available in Fig. 7. It contains 1210 trees. Figure 3 shows the relative cost of animation, expressed as the ratio between frame rate with animation enabled and without animation for the two different computer configurations, in the same set of scenes. The GeForce 6800 has a native sincos instruction, making our animation very efficient. Coupled with higher driver overhead and a slower computer, we can see that the difference in performance between animated and static trees is negligible. The Radeon 9800 does not have native sincos, has very low driver overhead, and is in this case used in a faster computer. The result is that rendering is entirely vertex processing limited. We can see that in the worst case, the

cost of animation is a reduction in frame rate by 51%. We can also see that the cost of adding more trees is greatly reduced as the distance increases. With animation enabled 1210 trees are rendered at 24 fps; doubling the number of trees to 2420 only lowers the frame rate to 21 fps. Again, trees are added further back in each scene. More varied scenes usually use the more complex shaders for a smaller portion of the primitives, decreasing the effective cost of animation. Figure 6 with animation disabled renders at 35 fps on a Xeon 1.5 GHz, Radeon 9800 XT, 1600 × 1200 compared to 32 with animation enabled, indicating a 9% drop in frame rate due to animation. As a rough comparison to CPU-based animation we have measured the performance when transferring the geometry each frame and performing a four-component matrix-vector multiplication per vertex on the CPU. Figure 6 then renders at 3.1 fps. Actual animation would require more calculations and thus be even more costly.

Real-time visualization of animated trees

Fig. 8. A pine tree viewed from different distances. The top and bottom rows contain the same images, zoomed to comparable size in the top row and at original size in the bottom row. 1. 538 points, 23 lines, 27 quads 2. 3 785 points, 50 lines, 27 quads 3. 6 551 points, 130 lines, 27 quads 4. 32 527 points, 190 lines, 37 quads 5. 0 points, 152 lines, 35 609 quads

5 Discussion We have presented efficient tree animation and data packaging methods that are targeted at state-of-the-art consumer-level graphics hardware. The results from the previous section show that near-field rendering of forestry scenes is possible at real-time frame rates. Although the animation models presented here are relatively simple, they achieve our goal of high visual fidelity and contribute to an improved overall sensation of a realistic forestry scene. When comparing the relative cost for animation (Fig. 3) we can see that the most recent generation graphics hardware (GeForce 6800) does not introduce significant additional costs for rendering. In visualization of

Fig. 9. Young birch datafile

403

404

D. Wessl´en, S. Seipel

forestry scenes there is a natural limit to the number of trees visible at high detail in the near field. The scene shown in Fig. 7 contains 1210 trees of which only approximately 150 trees are visible at full detail. Regardless of the viewpoint in the scene, trees in the far background are rendered with reduced level of detail, which obviously counteracts constant increases in rendering times. Figure 2 shows that forest scenes with approximately 1000 individual trees are still rendered at more than 50 fps for the current graphics cards. All future performance improvements in graphics hardware will provide room for additional detail refinement of animations based on our conceptual approach. Vertex packing helps to reduce the memory requirements for static tree models by about 25%, something that is sorely needed as video memory is still limited in consumer systems. While onboard memory sizes are rapidly increasing, supersampling, deferred shading, and other techniques demand their share, so any reduction is welcome. Stenciling geometric detail from simple primitives using alpha testing neccessarily introduces aliasing that would not have appeared had blending been used instead. Unfortunately, blending, which could solve the problem, requires the geometry to be sorted by depth, which is far too costly. The artifacts introduced by stenciling are similar to those that would be introduced by actual high-resolution geometry. Compared to explicit geometry, stenciling decreases driver overhead and vertex processing load in exchange for simple fragment processing. Fragment processing performance generally exceeds vertex processing performance and has the added advantage that only visible fragments need to be considered. Another advantage is that arbitrarily complex shapes can be stenciled from quads, while modeling a needle cluster would

require far too many vertices to be usable in practice. The lighting used is very simple. While real-time lighting would certainly add to the visual fidelity, we consider the current appearance to be satisfactory. Shadows would probably be the most desirable improvement, but real-time shadows would be too costly and static shadows would not work well with animation and instancing. Local shadows are currently approximated statically, and the described method of attenuation is a simple and practically free way to incorporate global illumination at a very coarse level for scenes lit by skylight.

6 Conclusion In this paper we have presented a system for real-time visualization of animated trees. The system achieves the goal of being able to render moderately sized areas of forest with high visual fidelity on consumer-grade hardware. Most of the work is handed off to the graphics card, leaving the CPU free for other tasks as required by applications not solely focused on the task of visualizing plants. We have shown that with recent advances in programmability, even low-cost hardware can be used to visualize a highly detailed forest area with animation at realtime frame rates. Download The program described in this article can be downloaded from viskom.se/forest-en.html. Acknowledgement This project was partly sponsored by the County Administrative Board of G¨avleborg and by the EU Structural Funds, Objective 2.

References 1. Deussen O, Hanrahan P, Lintermann B, Mˇech R, Pharr M, Prusinkiewicz P (1998) Realistic modeling and rendering of plant ecosystems. In: SIGGRAPH ’98: Proceedings of the 25th annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 275–286 2. de Reffye P, Edelin C, Françon J, Jaeger M, Puech C (1988) Plant models faithful to botanical structure and development. In: SIGGRAPH ’88: Proceedings of the 15th annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 151–158 3. Aitken M, Preston M (2003) Grove: a production-optimised foliage generator for “The Lord of the Rings: The Two Towers”. In: Proceedings of the 1st international conference on computer graphics and

interactive techniques in Australasia and South East Asia. ACM Press, New York, pp 37–38 4. Bloomenthal J (1985) Modeling the mighty maple. In: SIGGRAPH ’85: Proceedings of the 12th annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 305–311 5. Marshall D, Fussell D, Campbell III AT (1997) Multiresolution rendering of complex botanical scenes. In: Davis WA, Mantei M, Klassen RV (eds) Graphics Interface ’97, Canadian Human-Computer Communications Society, pp 97–104 6. Oppenheimer PE (1986) Real time design and animation of fractal plants and trees. In: SIGGRAPH ’86: Proceedings of the 13th annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 55–64

7. Sakaguchi T, Ohya J (1999) Modeling and animation of botanical trees for interactive virtual environments. In: Proceedings of the ACM symposium on virtual reality software and technology. ACM Press, New York, pp 139–146 8. Smith AR (1984) Plants, fractals, and formal languages. In: SIGGRAPH ’84: Proceedings of the 11th annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 1–10 9. Weber J, Penn J (1995) Creation and rendering of realistic trees. In: SIGGRAPH ’95: Proceedings of the 22nd annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 119–128 10. Prusinkiewicz P, Lindenmayer A, Hanan J (1988) Development models of herbaceous plants for computer imagery purposes. In:

Real-time visualization of animated trees

SIGGRAPH ’88: Proceedings of the 15th annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 141–150 11. Arvo J, Kirk D (1988) Modeling plants with environment-sensitive automata. In: Proceedings of Ausgraph’88, pp 27–33

12. Mˇech R, Prusinkiewicz P (1996) Visual models of plants interacting with their environment. In: SIGGRAPH ’96: Proceedings of the 23rd annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 397–410 13. Prusinkiewicz P, James M, Mˇech R (1994) Synthetic topiary. In: SIGGRAPH ’94:

´ received his B.Sc. in comDANIEL W ESSL EN puter science from the University of Gävle in 2002. Since 2003 he has been working as a research engineer at the University of Gävle, focusing on computer graphics and visualization. Wessl´en’s research interests include computer linguistics and abuse of programmable graphics hardware.

S TEFAN S EIPEL received his M.Sc. in medical informatics from Heidelberg University in 1992. In 1997 he received his Ph.D. from Heidelberg University for his thesis on visual simulations of surgical procedures. From 1998 to 2001 he was a postdoctoral fellow at the University of Uppsala, where his research focused on applied computer graphics in medicine and in e-learning. In 2002 he became an associate professor of computer graphics and visualization at Uppsala University, and in 2003 he was appointed as chaired professor of computer graphics at Uppsala University and University of Gävle. Seipel’s research interests include interactive graphical applications for decision support and real-time rendering of natural phenomena. Seipel is a board member and vice chair of the Swedish Computer Graphics Association.

405

Proceedings of the 21st annual conference on computer graphics and interactive techniques. ACM Press, New York, pp 351–358 14. Coder KD (2000) Sway frequency in tree stems. In: University Outreach Publication FOR00-24, University of Georgia, Warnell School of Forest Resources, Athens, GA