Creating the Scene


Chapter 28. Trees That Grow

The last two chapters have been about creating landscapes: the fractal terrain in Chapter 26 was empty, but the Terragen-generated landscape in Chapter 27 was decorated with 3D models and ground cover (2D images that always face the user). This mix of models and images is enough in most situations but still lacking in one area: the scenery doesn't change. For example, the trees don't sway in the wind, and the sagebrush doesn't tumble.

As the title of this chapter suggests, this chapter focuses on making trees grow. Each tree starts from a tiny sampling, then young green shoots turn brown, grow, branch, and sprout leaves. However, the underlying aim is to describe a rule-based approach to animation, which can be applied to many kinds of 3D shapes. This approach has the following characteristics:


Use of if-then rules

Each rule is a Java if-then statement. If all the conditions of a rule evaluate to TRue, then the rule's actions are carried out.

I'm not using a rule-based language such as Prolog, or a Java rules engine such as JESS. There's no need to step beyond standard Java.



Time-based sequential evaluation

The rules are evaluated at regular intervals during the program's execution. They're executed in a fixed, sequential order, defined by their textual order in the applyRules( ) method in the GrowthBehavior class.


Each rule is applied to every tree limb

When it's time for a rule to be evaluated, it's applied to every tree limb (tree branch) in the scene. For example, for two treesone with five branches and the other with nineeach rule is executed 14 times (5 + 9), once for each limb.

I can express this idea in more general terms: in each time interval, a rule is applied to every animation component in the scene. The choice of animation component depends on the application domain; in this case, the components are the branches of the trees.


An animation component is an object

In this example, each tree limb is an instance of the treeLimb class. This approach hiding a tree limb's implementation and most of the rules processing behind the class' methods.


Linked animation components form a hierarchy

Animation components are coupled together to form a hierarchy, where each component has a single parent (except the root component) and zero or more children. This allows rules to talk about parents and children, which adds to their expressiveness. Many 3D models are made from smaller parts, structured into a hierarchy, including trees, humanoids (e.g., the articulated figure in Chapter 20), and buildings (a building is composed of floors and walls).


Rules carry out incremental change

The rules change an animation component. For example, a tree limb will get longer and change color over a period of seconds. It is possible to add and delete animation components (e.g., new branches can start sprouting), but this is less common than changing an existing component.


A rule can behave randomly

A rule must behave randomly to introduce variation into the animation. For instance, the same rule may make one branch shoot up but delay another branch's growth. Randomness is easily achieved with Math.random( ).


The animation is efficiently implemented

Animation efficiency is important since the rules may have to deal with thousands of animation components, each of which is updated 10 or more times a second.

The incremental nature of the rules means that the 3D structures don't need to be generated from scratch in every time interval, which would be time-consuming. Instead, existing structures are modified.

Another optimization is that the geometry of an animation component (e.g., the cylinder representing the tree limb) is unchanged. Instead, changes such as translations, rotations, and scaling are done to transformGroup nodes connected to the shape. Similarly, changes to the component's appearance are applied to its Appearance node. Since the component's geometry is unaffected, you won't need to employ the complex GeometryUpdater interface used in the particle systems in Chapter 21.

An approach not used here are rules in the style of a Lindenmayer system (L-system), which suffer from the complexity and inefficiency I've tried to avoid throughout the book. I'll briefly compare my rule mechanism with L-systems in the section "Comparison with L-Systems."


Figure 28-1 shows a sequence of screenshots of the trees3D application. Five trees grow from saplings, green shoots turn brown, and leaves sprout, all taking place over a period of a few seconds.

Figure 28-1. Growing trees


Each time trees3D is executed, the trees will look different, due to random elements in the rules.



Killer Game Programming in Java
Killer Game Programming in Java
ISBN: 0596007302
EAN: 2147483647
Year: 2006
Pages: 340

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net