You are on page 1of 78

A Complete Wood Grain Modeling Application

Incorporating Multiple Cut Types, Species, and a Tree Ring Database




A Thesis
Presented to the Faculty of
California Polytechnic State University,
San Luis Obispo


In Partial Fulfillment
of the Requirements for the Degree
Master of Science in Computer Science


By
Ryan Dean Retting
March 2004
ii
AUTHORIZATION FOR REPRODUCTION

I grant permission for the reproduction of this thesis in its entirety or any of its parts,
without further authorization from me.

_______________________________
Ryan Dean Retting


_______________________________
Date
iii
APPROVAL PAGE

TITLE: A Complete Wood Grain Modeling Application Incorporating Multiple Cut
Types, Species, and a Tree Ring Database
AUTHOR: Ryan Dean Retting
DATE SUBMITTED: March 2004


_______________________________ _______________________________
Dr. Chris Buckalew - Advisor Signature

_______________________________ _______________________________
Dr. Hugh Smith - Committee Member Signature

_______________________________ _______________________________
Dr. Chuck Dana - Committee Member Signature
iv
ABSTRACT

A Complete Wood Grain Modeling Application
Incorporating Multiple Cut Types, Species, and a Tree Ring Database

Ryan Dean Retting

Simulating nature has challenged computer scientists in all fields, especially computer
graphics. Wood grain is very difficult to realistically simulate. A proof of concept
implementation of wood grain modeling using implicit surfaces has demonstrated
promising results. This thesis presents a GUI application using the implicit surfaces
technique. It adds species factors, different types of saw cuts, and an integration of a real
tree ring database.

KEYWORDS: computer graphics, wood grain modeling, implicit surfaces
v
TABLE OF CONTENTS
LIST OF FIGURES .................................................................................................................................... VI
1. PROBLEM DESCRIPTION AND MOTIVATION .............................................................................. 1
2. PREVIOUS WORK / CURRENT METHODS ..................................................................................... 6
ARTIFICIALLY GENERATED TEXTURE MAPS .............................................................................................. 6
SCANNED IMAGES ...................................................................................................................................... 7
SIMULATION MODELS ................................................................................................................................ 8
3. OVERVIEW OF SOLUTION ............................................................................................................... 15
GUI APPLICATION .................................................................................................................................... 16
SPECIES SELECTION .................................................................................................................................. 19
CUT TYPE ................................................................................................................................................. 22
TREE RING SOURCE .................................................................................................................................. 25
CUT SELECTION ........................................................................................................................................ 28
OPTIONAL SETTINGS ................................................................................................................................ 30
WOOD GRAIN GENERATION ..................................................................................................................... 32
4. IMPLEMENTATION DETAILS.......................................................................................................... 34
PORTING FROM J AVA TO C#..................................................................................................................... 35
MAINTAINING A CONSISTENT RADIUS ...................................................................................................... 39
PYLES BRANCHING PROBLEM ................................................................................................................. 41
MANUAL RENDERING ............................................................................................................................... 44
MAIN FORM .............................................................................................................................................. 46
BRANCHING AND THE 3D TREE MODEL VIEWER ...................................................................................... 51
3D BOARD VIEWER .................................................................................................................................. 54
5. RESULTS ................................................................................................................................................ 56
SPECIES .................................................................................................................................................... 56
CUT TYPE ................................................................................................................................................. 58
TREE RING DATABASE ............................................................................................................................. 61
6. FUTURE WORK.................................................................................................................................... 64
7. REFERENCES ....................................................................................................................................... 69
8. APPENDIX A: DEVELOPMENT PLATFORM ................................................................................ 70
9. APPENDIX B: SOURCE CODE .......................................................................................................... 71

vi
LIST OF FIGURES

FIGURE 1: QUARTER SLICING .......................................................................................................................... 3
FIGURE 2: PLAIN SLICING ................................................................................................................................ 3
FIGURE 3: LENGTHWISE SLICING..................................................................................................................... 4
FIGURE 4: ROTARY .......................................................................................................................................... 4
FIGURE 5: AN EXAMPLE OF AN ARTIFICIALLY GENERATED TEXTURE MAP[6] ............................................... 7
FIGURE 6: AN EXAMPLE OF A SCANNED IMAGE[6] .......................................................................................... 8
FIGURE 7: SENKERESTY'S WORK[4] ................................................................................................................ 9
FIGURE 8: MATSUI'S WORK[5] ...................................................................................................................... 10
FIGURE 9: MATSUI'S KNOT ATTEMPTS[5] ..................................................................................................... 11
FIGURE 10: PYLE'S WORK USING IMPLICIT SURFACES[6] ............................................................................... 12
FIGURE 11: PYLE'S USE OF PERLIN NOISE[6] ................................................................................................. 13
FIGURE 12: PYLE'S DATA REPRESENTATION, USED AS A BASIS FOR THIS THESIS[6] ....................................... 14
FIGURE 13: PYLE'S CONFIGURATION FILE[6] ................................................................................................. 16
FIGURE 14: MAIN WINDOW OF GUI APPLICATION ........................................................................................ 17
FIGURE 15: SPECIES SELECTOR ..................................................................................................................... 19
FIGURE 16: COMPARISON OF BRANCH PARAMETERS FOR PINE AND OAK ...................................................... 20
FIGURE 17: WOOD CUT SELECTOR ................................................................................................................ 22
FIGURE 18: QUARTER CUT WITH THREE 2X4'S .............................................................................................. 23
FIGURE 19: PLAIN CUT WITH THREE 2X4'S .................................................................................................... 23
FIGURE 20: LENGTHWISE CUT WITH THREE 2X4'S ......................................................................................... 23
FIGURE 21: ROTARY CUT .............................................................................................................................. 23
FIGURE 22: ARCHIMEDES SPIRAL[10] ........................................................................................................... 24
FIGURE 23: EQUIANGULAR SPIRAL[10] ......................................................................................................... 24
FIGURE 24: EDIT TREE INFORMATION FORM FOR CONSTANT RING WIDTHS .................................................... 25
FIGURE 25: DATABASE SELECTION FORM ..................................................................................................... 26
FIGURE 26: CUT SELECTION AREA OF THE MAIN WINDOW WITH THE QUARTER CUT TYPE ............................ 28
FIGURE 27: CUT SELECTION AREA OF THE MAIN WINDOW WITH THE LENGTHWISE CUT TYPE ...................... 29
FIGURE 28: ADD A CUT FORM ....................................................................................................................... 29
FIGURE 29: ADD A CUT FORM FOR ROTARY CUTS ......................................................................................... 29
FIGURE 30: RENDER OPTIONS FORM ............................................................................................................. 31
FIGURE 31: THE TEXTURE MAP GENERATION FORM WITH PROGRESS BARS .................................................... 32
FIGURE 32: THE CUT, BOARD, AND FACE DATA STRUCTURE AND HIERARCHY .............................................. 37
FIGURE 33: PYLE'S BRANCH GROWTH ASSUMPTION....................................................................................... 41
FIGURE 34: ILLUSTRATIONS FROM THE BIOLOGY OF PLANTS[13] ................................................................. 42
FIGURE 35: A RENDERED LIVE BRANCH ......................................................................................................... 43
FIGURE 36: A RENDERED DEAD BRANCH ....................................................................................................... 43
FIGURE 37: MANUAL RENDERING FORM ....................................................................................................... 44
FIGURE 38: PHASE EDITOR IN THE MANUAL RENDERING FORM ................................................................... 44
FIGURE 39: PLAIN AND LENGTHWISE CUT FACE ORIENTATIONS .................................................................. 47
FIGURE 40: QUARTER CUT FACE ORIENTATIONS .......................................................................................... 47
FIGURE 41: 3D TREE MODEL VIEWER ........................................................................................................... 52
FIGURE 42: 3D BOARD VIEWER .................................................................................................................... 55
FIGURE 43: WESTERN YELLOW PINE SPECIES ............................................................................................... 57
FIGURE 44: NORTHERN RED OAK SPECIES .................................................................................................... 57
FIGURE 45: SUGAR MAPLE SPECIES .............................................................................................................. 57
FIGURE 46: BLACK WALNUT SPECIES ........................................................................................................... 57
FIGURE 47: BLACK CHERRY SPECIES ............................................................................................................ 57
FIGURE 48: ZEBRAWOOD SPECIES ................................................................................................................. 57
FIGURE 49: PLAIN CUT BOARD ...................................................................................................................... 58
FIGURE 50: QUARTER CUT BOARD ............................................................................................................... 58
FIGURE 51: TWO LENGTHWISE CUT BOARDS SHARING THE SAME BRANCH KNOT ......................................... 59
vii
FIGURE 52: ROTARY CUT .............................................................................................................................. 60
FIGURE 53: THE TOP FACE OF A LENGTH WISE 2X4X1 CUT ........................................................................ 61
FIGURE 54: THE ANNUAL RING WIDTH FOR 100 YEARS OF THE SAME PINE TREE USED IN FIGURE 53 ............ 62
FIGURE 55: A CROSS-SECTION ILLUSTRATING A FOUR YEAR DROUGHT ......................................................... 63
FIGURE 56: RIFT CUT .................................................................................................................................... 64
FIGURE 57: HALF-ROUND CUT ...................................................................................................................... 64
FIGURE 58: EXPERIMENTATION WITH A PARABOLIC GRADIENT COLOR SYSTEM ............................................ 66

1
1. Problem Description and Motivation
Simulating nature has challenged computer scientists in all fields, especially computer
graphics. Most of the research on simulating trees and plants has focused on the exterior
structure and appearance. There has been very little research focused on simulating the
internal structure of trees and plants. This thesis improves on previous techniques to
simulate the internal structure of trees in order to produce realistic and accurate wood
grain texture maps.

Wood grain is very difficult to simulate. Due to many factors that contribute to wood
grain patterns, it is challenging to create a three-dimensional model in order to generate a
natural and realistic pattern. Previous work in wood grain modeling has produced
promising results for simple cases. Can an easy to use Graphical User Interface (GUI)
application be created to extend previous console-based work on wood grain modeling,
while using implicit surfaces and incorporating the support of multiple species, different
milling techniques, and a real-world tree ring database?

There are four goals of this thesis. The first is to allow the model to support multiple
species. Second, renderer should be able to support different milling techniques. The
third is to incorporate the use of an optional real tree ring width database. Finally, the
GUI application allows users to easily create these wood grain texture maps.

This thesis addresses some new factors to all previous work. The species of the tree
plays an integral role in the internal wood grain structure. For example, a Pine trees
2
trunk is fairly straight and symmetric. It has a light wood grain color. Its branches are
typically horizontal and small in relative diameter compared to the trunk. When
compared to a Pine tree, an Oak trees branches are much larger and typically grow at
approximately 45 degrees from vertical. Oak trees have fewer branches. Their trunks
and branches are not straight. The color of the wood grain is much darker. In the GUI
application, you can choose the species of the tree and all of these factors will be
incorporated into the tree-dimensional model automatically.

Most of the previous work allows the user to request a single cut in the three-dimensional
model by defining a plane and size of the desired cut. The end result is a two-
dimensional texture map. This thesis improves on this by allowing the user to request
multiple boards from the same tree. For example, the user might request eight 2x4s and
four 4x4s, which would all come from the same tree. Since each board has six faces, 72
two-dimensional cuts would be automatically created in the three-dimensional model.
All of these cuts would be from the same exact tree and each board is guaranteed to be
unique since all of boards are automatically bin-packed before the faces are calculated.
In cabinetry, it is very common for furniture to be constructed from the same tree and
even adjacent boards. For example, on a dresser, the same cut or adjacent cuts might be
used so that the wood grains line up on the drawers.

The type of cut has yet to be addressed with any previous work. This thesis provides four
types of sawmill cuts which each produce different grain patterns. Figures 1 through 4
3
are screenshots from the GUI application. Each figure demonstrates a different cut and
shows a preview of the grain patterns produced by that cut.[1]


Figure 1: Quarter Slicing


Figure 2: Plain Slicing


4

Figure 3: Lengthwise Slicing


Figure 4: Rotary

Finally, this thesis allows the user to select a real tree ring database to be use for the
modeling of the tree. The World Data Center for Paleoclimatology and NOAA
Paleoclimatology Program maintain the International Tree-Ring Data Bank[2]. This
database contains tree ring records for trees and forests around the world. For example, a
5
user could obtain the annual tree ring widths from a Ponderosa Pine (pinus ponderosa) in
the Grand Canyon from the year 1800-present. The GUI application will import this
information use the actual tree ring widths in the three dimensional model.

Realistic wood grain modeling can be used in more than just cabinetry. There are many
architecture, design, and construction applications where wood grain is poorly
represented. Additionally, computer graphics and animation find it challenging to
accurately present wood grain. For example, an animated movie might have a wooden
desk. The wood grain is either scanned from actual wood or artificially created. Either
way, the wood grain texture must be tiled or wrapped around the object, producing less
than realistic results. It is very hard to produce life-like results when tiling wood grains
because they must line up correctly and not look artificially repetitive or tessellated. This
thesiss three-dimensional model allows the user to create texture maps for any
dimension at any resolution in order to correctly map on to objects.
6
2. Previous Work / Current Methods
Several methods are used to produce wood grain. Artificially generated wood grains can
be created in graphics programs, such as Adobe Photoshop[3]. This is a fairly simplistic
approach since the wood grain does not appear to be accurate or realistic. Real wood
grain can also be scanned as photographs and used as texture maps. Finally, wood grain
can be simulated using models.

Artificially Generated Texture Maps
Adobe Photoshop and other graphics programs provide filters and other methods to
artificially create wood grain images. These programs rarely create realistic patterns.
They do not incorporate any factors such as a trees growth pattern or knots from
branches. If carefully created, they can be successfully tiled. This requires the pattern of
grain on the top and bottom, along with the left and right side, to line up. If they do not
line up exactly, or if a unique pattern is found by the eye, the end result will appear
tessellated.
7

Figure 5: An Example of an Artificially Generated Texture Map[6]

Scanned Images
Real wood grain can be scanned and used in similar application but this method is prone
to the same tessellation problem. It is also challenging to scan a piece of wood large
enough to cover the entire object. Scanned images do allow for the inclusion of knots
and will look very realistic for that small part of the object.
8

Figure 6: An Example of a Scanned Image[6]

Simulation Models
This thesis focuses on the simulation technique. The simulation technique uses
algorithms that incorporate many factors to build a three-dimensional representation of
the tree. Once the model is created, any cut can be made to produce the texture map.
Along with a more accurate representation of the wood grain, multiple cuts can be made
on the same tree. Although this technique appears to be the most flexible and useful,
there are many drawbacks.

This technique is the most complicated. It requires algorithms that incorporate many
factors in order to accurately simulate nature. Additionally, this method may be very
CPU and memory intensive, especially when creating many high-resolution images. This
can result in additional cost.
9

There are three previous theses that attempted to create wood grain through simulation
models. Scott Senkeresty[4] created the first model in 1995. The results of his work
were comparable to artificially generated texture maps through Photoshop-like programs.
More importantly, it proved that the simulation model technique could be used as viable
method for generating realistic wood grain.


Figure 7: Senkeresty's Work[4]

Michael Matsui[5] continued Senkerestys work. He defined five control parameters that
affected the three-dimensional model of the tree. These factors were eccentricity, height
variability, ring circularity, ring-to-ring variability, and ring variability. He was able to
adjust these parameters in order to produce different grain patterns. He also researched
non-linear coloring methods. Finally, he was the first to introduce branches and knots.
Unfortunately, the knots did not appear to be realistic at most angles.

10

Figure 8: Matsui's Work[5]


Finally, Robert Pyle[6] attempted create the three-dimensional model using implicit
surfaces. This was a radically different approach compared to previous theses. Implicit
surfaces are a mathematical method for blending multiple three-dimensional objects.
Pyle used this method to realistically connect and provide a smooth transition between a
trunk and its branches.

11

Figure 9: Matsui's Knot Attempts[5]

Pyle defined many cylinders, each slightly larger in diameter, to model a tree. First, each
tree ring could be represented as a cylinder (or technically a capsule defined by a constant
radius around a line segment). Additionally, a tree ring is made up of a gradient of
colors. Each shade or phase of the tree ring would be an additional cylinder. So, for a
trunk with 50 rings and 10 shades per ring, the trunk would be represented by 500
cylinders. The branches are modeled is the same fashion with narrower ring widths or
12
less cylinders. When the trunk and branch merge, the implicit surfaces functions
mathematically blend the two objects together to produce a realistic result. It is important
to note that every cylinder is involved in the calculation of every point. There are a few
variables in the mathematical formula, such as thumbweight, which adjusts for degree of
blending.


Thumbweight =1.0

Thumbweight =2.0

Thumbweight =3.0
Figure 10: Pyle's work using Implicit Surfaces[6]

Pyles work was a proof-of concept demonstration which proved that implicit surfaces
can be used to produce realistic results. It was the first to successfully incorporate knots
and branches. He also acknowledged that trees are not always symmetric and perfect.
He introduced a controlled random factor, Perlin Noise, which allows for the trunk and
braches to be distorted. For example, Pine trunks are typically straight and circular,
where Oak trunks are crooked and non-symmetrical. These Perlin Noise factors are used
in the species definition.

13

No Noise

Perlin Noise Used
Figure 11: Pyle's use of Perlin Noise[6]

Finally, Pyle introduced a two level hierarchy for data storage which was ported and used
in this thesis. The TreeLine structure contains the three dimensional vectors for defining
the line (through the center of the cylinder), along with ring width and dimension
information. The TreeData structure contains all of the TreeLines (trunk and branches),
along with tree specific information relative to constructing the three-dimensional model.
14


TreeData

Contains:
Multiple TreeLines
Noise Information
Settings for Tree
Functionality:
Color at a Point
Add TreeLine
Accessor Methods


TreeLine

Contains:
Line Endpoints
Weight
First Ring of Growth
Functionality:
Distance to a Point
Point Closest to Another Point
Accessor Methods
Figure 12: Pyle's data representation, used as a basis for this thesis[6]

Michelle Courier[7] was a fourth person to work on wood grain modeling. She was the
first to give an example of a milling system. The milling system allows for different
types of cuts, such as quarter cut and plain cut. Among other things, this thesis combines
Pyles implicit surfaces rendering methods and a milling system first implemented by
Courier.
15
3. Overview of Solution
There were four goals for this thesis. The first was to create an easy-to-use GUI
Application. The second goal was to allow the user to select the species of the tree. The
species contains many different factors and variables that affect how the three-
dimensional model is generated. The third goal was to allow multiple cut types and
incorporate sawmill options. This would allow the user to request lumber in different
sizes all from the same tree. The six faces of each board would be automatically
calculated so the user never has to worry about the cutting plane. The fourth goal was to
incorporate the ability to import measurement data from a database. Actual tree ring
widths for thousands of trees are maintained by The World Data Center for
Paleoclimatology and NOAA Paleoclimatology Program in the International Tree-Ring
Data Bank. This free and publicly available data can now be imported and used in the
simulation model.

16
GUI Application
The GUI application was a necessity in order to make the renderer easy to use.
Previously, all renderers were console-based and used text files to set parameters. These
text files were hard to use for most people. Only the developer knew what values to use
for each setting in order to produce the desired results. Also, it was hard to visually guess
how certain settings would affect the final result.
#grain rendering file
#note, all caps definitions must be directly followed by data
#this file's reading is NOT fault tolerant

RINGS
10
#rings, int

COLOR
7
0.5 0.8
0.6 0.7
0.7 0.6
0.8 0.5
0.9 0.4
0.95 0.3
1.0 0.2
#number of phases, int
#phases listed in pairs, 2x double

TREELINE
105 -100 0
105 700 0
8
0
#start, 3x double
#end, 3x double
#weight, double
#startring, int
RENDER
55 395 5
210 395 5
55 0 5
400 400
0.25
noise_stuff
#origin, 3x double
#orientation, 3x double
#orientation, 3x double
#resolution x&y, 2x int
#step size, double
#outputfile, string

NOISE
300
30
5
#noise seed, int (same seed for same trees)
#noise scale, double, 30 (overall look of distortion)
#noise mag, double, 3.5 (amount of distortion)

OTHER
0.9
3
#blendCuttoff, double, 0 <bc <1
#thumbweight, double
Figure 13: Pyle's configuration file[6]

Additionally, the units and scales were typically unknown. In order to produce an
accurate model, the units need to be clearly defined. Since the database records in the
International Tree-Ring Database are typically in millimeters, all tree measurements are
converted to millimeters.

17
The GUI application also removed unnecessary and confusing options. Since the species
contains many factors and settings, the details can be shielded from the user, thus making
the application simpler to use. One of the goals of the GUI application was ease of use.
A user with little or no knowledge should be able to generate many different types of
wood grain.


Figure 14: Main window of GUI Application

The GUI application was written in C#[8]. This language was chosen because of its ease
of use, especially for GUI development. Also, the language is similar to J ava[9]. This
18
made the porting of Pyles original J ava rendering code fairly straight forward. The
render code has gone through vast changes and improvements, but the underlying
implementation of the implicit surfaces functions and rendering methods remain intact.
Additional options and settings have also been incorporated. The renderer is clearly
separated from the GUI application, with the anticipation that the renderer might be used
separately from the GUI application.

The main form allows for the user to save and load configuration files. All of the
configuration files are in XML to allow for manual configuration via a text editor, if
desired. Also this allows for the rendering engine to be used without the GUI
application.

The rest of the overview will be a walk-though using the GUI application. Each step
configures settings that affect the three-dimensional model and the creation of the texture
maps.

19
Species Selection
The Change button in the Species area will show the form in Figure 15: Species Selector.
This form allows the user to select a species. There are six species available: Pine, Oak,
Maple, Walnut, Cherry, and Zebrawood. The species definitions contain settings that
will change the three-dimensional model in order to simulate each species. Some of the
factors include color, noise, and branching settings.

Figure 15: Species Selector

The color of the wood grain in Pyles renderer is determined though phase values. A
point within a tree ring is given a value between 0 and 1 depending on the distance from
the start of the ring to the end of the ring. In Pyles implementation, a set of ranges are
defined along with a predetermined Hue and Saturation. The phase affected the
Brightness, or Value, of the HSB color.

20
After further testing and research, this method could not produce realistic results for
different species. The renderer now uses a complete set of HSB values for each phase.
The HSB values were sampled from scanned pieces of wood from each species. The
number of phases can vary from species to species, as long as phase ranges are defined
for all values between 0 and 1.

The Noise values are pre-selected for each species. Pine trees have low noise values
since they are typically straight and uniform. Oak trees usually have more crooked
branches and contain more variance in growth patterns. Therefore, the Oak species has
higher noise values. Each species has their Noise values set accordingly. This is one
example of how the GUI application easily allows the user to create more realistic wood
grain without requiring the user to know proper values for each species.

Finally, the species selection includes branching settings. The branch settings include
branchSize (a diameter percentage relative to the trunk), branchVerticalSpacing (vertical
distance between two branches), and the branchVerticalAngle (the angle between the
trunk and the branch). Figure 16: Comparison of branch parameters for Pine and Oak
compares the branching settings between Pine and Oak species.

Branch Parameter Pine Oak
branchVerticalSpacing 300mm (approx 1 foot) 600mm (approx 2 feet)
branchSize 10% of trunk size 50% of trunk size
branchVerticalAngle 0 degrees (horizontal) 60 degrees
Figure 16: Comparison of branch parameters for Pine and Oak

21
All of these preset parameters allow for a species-specific model to be generated without
the need to know specific values or settings.

22
Cut Type
Clicking the Change button in the Cut Type area of will show the form in Figure 17:
Wood Cut Selector. This form allows the user to select which type of cut will be used to
create boards. The form demonstrates different cutting methods and also shows a
preview of what the grain will look like. Figures 1 through 4 demonstrate each type of
cut.

Figure 17: Wood Cut Selector

Internally, settings are changed that affect the bin-pack placement algorithm and face
calculations which are made for each board. These settings also affect the on-screen
drawing algorithms in the Slice & Dice Preview area in the GUI, shown in figures 18
through 21.
23

Figure 18: Quarter Cut with three 2x4's

Figure 19: Plain Cut with three 2x4's

Figure 20: Lengthwise Cut with three 2x4's

Figure 21: Rotary Cut

The Rotary Cut type is a special case. This cut is performed by using a knife to cut a thin
layer of wood off in a spiral. This method is used to create plywood and veneers. In this
method, an Archimedes spiral is used to compute the two-dimensional texture map from
the tree-dimensional model.
24

= r
Figure 22: Archimedes Spiral[10]

b
ae r
cot
=
Figure 23: Equiangular Spiral[10]

The Archimedes spiral is unique in that distance between each rotation is equal, which
accounts for the constant thickness in a cut of plywood or veneer. Also, each step along
the spiral arc (fraction of circumference for any given point) is constant. If this was not
the case, the spiral would be an equiangular spiral and the final wood grain would appear
to be stretched at the one end and compressed in the other end. Since very thin layers are
typically sliced, only one face is computed compared to the six faces for each board
computed with every other cut type.

25
Tree Ring Source
In the Tree Ring Source area of the main form, the user can choose to use a constant ring
width or a database to provide ring width values. The simpler constant ring width option
allows for the user to set the ring width and the Tree Age (total number of rings).


Figure 24: Edit tree information form for constant ring widths

If the user chooses to use a database, they can select specific information through the
Database Selection form.

26

Figure 25: Database Selection form

The database will read most RWL formatted files (Raw Data Files) from the International
Tree-Ring Data Bank. The database contains information in various measurements and
formats. The GUI application will only import files containing the Ring Width measured
parameter and the Measurements Only standardization option. These two requirements
can be selected when searching the database on the website. Any database file can be
downloaded and put into the Data directory.

The database files and formats are not always consistent. For example, the file format
description says that the values are measurements in units of .01mm or .001mm of the
27
thickness of tree ring width for each year.[11] The database header information may be
present or missing. Also, values may be missing and may be represented by 999 or -9999
or nothing at all. From experimentation, along with trial and error, the file import
routines are very tolerant of mal-formatted or missing information. Most files will be
imported correctly. The routines also try to automatically detect the correct units used
and adjust accordingly.

The user can select the database to be used, along with the start year (when the tree began
growing) and the age of the tree. By default, a random core will be selected since each
database file may contain over 50 different tree core samples from the same site.
However, the user can select a specific core if desired. The user may also manually
override the data units and select either .01 or .001 millimeters. The form does a fair
amount of error checking to make sure that enough values are present in order to satisfy
the tree age and start year requested. Once the database options are selected, they will be
used by the three-dimensional tree model instead of using a constant tree ring width
value.

28
Cut Selection
The Cut Selection area of the main form contains a list of the cuts along with a preview
of the cut placement. This preview reflects the cut type previously selected.


Figure 26: Cut Selection area of the main window with the Quarter Cut type

The Add a Cut button allows the user to add additional cuts, which are then automatically
bin-packed into the tree. The placement area differs, depending on the cut type.

29

Figure 27: Cut Selection area of the main window with the Lengthwise Cut type

A cut is defined by the height and width (in inches), length (in feet) and quantity. These
units were used because they are the most common (locally). The application
automatically converts all measurements into millimeters, which it uses internally. If the
Rotary cut type is selected, the Add a Cut form appears with different units since
plywood is typically measured in feet and not inches.


Figure 28: Add a Cut form


Figure 29: Add a Cut form for Rotary cuts

30

Every time a cut is added, the bin-pack algorithm will automatically try to fit all the
requested cuts into the placement area. If this cannot be performed successfully, the new
cut will not be added and the user will have to select less cuts, smaller size boards, or a
larger tree. The Zoom slider to the right of the Preview area allows the user to zoom in
and out and adjusts the drawing all screen objects appropriately.

Optional Settings
The Render Options form, accessible form the menu bar under Options, allows the user to
specify the resolution and output file options. The resolution method was a very
important design choice. Originally there were no units in Pyles renderer. Also, he used
a step size parameter and a final resolution size to determine how the wood grain would
be rendered. The Pixels per Millimeter (PPMM) parameter was created to solve this
problem. There are several coordinate systems that all need to predictably work together.
The trees are all measured in millimeters. The bin-packing and board face computation
algorithms use millimeters. The screen resolution is in pixels and is dependent on the
zoom factor set by the Zoom slider. The final rendering output is in a different resolution
dependent on the PPMM setting. The PPMM setting eliminates a manual step size or a
static final resolution. If the user was allowed to specify that they wanted a 400 x 400
final resolution, they would also have to choose which face is 400 x 400, since all six
faces cannot have a 400 x 400 resolution or the final output would result in a cube. The
Options form pre-computes an example of final resolution for a 2x4 that is 8 feet long to
give the user some perspective. By default, the PPMM value is 1.
31


Figure 30: Render Options form
32
Wood Grain Generation
Finally, when the user presses the Start button, the generation begins. There are four
progress bars that follow the data structures. The user specifies a quantity of boards with
a specific cut (dimension). Each board contains six faces. Each face contains a certain
number of horizontal lines (of pixels).


Figure 31: The texture map generation form with progress bars
33

The progress bar uses two threads to create the texture maps while updating the GUI
controls. The overall progress is shown at the bottom with the time elapsed and time
remaining. The time remaining is a continually calculated value using the total amount
of lines currently generated, lines needed to be generated, and the time elapsed. The
performance of the renderer depends on the PPMM desired along with the quantity of
cuts, size of the boards, and CPU speed. Pyles algorithm has been optimized. The
renderer is slightly faster due to these optimizations and the use of C#over J ava.
34
4. Implementation Details
The implementation started with the porting of Pyles console-based J ava implementation
to C#. After an identical C#version was complete, the GUI application was started. The
first step was to remove the data input file dependency. Next, the renderer needed the
capability of rendering multiple files. GUI progress forms were also created. After the
renderer was capable of rendering multiple files, the cuts were implemented. This also
included the design and coding of the bin-packing algorithm for each cut along with the
preview rendering on the main form. The database form and importer was then
developed. The renderer needed to be modified in order to allow an array of tree ring
widths to be passed instead of just a static ring width used for the entire tree. The Species
classes were developed and settings specific to each species were migrated from the
treeData classes to the species classes. Finally, the branch growth algorithm was
developed along with the 3D tree model viewer to verify the branch growth algorithms
and the 3D board viewer to view the final product.

35
Porting from Java to C#
The porting from J ava to C#was fairly straight forward. Many of the classes, methods,
and properties were very similar or identical. For example, the J ava Math.cos() function
is Math.Cos() in C#. Some of the loops and iterations were rewritten to take advantage of
C#s foreach loop statements. Many C#properties were also added to replace get/set
methods. The .NET library, which C#uses, does not include a HSB to RGB function, so
one needed to be added. Pyles J ava implementation used the 3D Vector class in
java.util.Vector. For C#, Exocortexs Geometry3D vector class[12] was used. This class
contained all necessary vector math functions in an efficient, self-contained class, which
was free to use under the BSD license.

A new PhaseHSB structure was created. Pyles original renderer used a static Hue and
Saturation for the tree. This was found to produce poor results when using multiple
species. Now, each species contains an array of PhaseHSB structs and each phase range
contains a Hue, Saturation, and Brightness value. These values were sampled for each
species and can be now found in the species classes instead of the TreeData class.

The Noise-specific settings, such as scale and magnitude mentioned in Pyles thesis have
been moved into the species classes as well. The Noise object itself remains in the
TreeData class.

Pyles blendValue() function has been modified to allow for multiple tree ring widths
(also called Weights in Pyles work). This allows a database to provide exact widths for
36
each ring or to allow for a default width to be used for all rings. Additionally, the
blendValue() function needed to adjust the ring widths for the thumbweight and cut off.
This problem is described in detail below.

Pyles colorFunction() has been modified from a recursive function to a simpler iterative
function. His applyNoise () has also been optimized. These modifications are partially
responsible for higher performance. The TreeSegment and Noise classes remain mostly
untouched. A dynamic Radius property has been added to TreeSegment, which
dynamically calculates the radius depending on the use of a static ring width or array of
ring widths.

The renderer class has major changes in both structure and functionality. The only
RenderData passed is the PPMM, output file settings, and the cut type. All cut vectors
and dimensions, which were previously part of RenderData, are now passed in through
the Cut data structure. In Pyles implementation, the renderer contained the main()
function which read the configuration file then rendered the single image. Now, a
renderer object is created by passing the TreeData, RenderData, and Cut list. This
renderer object also includes a multi-threaded GUI progress form. The renderer
processes the Cut list and renders each face according to the TreeData and RenderData.
37

Cut Board Face
Height Front Face Height
Width Back Face Width
Length Top Face 3 vectors
defining the
cutting plane
Quantity Bottom Face
Array of Boards Left Face
Right Face
ID
Figure 32: The Cut, Board, and Face data structure and hierarchy

The renderTree() function has been modified in several ways. It dynamically calculates
the render plane vectors since they change for each face. Previously, this was done when
the configuration file was loaded. The function also calculates its points differently,
depending on the cut type. If the cut type is rotary, an Archimedes Spiral is created. The
Spiral class will return each point along spiral defined by the radius and PPMM.

Since every implicit surface has an effect on every pixel, the calculations can become
very long. Since a branch that is far away from the rendering point has virtually no effect
on the point, it can be skipped during calculation. Before rendering, a simple
optimization algorithm is run to mark the branches that can be skipped. Although it
could be highly modified and improved, the algorithm uses a simple, worst case Z-axis
value. If the face intersects any part of the branchs Z-axis range, it will be rendered.
38

Finally, additional progress variables were added to monitor the progression via progress
bars. The C#implementation uses delegates to update the GUI thread from the renderer
thread. These functions not only keep the user informed of the current render status, but
also provide an elapsed and estimated time for completion. This time is continually
recalculated using the elapsed time, total lines rendered so far, and total lines to be
rendered.

39
Maintaining a Consistent Radius
The thumbweight and blend cutoff values affect the final rendered widths. For example,
a tree with ten 5mm rings should have a radius of 50mm. But the thumbweight and blend
cutoff values can cause the tree have a radius of 20mm. In order to prevent this, the
width is temporarily increased in the blendValue() function.

Pyles implicit surfaces blending algorithm returns a value less than the blend cutoff if
the point inside the defined radius. If the blend cutoff is 1, then 100% of the tree will be
rendered. However, if a point is affected by two TreeSegments (a trunk and branch
intersection), then the effects of the two cannot be combined and will not be seen. The
cutoff value of 1 effectively turns the equation into a Boolean result: either inside or
outside. The result will be a sharp transition between segments. The blend cutoff is set
to 0.8. This allows for two intersecting branches to have a combined effect on that point,
thus resulting in a smooth transition. Unless the ring widths are altered, the trees radius
will appear to be only 80% of the expected size. Therefore, the width is divided by 0.8
before being computed in the blending equation. This adjustment would be valid if the
thumbweight was 1. Unfortunately, a larger of thumb weight of 3 is necessary to produce
a smooth transition.

A thumb weight is represented by the t in Pyles blending equation. (Reference Pyles
paper for an explanation of the equation.)

t
n n
t t
n
R P R P R P P P P B
+ + +
= ] / 1 [ ... ] / 1 [ ] / 1 [ 1 ) ... , (
2 2 1 1 2 1

40
A thumb weight of 3, for example, will effectively cube the value if P divided by R does
not equal 1. The thumbweight therefore has an effect on the final radius of the tree as
shown in Figure 10: Pyle's work using Implicit Surfaces. In order to approximate the
thumb weight and blend cutoffs effects to the radius, the ring width is temporarily
modified using the following approximation equation:
) )( (
t thumbweigh
f blendCutof f blendCutof
width
dth AdjustedWi =

By modifying the width before calculating the blend value, the original radius is
preserved.
41
Pyles Branching Problem
A major problem was discovered when knots were not appearing in many of the boards.
The branches were being placed and rendered correctly. The problem was due to the way
Pyles implicit surfaces algorithm rendered the branches under an incorrect assumption.
Pyle assumed that a branch, connected to the trunk, has fewer tree rings than the trunk.
He also assumed that a branch never connects to the center of the trunk.

Figure 33: Pyle's branch growth assumption

Upon further investigation, there are two different possibilities for the trunk and branch
intersection. In Figure 34: Illustrations from the Biology of Plants, (a) illustrates a live
branch, while (b) illustrates a dead branch. In both cases, the center of the branch
connects to the center of the trunk. In the live branch case, the branch and the trunk
contain an equal number of rings. The ring width is significantly smaller in the branch.
In the dead branch case, the trunks outer most rings abruptly stop creating a darker dead
bark area.

42

Figure 34: Illustrations from the Biology of Plants[13]

Pyles definition of a TreeSegment (a branch or trunk) included the start and end
position, along with the ring weight (width) and the start ring. The start ring was always
zero for the trunk. For branches, the start ring was the ring on the trunk where the branch
started to grow. The start ring parameter has been changed to a ring count parameter
since all TreeSegments start on the first ring (center of trunk), but may not have the same
number of rings. The implicit surfaces algorithm in blendValue() was modified to work
with this new change.

43

Figure 35: A rendered live branch


Figure 36: A rendered dead branch

These changes were necessary in order for knots to appear in most cuts. Most of Pyles
illustrations use tree trunks with only 10 rings. If you had a tree with 100 rings, and a
branch that has only 10 rings, then 90% of the trunk will not have any branches. This
causes most cuts to not have any knots, except for the outer most boards. With this
change, the branches are accurately connected to the center of the trunk creating proper
knots.

44
Manual Rendering
The Manual Rendering form was created to aid in my research and trials of various
settings and values. It is designed to allow most values to be set and sent directly to the
renderer.

Figure 37: Manual Rendering Form


Figure 38: Phase Editor in the Manual Rendering Form
45

This form has proved to be invaluable for development. Some of the many uses include:
Rendering plane (face) calculation
Unit evaluation and experimentation
Trunk and branch placement
Ring count and width experimentation
Performance testing (render time and last render time in status bar at bottom)
PPMM and resolution experimentation
Manual weight (tree ring width) and database experimentation
Color phase experimentation
And many more

Although this form was developed over time as an aid, I have decided to leave it in the
final application. This will allow the user and future developers to try specific settings.
It also allows the user to save and load settings in XML format. The image may be
copied to the clipboard or saved to a file. The manual renderer will only generate one
image and does not render complete boards or cuts. The manual renderer form uses a
special static version of the renderTree() function in the renderer class. This version of
renderTree() is similar to Pyles original, single image rendering system. The only
difference between this static version and the standard renderer object is that the static
version will only render a single image and will not show or give any progress. The
static version uses a single Face structure instead of a list of Cuts.

46
Main Form
The main form is responsible for the majority of the user experience. The selection of the
species and cut type are straight forward. These selections, however, affect many aspects
of the form and the resulting wood grain texture maps.

Most of the complex code in the main form is in the bin-pack placement of the boards,
calculation of the faces from a three-dimensional model to a two-dimensional texture
map, and the screen drawing functions for the preview area.

Every time a cut is added via the Add a Cut button, the bin-pack placement algorithm is
run. This checks to see if the new Cut, which may include any quantity of boards, will fit
in the placement area. If the entire cut will not fit for any reason, the user will be notified
and the cut will not be added to the Cut List. Finally, the list and the preview are
updated.

Before any bin-pack algorithm can be run, the boards for the new cut are initialized.
Each cuts height, width, and length are in inches or feet, but all dimensions on each face
of each board dimensions are in millimeters. The bin-pack algorithm uses the front face
of each board (measure in millimeters) to perform all calculations. The bin-pack function
is a two-dimensional algorithm running on the Z =0 plane. No attempt is made to pack
multiple boards lengthwise along the trunk (Z-Axis).

47
A standard needed to be established for the orientation of each face. This affects the
height & width of each face, as they may actually be the length of the board for certain
faces.

Figure 39: Plain and Lengthwise Cut Face Orientations


Figure 40: Quarter Cut Face Orientations
Bottom

Front
Left
Right
Top Back
Width
Length
Height
Red markers
indicate Top
Left of face
Back
Left Front
Top
Bottom
Right Back
Height
Length
Width
Red markers
indicate Top
Left of face
48

The PlaceboardData() contains the bin-packing algorithm. First, it constructs
mathematical equations to account for the shape of the placement region. For example,
in the quarter and plain cuts, the boundaries for the ice cream cone-shaped region
illustrated in Figure 26: Cut Selection area of the main window with the Quarter Cut type
is created using slope lines and ellipse functions. The algorithm will then attempt to
place the board in the bottom left portion of the region. If the entire front face can fit
without being obstructed by a boundary or another face, it is assigned an ID. If all faces
acquire an ID, then the cut, and all of its boards, can be added to the cut list.

The quarter cut introduced some challenges. Since the orientation layouts were defined
to keep the faces predictable and consistent, the bin-packing and screen drawing
algorithms had to be modified. The quarter cut type modifies the algorithm because the
height and width are reversed when compared to the plain and lengthwise cut types.
Additionally, the Top Left orientation point has been rotated 90 degrees. The bin-
packing algorithm doesnt care how the face is rotated because it typically used the Top
Left point on the XY plane. In the quarter cut, the Top Left point is actually the Top
Right on the XY plane. These cases needed special consideration and implementation.

After all of the boards have been successfully placed in the placement region via the front
face, all other faces needed to be calculated via the calculateFaces() function. By passing
the Top Left point (on the XY plane) the function can calculate the Top Left, Top Right,
and Bottom Left vectors for each face. These define six cutting planes defined for the
49
board. This function is very tricky and differs depending on the cut type. The strict
orientation definition and layout illustrated in Figure 39: Plain and Lengthwise Cut Face
Orientations and Figure 40: Quarter Cut Face Orientations was the key to successfully
implementing this function.

Finally, the painting functions draw the preview on the screen. First, the background is
drawn. All backgrounds show a horizontal slice of the tree trunk with the plane defined
at Z=0. The details of each preview depend on the cut type. For example, a lengthwise
cut type will display the entire diameter of the trunk, while the quarter and plain cut types
will display only half of the diameter since the placement region is a quarter of the trunk.
These are all illustrated in Figure 18: Quarter Cut with three 2x4's through Figure 21:
Rotary Cut. Each screenshot is shown at the default Zoom level for each cut type. The
Zoom slider allows for the preview to be zoomed in or out. All relative screen drawing
functions use the zoom factor.

Once the appropriate background is drawn to the screen, the function processes the cuts.
Each cut in the cut list contains one or more boards. The front face of each board will be
drawn to the screen. Quarter cut types must be handled differently from plain and
lengthwise since their top left points are actually the top right points in the renderers
coordinate system. Additionally, the zoom factor must be included in the calculation in
order to keep the same perspective as the background.

50
The rotary cut type is a very special case. None of the rotary cuts are ever placed or
drawn to the preview area on the screen. The preview area draws an exaggerated spiral
in order to demonstrate the cutting method. The rotary method can theoretically create
hundreds of feet of very thin wood grain (or veneer). Because of this, any type of bin-
packing or preview is inappropriate.


51
Branching and the 3D Tree Model Viewer
A three-dimensional viewer was added late in development in order to validate the
branch growing algorithms. These algorithms are responsible for placing (growing)
branches according to species specific variables. The variables that used to describe
branches were branch vertical spacing, branch size, and branch vertical angle. The
algorithm starts at the bottom of the trunk and uses the variables to construct a list of
branches. These branches are TreeSegments, which contain three dimensional vectors
for the start and end points, along with the ring width(s) and the ring count.

The branches were hard to visualize, which made the algorithm difficult to validate. This
started investigation into three-dimensional rendering. The two choices for three-
dimensional rendering in C#were Direct3D (part of DirectX[14]) and OpenGL[15].
DirectX 9 is a managed library which is much easier to use than previous unmanaged
versions. DirectX 9 is also fully supported and integrated into Visual Studio .NET.
OpenGL is a viable alternative when using C++, but needs third-party wrappers to be
utilized in C#. Therefore, DirectX 9 and Direct3D were used.

The 3D rendering was surprisingly challenging. Since Direct 3D is used to make the
most modern and complex games, there are many options and settings that need to be set
or turned off. Meshes were used to create cylinder in order to represent a TreeSegment
as a trunk or branch. The actual radii were used from the TreeData in order to give an
accurate representation of the tree.

52

Figure 41: 3D Tree Model Viewer


53
The difficult part was to create the appropriate transformation and rotation matrices for
each TreeSegment. The start and end points of each branch created a cylinder that had its
own yaw, pitch, and roll relative to the trunk. The rotations were calculated by using
Quaternions. The rotation between the trunk vector and the branch vector resulted in a
Quaternion. That value was then converted to a rotation matrix.

The navigation is controlled by the mouse using an ArcBall[16]. The ArcBall, originally
developed by Ken Shoemake, maps the mouses two dimensional coordinates onto a
three dimensional sphere. This allows the user to view the model at all angles.

A snapshot of the 3D rendering can be captured. This is done by copying the front buffer
onto a newly created off-screen surface. The rendering panels area of the surface is then
converted to an image object. The image may be copied to the clipboard or saved to a
file.

The 3D viewer will also gray out branches that have been optimized out of the rendering
calculations. This is only shown when viewed from the Manual Rendering form.

After the 3D Viewer was complete, the branching algorithms could be validated. For
example, the branches from Oak trees joined the trunk at 60% angles. Their radii are also
larger when compared to a Pine trees horizontal branches.


54
3D Board Viewer
A three-dimensional board viewer was added late in the project so the user could view
the final product. The renderer will produce six faces for each board. The 3D Board
Viewer puts all six faces together. A board is rendered using a texture map for each face.
The viewer allows the user to visually see the knots going through the board. Prior to the
3D Board Viewer, the user had to imagine the faces being placed next to each other. The
3D Board viewer uses the ArcBall control, which enables the user to view all faces of the
board. The 3D Board viewer shares the same screen capturing features as the 3D Tree
Model Viewer. The size of the board is automatically adjusted depending on the height
and widths the texture maps.

55

Figure 42: 3D Board Viewer
56
5. Results
This thesis resulted a powerful, easy-to-use application that is capable of generating
many different types of realistic wood grains. The GUI application allows a user to
choose any combination of species and cut types in order to create any number of cuts.
Additionally, a database can be used to produce even more accurate models. The
application allows users with little or no knowledge create very realistic wood grains. It
was also designed to allow the developer to easily extend the renderer and/or GUI
application. For example, new species can easily be added and integrated into the
application.

Pyles original work on implicit surfaces has shown to be flexible. I was able to add
additional features and customization, such as database integration and complete HSB
phase values without major modification. With these changes and some optimizations, I
was able to use his existing work and create realistic wood gain.

Species
The species of the model can now be easily set by the user. The species affects the color,
noise, and branching patterns. Figure 43: Western Yellow Pine Species-Figure 48:
Zebrawood Species illustrate the top face of a plain cut board for each species.

57

Figure 43: Western Yellow Pine
Species

Figure 44: Northern Red Oak
Species

Figure 45: Sugar Maple Species

Figure 46: Black Walnut Species

Figure 47: Black Cherry Species

Figure 48: Zebrawood Species
58
Cut Type
The cut type allows for a cut to be milled using different methods. The following shows
a board milled with each cut type.




Figure 49: Plain Cut board



Figure 50: Quarter Cut board


59


Figure 51: Two Lengthwise Cut boards sharing the same branch knot

60
The rotary cut type allows the renderer to generate plywood and veneer wood grains.


Figure 52: Rotary Cut


61
Tree Ring Database
The ability to import real tree ring width values from the International Tree-Ring Data
Bank allows the user to accurately model trees from different areas around the world.
Pyles implementation only allows for a single tree ring width to be used for every ring.
Now, every branch can use unique tree ring widths for each ring.

Figure 53: The top face of a length wise 2x4x1 cut
of a 100 year old Pine (1880-1980) from Sequoia National Park
62
Pine from the Sequoia National Park (Core ASP04B)
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
1
8
8
0
1
8
9
0
1
9
0
0
1
9
1
0
1
9
2
0
1
9
3
0
1
9
4
0
1
9
5
0
1
9
6
0
1
9
7
0
1
9
8
0
1
9
9
0
Year
R
i
n
g

W
i
d
t
h

(
M
M
)

Figure 54: The annual ring width for 100 years of the same Pine tree used in Figure 53

Tree ring widths vary from year to year. Trends can indicate changes in weather patterns,
such as drought. Figure 53: The top face of a length wise 2x4x1 cut and Figure 54:
The annual ring width for 100 years of the same Pine tree used in Figure 5 both use the
same data, although it may be hard to see all 100 rings and any growth patters in Figure
53: The top face of a length wise 2x4x1 cut. This is due to the low resolution and
number of rings rendered in the picture. Figure 55: A cross-section illustrating a four
year drought is an example where a four year drought was present. This is clearly
indicated by the abnormally narrow ring widths.

63

Figure 55: A cross-section illustrating a four year drought
64
6. Future Work

This thesis is a major milestone in the procedural generation of wood grain. It took
Pyles implicit surfaces proof of concept thesis and expanded the features and
functionality. There are still many areas which are applicable to future work and
research.

Additional cut types could be supported. The Rift and Half-Round cuts are not present in
this thesis. This is due to the implementation complexity. Rift cut is similar to a quarter
cut, but is sliced at a slight angle. This adds complexity to the bin-packing algorithm.
Half-round cut is similar to plain cut, but the faces are cut at a slight arc.


Figure 56: Rift Cut


Figure 57: Half-Round Cut

The application uses bin-packing to automatically place each board. Before the boards
are packed, the cut list is sorted by each boards front face area. The result is larger
boards, such as 4x4s being packed before 2x4s. This was a design decision. However,
additional alignment and packing algorithms may be desired. The application currently
uses two-dimensional bin packing. Future applications may choose to implement three-
65
dimensional bin packing algorithms in order to use the entire length of the log. Manual
placement of boards may also be useful as an option instead of automatic bin-packing
algorithms.

The gradient and color system has been substantially improved. Pyles color system used
a fixed Hue and Saturation. It linked the Brightness (Value) to the Phase, a value
between 0 and 1 representing the distance from the start to the end of the ring. Currently,
any number of phases may be defined as each phase contains its own Hue, Saturation,
and Value. Most species are defined with approximately six phases. This generally
produces good results. However, a much more subtle gradient would produce more
realistic results. A system where each phase would blend together might produce more
realistic results.

Parabolic gradients were also investigated for this thesis. A parabolic curve was mapped
to the gradient pattern of the tree ring. This mainly used the brightness as the parameter
with fixed Hue and Saturation values. The current Hue, Saturation, and Brightness model
used was selected since the different Hue and Saturation values in each phase produced
more realistic results for different species.

Additionally, computation time must be investigated. In the current implicit surface
model originally developed by Pyle, each phase of each ring is considered another
implicit surface. For example, a tree with 50 rings, each containing 6 phases, results in
300 implicit surfaces. This is only for the trunk. Currently the pine tree model is
66
10,000mm tall (about 33 feet). In this model there are approximately 90 branches. 90 *
300 =27,000 branch surfaces plus the trunk surfaces =27,300 surfaces in a worst case
scenario with no optimization. If a parabolic gradient system is used with the current
system, an implicit surface must still be used for each color. So, even if the parabolic
gradient system is capable of producing 30 shades for each ring, that is 136,500 implicit
surfaces (50 rings * 30 shades * 91 segments). Also, keep in mind that this is just to
generate a single face. There are six faces for each board. Obviously, the current system
was not designed for the parabolic gradient system described. Other color systems could
be researched that would produce more realistic looking gradients and blending without
substantially hurting performance.

Figure 58: Experimentation with a parabolic gradient color system
67

Since so many implicit surfaces are involved in every calculation, optimization is
necessary. Pyles rendering algorithms have been improved. Additionally, the
optimizeRendering() function significantly reduces the number of implicit surfaces
involved in the rendering functions. The optimization is very basic, since it only
considers the worst case scenarios along the Z-axis (the trunk). Additional branch
removal optimizations could be used, including different collision detection methods
used in real-time three-dimensional graphics engines. Additionally, a different
colorization system may eliminate the need to use an implicit surface for each phase.
Currently the colorization increases the implicit surface count by approximately six
times.

There are many irregularities in wood grain that are ignored in the current rendering
system. For example, the branches (knots) are typically darker in wood. This is ignored
in the rendering engine as it would necessitate special consideration for branch
coloration. Other variables that could be considered for future extensions include
boughs, bark, and special grain patterns created by certain species, such as birds eye or
quilted maple.

Finally, many different species could be easily added. Six example species are
included to demonstrate the versatility of the rendering system. Many more could be
added using the existing variables. More complex branch growth algorithms could be
68
introduced for new species. Overall, the rendering system is designed to be easily
extensible in many directions.
69
7. References

1 Cut Type illustrations by Oakwood Veneer,
http://www.oakwoodveneer.com/tips/cuts.html
2 International Tree-Ring Data Bank, http://www.ngdc.noaa.gov/paleo/treering.html
3 Adobe Photoshop, http://www.adobe.com/products/photoshop
4 Senkeresty, Scott. Wood Grain Modeling, California Polytechnic State University,
1995.
5 Matsui, Michael. Tree Parameterization for Wood Grain Modeling. California
Polytechnic State University, 1999.
6 Pyle, Robert Wood Grain Modeling Using Implicit Surfaces, California Polytechnic
State University, 2003
7 Courier, Michelle The Design and Implementation of the Wood Object Modeling Tool,
California Polytechnic State University, 1999
8 Microsoft Visual C#, http://msdn.microsoft.com/vcsharp/
9 Sun J ava, http://java.sun.com
10 Famous Curves Applet Index, http://www-gap.dcs.st-and.ac.uk/~history/J ava
11 Tree Ring Data Description, http://www.ngdc.noaa.gov/paleo/treeinfo.html
12 Exocortexs Geometry3D, http://www.exocortex.org/geometry3d
13 Raven, Evert, Eichhorn, Biology of Plants, Sixth Edition, W.H. Freeman and
Company/Worth Publishers, 1999
14 Microsoft DirectX, http://www.microsoft.com/windows/directx
15 OpenGL, http://www.opengl.org
16 Shoemake, Ken, Arcball Rotation Control, Graphics Gems IV, Academic Press
Professional, Inc., 1994
70
8. Appendix A: Development Platform
The hardware platform used for this thesis was an Intel Pentium IV 3.0 GHz system with
512 MB ram running Microsoft Windows XP. The software was developed using Visual
Studio .NET 2003 and the 1.1 version of the Microsoft .NET runtime. The three-
dimensional viewers use Direct3D, part of the DirectX 9 SDK. The Vector class was
written by Exocotex. The FolderBrowser control was written by Rama Vavilala
(http://www.codeproject.com/cs/miscctrl/folderbrowser.asp).

The requirements in order to run this program:
Microsoft .NET Runtime
http://msdn.microsoft.com/netframework/technologyinfo/howtoget/
Microsoft DirectX Redistributable (for 3D Viewers)
http://www.microsoft.com/windows/directx/downloads/
DirectX must be installed with the /installmanageddx switch to install the
managed DirectX assembilies. For example:
<location of DirectX files>\dxsetup.exe /installmanageddx
71
9. Appendix B: Source Code
The source code will be available at
http://www.csc.calpoly.edu/~buckalew/projects/woodGrain