gremm: a real-time graphics engine for forest rendering · the ﬁeld of real-time1 computer...

Umea UniversityDepartment of Computing Science

MASTER THESIS

GREMM: a real-time graphics

engine for forest rendering

11th February 2003

Morgan Johansson

[email protected]

Supervisor:

Berit Kvernes

[email protected]

c©Copyright 2003 Morgan Johansson

GREMM: A REAL-TIME GRAPHICS ENGINE

2

Abstract

One of the hardest problems within real-time computer graphics is the realisticrendering of detailed outdoor scenes. Outdoor scenes with plants, grass andtrees are difficult to render in real-time mainly because of the extremely highnumber of graphical primitives needed for realistic visualization of them.

This thesis describes the theory behind an OpenGL-accellerated graphicsengine, which was created specifically for the purpose of rendering forest sceneswith a very high polygon count. It is based on dynamically generated impostors,which where first described in 1995 but then used in a slightly different way, asthe engine among other things introduces a planning stage where the renderingof the scene is treated as an optimization problem.

The test results show that rendering engines based on dynamically gener-ated impostors may give significant gains in frame-rate compared to normalrendering, at the cost of a slightly reduced visual quality. The frame-rate wasunder certain conditions increased by 500% while the visual impact was low.

Currently, there is still room for improvement of the techniques as the visualquality is not always satisfactory. It is expected that the future developmentwill yield both improved quality and performance.

3


4

Acknowledgements

I would like to thank my supervisor Berit Kvernes for her help and for neversaying she was too busy to help me whenever I came knocking at her door.

I also wish to express my gratitude to my girlfriend Maria Paajarvi for hersupport whenever I needed it.

Finally, I would like to thank my parents for the encouragement and supportthey have always given me.

5


6

Contents

1 Introduction 111.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Description of the problem domain . . . . . . . . . . . . . . . . . 121.4 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Current techniques 152.1 Billboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Common techniques in entertainment software . . . . . . . . . . 16

3 Previous work 193.1 Real-time display of forested virtual scenes . . . . . . . . . . . . 193.2 Dynamically generated impostors . . . . . . . . . . . . . . . . . . 203.3 Other relevant work . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Generation of trees 234.1 L-systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 A modular tree generation system . . . . . . . . . . . . . . . . . 254.3 Generation results . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Overview of GREMM 295.1 Calculating the importance of objects . . . . . . . . . . . . . . . 305.2 Approximating rendering cost . . . . . . . . . . . . . . . . . . . . 345.3 Measuring visual quality . . . . . . . . . . . . . . . . . . . . . . . 355.4 Impostor generation . . . . . . . . . . . . . . . . . . . . . . . . . 395.5 The rendering cache . . . . . . . . . . . . . . . . . . . . . . . . . 415.6 Planning the rendering . . . . . . . . . . . . . . . . . . . . . . . . 435.7 Object clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.8 Implementation details . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Performance analysis of GREMM 476.1 The visual quality . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.3 Test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7


6.4 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7 Drawbacks with GREMM 61

8 Future development of the engine 638.1 Alpha blended impostors . . . . . . . . . . . . . . . . . . . . . . . 638.2 Shadows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.3 Cluster-based impostors . . . . . . . . . . . . . . . . . . . . . . . 658.4 Efficient cache lookup . . . . . . . . . . . . . . . . . . . . . . . . 658.5 Improved texture management . . . . . . . . . . . . . . . . . . . 668.6 Animation support . . . . . . . . . . . . . . . . . . . . . . . . . . 668.7 Dynamic K-means clustering . . . . . . . . . . . . . . . . . . . . 67

9 Concluding remarks 69

8

List of Figures

2.1 Billboards used for distant trees . . . . . . . . . . . . . . . . . . 162.2 The foliage consists of several billboards . . . . . . . . . . . . . . 172.3 The branches are represented with partially transparent textures 17

4.1 A very simple L-system example . . . . . . . . . . . . . . . . . . 244.2 Plants generated using simple L-systems . . . . . . . . . . . . . 254.3 A possible setup of component types . . . . . . . . . . . . . . . . 264.4 Trees generated using the modular tree generator . . . . . . . . . 28

5.1 Cylindrical bounding box . . . . . . . . . . . . . . . . . . . . . . 305.2 The impact of apparent size on importance . . . . . . . . . . . . 315.3 The impact of foreground/background on importance . . . . . . 325.4 The impact of horizontal centering on importance . . . . . . . . . 335.5 The impact of camera translation/rotation on importance . . . . 345.6 Error due to changing direction . . . . . . . . . . . . . . . . . . . 365.7 Error caused by perspective view . . . . . . . . . . . . . . . . . . 375.8 Impostor resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 395.9 An impostor of the tree will be rendered . . . . . . . . . . . . . . 405.10 The tree is centered on the screen but does not fit the texture . . 415.11 Changing the FOV . . . . . . . . . . . . . . . . . . . . . . . . . . 425.12 The object and its bounding box fit inside the texture . . . . . . 435.13 The impostor will use this area as a texture . . . . . . . . . . . . 445.14 Fake shading by tilting the normals . . . . . . . . . . . . . . . . . 445.15 The basic role of the rendering cache . . . . . . . . . . . . . . . . 455.16 Clustering of trees . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.1 Impostor using a texture of the wrong resolution . . . . . . . . . 486.2 A virtual fly-through . . . . . . . . . . . . . . . . . . . . . . . . . 496.3 A screenshot of the performance testing program . . . . . . . . . 506.4 A forest scene with a total of 1280 trees . . . . . . . . . . . . . . 60

8.1 Time-based alpha blending for transition . . . . . . . . . . . . . . 648.2 Alpha blending of sampled views . . . . . . . . . . . . . . . . . . 648.3 A rendering cache tree structure . . . . . . . . . . . . . . . . . . 65

9


8.4 More efficient texture allocation . . . . . . . . . . . . . . . . . . . 66

10

Chapter 1

Introduction

The field of real-time1 computer graphics is one of the fastest evolving fieldswithin computer science and engineering. This has more recently been causedmainly by the rapid developments within hardware acceleration of 3D computergraphics. In fact, the rate at which graphics hardware has become faster hasbeen far exceeding Moore’s law2 during the few years. Even with this rapiddevelopment there are challenges within computer graphics that probably willremain very challenging for many years to come. One of those is the the realisticdisplay of outdoor scenes that are rich in plants. The amount of detail neededto realistically display a dense forest is staggering. That is not to say thatattempts are not made to display forested scenes as the forest is, for obviousreasons, one of the most important settings for virtual environments. Thisthesis will describe the theory behind the the Graphical Rendering Engine forMassive Multiplicity (GREMM), an OpenGL3-accelerated real-time renderingengine created specifically for the purpose of rendering forests.

1.1 Background

Nearly all early representations of trees and plantlife in real-time 3D graphicshave relied on billboards (described in closer detail in section 2.1). Billboardscan be highly detailed and require very little resources, but generally they lookflat and unrealistic.

The transition from billboards to the more realistic actual 3D geometry hasbeen slow but is constantly ongoing as the hardware constantly becomes faster.

1Within computer graphics, the term real-time usually refers to an animation which is

created on-the-fly. Usually this means that what is seen on the screen is less than 2/FPS

seconds old.2More than 25 years ago Gordon Moore predicted that the number of transistors on a

microprocessor would double approximately every 18 months. This generally translates to a

doubled computing speed every 18 months.3An application programming interface for the development of 2D and 3D graphics appli-

cations.

11


Today, most entertainment software relies on 3D geometry for representation oftrees. While these representations are still simple and not really realistic theystill provide a higher degree of realism than billboards.

The use of real 3D models for plantlife poses another problem - the geometricmodels. There are three different ways to create new models. The first is tothree-dimensionally scan existing plants (which is expensive), the second is tohave an artist create the models (which is time-consuming and often expensiveas well) and the third, which is the one used in this thesis, is to automaticallygenerate the models.

The most well known, and widely used, technique for generation of plants isby using L-systems introduced in 1968 by Astrid Lindenmayer [Lin68]. Theseprovide highly detailed and realistic models of plants. The only major drawbackis that the models are often so natural (and therefore - complex) that forestsof such plants are unrealistic to render in real-time, using the usual renderingalgorithms.

1.2 Objective

The objective of this thesis is to describe how a virtual forest with a very highpolygon count can be displayed using a combination of techniques. This is doneby describing the techniques used in GREMM. GREMM will also be used toevaluate the effectiveness of these techniques.

1.3 Description of the problem domain

Though the objective states that the thesis will describe how a virtual forestwith a very high polygon count can be displayed, the techniques behind GREMMare more general than so. In fact, it is expected that the engine will performeven slightly better on some types of animated objects since popping4 effectsare less noticeable then.

Generally the problem domain covers all cases where a 3D engine shoulddisplay identical objects multiple times in the same scene within a short time-frame. To exemplify this, assume a scene where a thousand marching soldiersare displayed. The soldiers are all identical and are in almost identical poses,but are seen in different locations. Unless the number of poses in the scene ishuge, the engine will quite often be able to reuse previously rendered soldiersto reduce the time needed to render the scene.

A good example of a scene which fits GREMM badly is a scene displayinga simulated lava lamp. The lamp constantly morphs and it is for that reasonnot possible to reuse previously rendered representations of the lava lamp.

4When the steps in an animation are so big that the object appears to ”pop” into its new

position/pose.

12

CHAPTER 1. INTRODUCTION

1.4 Structure of the thesis

The thesis begins with a survey of the current techniques in use to solve theproblem of rendering trees. It then describes the methods currently in use andthe previous scientific work done in mainly the field of dynamically generatedimpostors but also in some other relevant fields. Following that, L-systems arebriefly described. A basic understanding of L-systems is required for the follow-ing parts where the specifics of the tree-generator used in the test applicationis described.

The main part of the thesis describes the theory behind GREMM and this isfollowed by an experimental analysis of the performance of the engine. Finally,the thesis concludes by discussing the drawbacks and possible future develop-ment of GREMM.

It is assumed that the reader has a basic understanding of concepts and tech-niques in 3D computer graphics.

13


14

Chapter 2

Current techniques

Compared to the rapid developments within computer graphics, the methodsused for real-time visualization of trees have evolved very slowly. The improvedrealism of real-time-rendered plants today is to a large extent an effect of thefaster hardware and the better methods used for creation of the 3D geometry.There are several proposed methods to increase the realism of rendered trees,but these have, so far, only sparsely been used outside of the academic domain,and when so - usually in specialized software.

2.1 Billboards

Billboarding is one of the most common techniques to reduce the complexityof a graphical scene. The basic concept is very simple - represent an object byusing the image of the object instead of using a real-time rendered representa-tion based on its geometric properties. Billboards are usually implemented asrectangular polygons that are textured1 with an image and which always rotateto face the viewer (hence the name billboard). Often these display differentimages when viewed from different directions, but only in discrete steps as eachof these directions is statically included as a prerendered texture.

Billboards have several serious drawbacks. They look flat, especially whenthe viewer is close, and rarely have a good enough resolution to handle thesituation when the viewer is very close to the tree, resulting in clearly visiblepixelation. A problem with billboards that display different images for differentviewing directions is popping since it is difficult to have sufficiently many view-ing directions covered, especially when the viewer moves in three dimensions(in relation to the viewed object).

1An image is used to drape a polygon. The texture assigns colour information to the

polygon.

15


2.2 Common techniques in entertainment software

Figure 2.1: Billboards used for distant trees

Modern entertainment software (also known as computer games) generallydisplay trees as simplified 3D geometry where the most complex structure ofthe tree, the foliage, is made out of partially transparent textures (which oftenare billboards). This is the case in the game Battlefield 1942 2 developed byDigital Illusions CE, which is fairly representative for entertainment softwarein general.

Figures 2.1-2.3 display screenshots from Battlefield 1942 where the differentlevels of detail involved the tree rendering are clearly displayed. Figure 2.1shows a tree as seen from a great distance, represented by a single billboard.As the viewer moves closer, the stem of the tree is replaced by 3D geometry, andthe foliage is displayed using several textured, partially transparent polygons,as shown in figures 2.2 and 2.3.

2Battlefield 1942tm is a registered trademark by Digital Illusions CE

16

CHAPTER 2. CURRENT TECHNIQUES

Figure 2.2: The foliage consists of several billboards

Figure 2.3: The branches are represented with partially transparent textures

17


18

Chapter 3

Previous work

3.1 Real-time display of forested virtual scenes

Forest rendering is a very complex field, and hence there are many researchfields within computer graphics from which methods can be applied to forestrendering. Those mentioned here have either been directly applied to forestrendering or are quite closely related to the work described in this thesis.

Marshall et. al. [MWW01] wrote about automated generation of forestedscenes and real-time display of them. Their approach to the real-time displayof forested scenes was similiar to the one used in this thesis, using dynami-cally generated impostors and level of detail (LOD)1 techniques. They showedthat the performance of the system was greatly improved by these techniquesbut they also stated that there are problems associated with these techniquesresulting in a lowered visual quality.

Meyer et. al. [MNP01] described a method for rendering trees based onblending of precomputed hierarchical impostors. The method supports bothshading2 and shadowing and the main drawback is that it requires a lot oftexture memory.

Another precomputed approach was described by Jakulin [Jak00] - a simpleand fast approach based on slicing and alpha blending3 of the slices whichprobably works best on fairly dense vegetation.

A technique for simplification of the foliage was described by Remolar et. al.[RCB+02]. They also described how the technique could be used to reduce thecomplexity of the trees, not only through common LOD, but also by reducingthe complexity at the far side of the foliage.

Another technique for simplification was described by Marshall et. al.

1A technique to reduce the complexity of the scene. Objects are represented in several

levels of detail (usually referring to the number of polygons and resolution of the textures).2Colouring a polygon according to its incident light. The colour depends on the position,

orientation and attributes of both the surface and the sources of the light.3The blending of images by transparency.

19


[MFAC97]. It is an interesting approach based on subdivision of the sceneinto tetrahedrons that are used as approximations of their contents.

Deussen et. al. [DCSD02] recently showed how rendering with points andlines (similar to the approach of Reeves and Blau [RB85]) could be used torender the plants in fairly complex outdoor scenes in real time. Weber andPenn [WP95] have also used points and lines for drawing trees.

3.2 Dynamically generated impostors

An impostor is a replacement object used to mimic another object of highercomplexity. Maciel and Shirley [MS95] defined an impostor as an entity thatis faster to draw than the true object, but retains the important visual charac-teristics of the true object. Billboards (section 2.1) and traditional LOD areexamples of commonly used impostors. In [Sch95], Schaufler described dynam-ically generated impostors and how these could be used to reduce the renderingcomplexity of the scene. The algorithm used for updating the impostors wassimple:

DrawObjectWithImpostor()

if (maximum resolution of impostor) > (screen resolution)

if error for existing impostor is large enough

newImposter()

drawImpostor()

else

drawTrueObject()

The impostor is created by using the rendered image of the true object asa texture on a billboard. Schaufler et. al. [SS96] later extended the techniqueby introducing a hierarchy of impostors, where impostors at a lower level areutilized when rendering the higher level impostors. This thesis will not use thisextended method mainly because it fits badly with the suggested extensions,since it uses more texture memory and increases the total number of impostorsin the scene.

There are several differences between Schaufler’s impostors and those usedin GREMM. The most important ones concern the management of the impos-tors, and the actual impostor is basically the same. The main reason for thedifferences between Schaufler’s work and the methods used for impostors inthis thesis is the slightly different problem domain. While Schaufler focuses onreducing the complexity of the scene using a specified minimum quality (in thecase described in [Sch95] - getting the highest possible frame rate without loos-ing visual quality), forest rendering is often a problem where rendering withoutvisual degradation is not possible so the goal is to get the highest possible visualquality at a specified frame rate.

20

CHAPTER 3. PREVIOUS WORK

3.3 Other relevant work

Particle systems

First described in 1983 [Ree83], particle systems today belong to the most im-portant techniques within both real-time and prerendered graphics. Particlesystems stochastically create minute particles in controlled ways. These parti-cles then follow some defined set of rules (often based on the laws of physics)until their lifespans are over and they disappear.

In 1985, Reeves [RB85] showed that particle systems could be used (backthen in non-real-time) to render realistic trees, by displaying this in the an-imated short movie The Adventures of Andre and Wally B. [Luc84]. So farthis method has only been used in experimental or specialized software, andentertainment software has not yet used particle systems for forest rendering,though particle systems are commonly used for other purposes.

Ground vegetation

Rendering of grass is one field that has received much attention, much of itbecause of its close resemblance with the rendering of fur. Reeves [Ree83]showed how particle systems could be used to create realistic grass, however,rendering whole fields of grass in real-time using this approach is not possibleyet. Currently, the most widely used way to render fields of grass (in waysmore realistic than just texturing the ground) is probably by using volumetrictextures [MN98][BB02].

Volumetric textures do not work very well when viewing grass from theside, since the gaps between the layers of textures become visible. Perbet et. al.[PC01] proposed using three different representations to overcome this problem.Their work shows that by combining several techniques it is possible to displayfields of grass quite realistically even in real-time.

Occlusion culling for forested scenes

An efficient and fast algorithm for occlusion culling4 of forested scenes wouldgreatly enhance the performance when displaying dense scenes. Unfortunately,most trees are badly suited as occluders since the foliage rarely is dense enoughto completely occlude everything behind it and also because trees do not resem-ble any simple geometric shapes. That does not mean there are no availablealgorithms, but it limits the choices to algorithms which do not utilize thegeometric properties of the objects, as such algorithms would be too slow.

The Hierarchical Z-Buffer Visibility [GKM93] algorithm is one suitable al-gorithm, which makes use of the Z-buffer5 (in practice - the Z-buffer of the

4The removal of objects that are hidden behind other objects.5A buffer containing depth information.

21


previous frame) to find which objects are visible. Aside from using the Z-buffer, the algorithm is completely software-based on most platforms. Bartz et.al. [BMH99] proposed another Z-buffer-based algorithm which made more useof the graphics hardware, and they had very promising results. Their methodhad the drawback that it could possibly remove objects that were not com-pletely occluded. Further, as it was hardware assisted, it put more strain onthe graphics hardware than the hierarchical Z-buffer visibility algorithm.

22

Chapter 4

Generation of trees

As trees are complex structures, one might think that automatic generationof trees is difficult. That is not the case, as structures resembling trees canbe described and generated using very simple rules. The most common wayto generate models of trees is by using L-systems but there have been otherapproaches [Hon71][RB85][Opp86][dREF+88]. These other approaches will notbe described as the generator described in section 4.2, based on L-systems,worked sufficiently well in its current design.

4.1 L-systems

Astrid Lindenmeyer [Lin68] introduced L-systems in 1968, originally as a for-malism to model and simulate the development of simple multicellular organ-isms. Later, it became apparent that L-systems worked well also for generatingmodels of plants for virtual environments.

A simple L-system is defined by its variables, constants, starting point andrules. An example:

Variables: A BConstants: CStart: ARules:A → AB

B → CA

This L-system produces the following output:

Stage 0: AStage 1: AB (since A → AB)Stage 2: ABCA (using A → AB + B → CA)Stage 3: ABCACAB

23


Stage 4: ABCACABCABCAAnd so on...

Methods for plant generation using L-systems have been thoroughly re-searched, starting as early as 1974 in [FL74]. One of those who have done themost extensive research in this field, Prusinkiewicz, was one of the authors be-hind Visual Models of Plant Development [PHHM97], the paper describing thetechniques on which the tree generation in the testing program was based.

Using L-systems, plants are described as a spatial configuration of discreteconstructional units called modules, which develop over time. Typically, thesemodules represent the basic components of the plant, such as flowers and leaves.A simple example of how L-systems can generate models of plants is shown infigure 4.1.

Figure 4.1: A very simple L-system example

Although this method is simple, it is still powerful enough for the creationof highly realistic models of plants. Figure 4.2 displays some three-dimensionalmodels of plants created created using simple L-systems.

L-systems do not actually provide any kind of visual output. Visual outputcomes from the mapping of a string into a visual domain (which is done im-plicitly in figure 4.1). The most common way to do this mapping is by usingturtle interpretation, a interpretation where L-systems provide movement andorientation instructions for an imaginary turtle [PHHM97]. As the turtle movesthrough space it draws lines (or cylinders).

While the notation is very powerful, it is generally far more flexible thanis required in entertainment software. As turtle drawing is also fairly slow,another solution was used.

There are several extensions to the basic L-systems that are relevant to thisthesis. One is parametric L-systems, which admits the passing of arbitrary nu-merical information from parents to children. Another highly relevant extensionis stochastic L-systems which introduces randomness into the otherwise com-pletely deterministic L-systems. Finally, environmentally-sensitive L-systems

24

CHAPTER 4. GENERATION OF TREES

Figure 4.2: Plants generated using simple L-systems

are relevant as they provide an easy way to affect the growth of the tree basedon position and orientation of the individual modules. These extensions (andsome other) are very well described in [PHHM97], and will not be describedany further in this thesis.

4.2 A modular tree generation system

The tree generation is not really a part of GREMM but it was an essential partof the testing system, and was also created with other future applications inmind. The tree generation system is loosely based on L-systems as describedby Prusinkiewicz et. al. in [PHHM97].

The tree generation system was created with the use in entertainment soft-ware as a potential application. Therefore it does not use any kind of descrip-tive formal language for the description of the trees. Instead, the focus was onmaking the tree generation engine highly modular so that some kind of plant-description plugins could be used. While the drawback is less flexibility in thedescription of the plants, the advantages are increased speed and better mod-ularity. The generation process is designed to be fast enough for load-time usein entertainment applications.

The trees are created by use of components. These components are the basicbuilding blocks for the plants. The component types essentially determine thephysical properties of components of that component type, how the component

25


is connected to its parent and where children are connected to the component,including the default orientation of each connection point. For example, thecomponent types displayed in figure 4.3 may be used.

Figure 4.3: A possible setup of component types

As mentioned above, the goal was to make the tree generation process mod-ular. The generation was divided into three separate modules, all of which maybe replaced almost independently of the others. The only restriction is that thenumber of component types should always remain fixed.

• The generator module - contains all the rules that define the positionand orientation of each component.

• The component module - specifies the component types and their in-dividual geometric properties such as length/radius-ratio and the relativesize of the connected children.

• The drawing module - specifies how to draw each component, based onits component type and physical properties. Currently there are no morethan two different drawing modes. All component types except leavesare represented with cylinders of the same colour. Leaves are representedwith green triangles.

The algorithm used to grow the tree, starting with the connection point forthe root, is the following:

function grow(connection point,size,parent):

newtype=selectComponentType(parent)

newpart=create new component of newtype and specified size

connected to connection point

26

CHAPTER 4. GENERATION OF TREES

for every child connection point in newpart

perform a minor random translation of the child

connection point along its parent

orient(child connection point)

if child connection point is on the side

grow(child connection point,size*k1,newpart)

else

grow(child connection point,size*k2,newpart)

The orient step is a very complex operation. The orientation and position ofthe connection point are first set by the default values included in the componentdescription of its parent. Orient performs yaw-, pitch- and roll-operations bya set of rules defined in the generation module. These rules may depend onlocal data such as the orientation and type of the component or its parent, orglobal data such as the direction up or the direction towards the sun. Therules may also depend on random numbers (actually pseudo-random numbers,so that each generated plant can be reproduced given that the same randomseed is used).

As the geometric properties of the tree and its graphical representation areseparate, it is easy to implement different level-of-detail optimizations in thedrawing module. The drawing module accepts a detail value (in the range 0 to1), which modifies the number of triangles used in the implementation (the sizeof the part also affects the number of triangles used in its representation).

4.3 Generation results

Figure 4.4 displays a few models of trees rendered using this generator. Thetrees consist of 8000 to 25000 triangles. All four trees were generated usingalmost the same rule set, with only some minor variations to the parametersincluded. While models with a substantially higher degree of realism havebeen generated, these usually required ten times more triangles making themunsuitable for real-time applications.

27


Figure 4.4: Trees generated using the modular tree generator

28

Chapter 5

Overview of GREMM

Schaufler [Sch95] used a fairly simple algorithm for updating the dynamicallygenerated impostors (section 3.2). That algorithm works very well for mini-mizing the visual impact of using the impostors but as previously stated, thisthesis assumes a situation where real-time rendering without a decrease in visualquality is not possible.

The main improvement over the early work of Schaufler is the resource man-agement in GREMM. The resource GREMM manages is available renderingtime, and it is used to increase the visual quality. GREMM uses the followingalgorithm:

DrawSceneWithImpostors():

calculate importance of the objects in the scene

calculate free rendering time (including previously unused time)

mark all critically important objects and approximate lost time

calculate current scene quality Qold

distribute free rendering time to maximize Qnew −Qold

generate the new impostors

draw all non-critical objects using best available impostor

draw all critically important objects using true rendering

All objects are contained in cylindrical bounding boxes1 (which will some-times be referred to as bounding cylinders). The cylinder is always aligned withthe global upward direction (figure 5.1 displays bounding cylinder of an uprightstanding tree).

Each 3D model is instantiated any number of times (and then referred to asinstances or objects). Objects share both the geometric model and impostorswhich saves resources when rendering forests where the same tree model isplaced on many locations.

1A box bounding an object on all sides.

29


Figure 5.1: Cylindrical bounding box

5.1 Calculating the importance of objects

Determining which parts of the scene that are truly important requires moreinformation than is actually available. The assumption that objects in thecenter of the screen are the most important for the user seems generally truebut the reality could be that the user is actually looking at some object in oneof the corners of the screen.

However, since some kind of assumptions must be made, one can only striveto make them good enough to be true in most cases. The method for importancecalculation is based on these four assumptions:

• Objects with a greater visible size (screen area) on the screen are moreimportant than smaller objects even when displayed at the same positionof the screen. This is displayed in figure 5.2 (darker=more important).

• Objects in the foreground are more important than objects in the back-ground (figure 5.3).

• Objects in the horizontal center of the screen are more important far fromthe horizontal center (figure 5.4).

• When the viewer is translated or rotated the areas that came into viewrecently are more important than those that have been in view for a longtime (figure 5.5, viewer is rotating in direction of arrow).

The mathematical function used to calculate the importance is based onthese assumptions, however, some approximations are made since the calcu-

30

CHAPTER 5. OVERVIEW OF GREMM

Figure 5.2: The impact of apparent size on importance

lation must be performed very rapidly. The function τ which is used for theimportance calculation is defined in equation 5.1.

τ(object, view, secview) = (wp · g(object, view) +

ws · g(object, secview) +

wr · fRND(0, 1))/(wp + ws + wr) (5.1)

The function g, which describes the importance of an object inside a single viewis defined in equation 5.2 for all cases where the object is inside view.

g(object, view) = (ksα + kfdn

d+

kc(FOV − 2 cos−1(vf •u− (u • vu)vu

‖u− (u • vu)vu‖))/FOV )/

(ks + kf + kc) (5.2)

where α is:

α =

hwcr

4d2 tan2(FOV/2)w < d tan(FOV/2) and h < (d/cr) tan(FOV/2)

1 w ≥ d tan(FOV/2) or h ≥ (d/cr) tan(FOV/2)0 if object is outside view

If the object is outside view, then g is defined as:

g(object, view) = 0 (5.3)

The symbols used in equation 5.2 and 5.3 are defined in the following table

31


Figure 5.3: The impact of foreground/background on importance

symbol descriptionfRND(0, 1) Random function giving a value between 0 and 1

wp Weight of the primary viewws Weight of the secondary viewks Weight of size for importancekf Weight of foreground/background for importancekc Weight of horizontal centeringdf distance to the back clipping planedn distance to the front clipping planeh Height of objectcr Screen x/y ratiow Width of object(diameter of bounding cylinder)ms Maximum h*w in scened Distance to objectvf Normalized vector in viewing directionvu Normalized vector pointing up in viewers frame of referenceu Normalized vector towards object

FOV Field-of-view

The function g has three different parts. The first part (with ks) gives theimportance due to apparent size. The second part (with kf ) is a very rough ap-proximation of foreground/background importance only based on the distanceto the object. The last part (with kc) models the importance due to horizontalcentering. The function g does not model the effects of translation and rotation

32


Figure 5.4: The impact of horizontal centering on importance

of the viewer. Instead, that is reflected by the secondary view. The secondaryview is a probable view within a fairly short time. It is calculated, as shown inequation 5.4-5.5 using linear dead reckoning2 on both rotation and translationover a time span of a few frames (which is reflected by the constant k).

If Ψ is such that

viewcurrent = viewprevious + Ψ (5.4)

then

viewsecondary = viewcurrent + k ·Ψ (5.5)

The advantage of using this secondary view is not only that it reflects impor-tance based on viewer rotation and translation. It also introduces the possibilityof rendering impostors of the off-screen objects that will likely be visible soon.To exemplify the need for this, assume a case where the viewer is looking aroundin a scene with complex objects and that the system is fast enough to updateone object each frame while keeping an adequate frame-rate. Using Schaufler’s[Sch95] update algorithm, every time a cluster of objects enters the view, thesystem will slow down noticeably. If, instead, the system can predict the needfor objects before they enter the view a few frames ahead, there will be moretime to render the needed impostors and the frame-rate can be kept more stable.

2Originally a term used by navigators. Blind calculation is used to approximate (guess)

the position and heading.

33


Figure 5.5: The impact of camera translation/rotation on importance

5.2 Approximating rendering cost

There are several possible approaches to approximating the rendering cost of anobject. Funkhouser et. al. [FS93] describes one approach, where the renderingtime needed to render an object is calculated based on the number of pixels3,vertices and triangles in the object and an automatic analysis of the system’srendering speed. The approach has one major drawback, it must analyze eachrendering technique used.

In GREMM a simpler technique is used. The system dynamically learns thetime needed to render an object. Every time a model is rendered, a timer timesthe clock time needed (in more than µs resolution) to render the model. Thenew approximation (ϕnew) for the time needed to render the model is calculatedas displayed in equation 5.6.

ϕnew = (1− k) · ϕold + k · tk ∈ [0, 1] (5.6)

where t is the time measured the last time and k is the learning rate. The impactof distance (the number of pixels required) was ignored since it had little affecton the testing system. The alternative would have been to store the timings ofthe last n times and find a least-square fit of a function to that data (which couldthen have been mixed with the previous fit as above, still using a learning rate).Different LODs are handled as separate models if they are discrete. Should the

3Modern display devices (monitors etc.) are based on a grid of coloured dots. Each such

dot is a pixel.

34


LOD be continuous, then it could be handled by fitting a function as describedabove, or by introducing discrete steps for the approximation.

Compared to the method described in [FS93], this method is generally slower(but not noticeably so when such complex objects as trees are rendered), but ithas the advantage that it dynamically reflects the current speed of the renderingsystem. This is a significant advantage when there are other threads executingin parallel to the graphics system, as is common in entertainment software.

5.3 Measuring visual quality

A useful definition is, for the purpose of measuring visual quality, that visualquality is the absence of errors. The use of impostors introduces errors in thesystem. In GREMM, using dynamically generated impostors, the followingerrors are relevant:

• View direction errors. When the viewer translates sideways in relationto the viewed object, old impostors display the objects from the wrongdirection.

• Perspective errors. When the viewer translates towards or away fromthe object, old impostors display the object with the wrong perspective.

• LOD errors. If the object can be displayed using several levels of detail,lower levels of detail introduce errors.

• Resolution errors. Errors introduced when the impostor is displayedat a resolution higher than it was rendered at.

Lighting errors could also have been relevant but as GREMM uses a method tofake the lighting (section 5.4) that is not a problem.

The quality of the rendered image is expressed by the scene quality functionQ(objects, representations). The quality of each object is determined by thequality function q(object, representation) which is composed by quality aspectfunctions γaspect(object, representation).

Let O be the set of all objects, oj is the object j, r(oj) the representationof object j (that which is drawn to the screen), and i(oj) is the importanceof object j. The scene quality function, for n objects and m quality aspectfunctions, is defined in equation 5.7.

Q(O) =cmin · qmin + cmax · qmax + cmean ·

∑n

j=0i(oj)·q(oj ,r(oj))∑n

j=0i(oj)

cmin + cmax + cmean

qmin = q(x, r(x)) (∃x ∈ O,∀y ∈ O : q(x, r(x)) ≤ q(y, r(y)))

qmax = q(x, r(x)) (∃x ∈ O,∀y ∈ O : q(x, r(x)) ≥ q(y, r(y))) (5.7)

35


q, the quality function for each object is defined in equation 5.8. In equation5.8, wj is the weight of the j:th quality aspect.

q(o, r) =∑m

j=0 wj · γj(o, r)∑mj=0 wj

(5.8)

The quality aspect functions

The quality aspect functions describe the quality of the different aspects of therendering like perspective correctness and resolution. Many of these only applyto impostors, and true rendered objects are always of full quality. Each functionranges from 0.0 to 1.0 with 1.0 being the best possible quality. The functionsshould preferably be as close to linear to the perceived quality as possible.Ideally, 0.9 should be perceived as 90% of the quality of 1.0 and 0.5 should behalf the quality of 1.0. As this is highly subjective care should be taken in thecreation of these functions. Also, these functions are called thousands of timeseach frame, so speed of computation is essential. The quality aspect functionsused in GREMM are the following:

Quality aspect: View direction

Figure 5.6: Error due to changing direction

The view direction is always expressed using the the coordinate system ofthe model as that is the only coordinate system that all instances share. Thatway, the viewing directions can be compared between instances without theneed for further transformations.

A suitable quality aspect function for directional errors is defined in equation5.9.

γviewdir(object, representation) =

1− cos−1(vo•vr)

k if vo • vr > 0 andcos−1(Vo • Vr) < k

0 otherwise(5.9)

36


symbol descriptionvo Current view direction (normalized)vr The view direction (normalized) when the impostor was renderedk A specified maximum error angle

In figure 5.6, the angle marked a is the angle used as a measure of the error.Another possibility would have been to use the length of the section markederror as a measure. Though in many ways a better measure of the error, it isharder to create a good quality aspect function from it.

Quality aspect: View perspective

The cause for errors due to the way the perspective view is affected by distanceis displayed in figure 5.7. As the impostor is flat, any point that is neither

Figure 5.7: Error caused by perspective view

in the impostor plane nor on the centerline (a line from the viewer throughthe center of the impostor) moves around on the impostor as the distance ischanged. Based on the situation in figure 5.7, the error may by calculated asdisplayed in equation 5.10.

error =d1a

d1 − b− d2a

d2 − bd1 ≤ d2 (5.10)

However, on a cylindrical bounding box, neither a nor b is constant and al-though they can be calculated for each distance, this thesis will instead use anapproximation to save calculations. One can safely assume that b < d1 andb < d2, since the impostors are not intended to be used when the viewer is in-side the bounding box. A constant c is defined as the maximum distance fromthe center of the bounding box to any point inside the box so that c ≥ a andc ≥ b for all values of a and b. Then the equation 5.11 can be derived from the

37


equation 5.10:

error ≤ d1c

d1 − c− d2c

d2 − cd1 ≤ d2 (5.11)

Based on equation 5.11 a suitable quality aspect function for the perspectiveerror may then be the one defined in equation 5.12.

γperspective(object, representation) =

{1− | doc

do−c −drc

dr−c |/k | docdo−c −

drcdr−c | < k

0 | docdo−c −

drcdr−c | ≥ k

(5.12)symbol description

do Distance to the impostordr Distance when the impostor was renderedk A specified maximum error

Quality aspect: Levels of detail

The use of several levels of detail is simple to handle. Each LOD must beassigned a quality value (from 0.0 to 1.0) with the best LOD having a qualityvalue of 1.0. This may be done manually, or the quality value (q) could be basedon the resolution (usually the number of triangles) of the model compared withthe most detailed model (which has a quality value of 1.0), as in equation 5.13.

q =res

resmax(5.13)

Based on equation 5.13 the quality aspect function is as defined in 5.14.

γLOD(object, representation) =< quality value used in impostor > (5.14)

Quality aspect: Impostor resolution

The basics for the resolution of the impostor are simple. A texel4 should notbe larger than the pixels of the screen. In one dimension the problem is asdisplayed in figure 5.8.

Equation 5.15 defines ws as the full width of the scene at the position of thetexel.

ws = 2d · tan(FOV/2) (5.15)

The relation in equation 5.16 (where wi is the width of the impostor, ri is theresolution of the impostor, rs is the resolution of the screen and rmax is themaximum available texture resolution) should apply when the resolution of theimpostor is optimal.

ri =rs · wi

ws(5.16)

4A pixel of a texture.

38


Figure 5.8: Impostor resolution

A good measure of quality in one dimension is defined in equation 5.17.

γres1(object, representation) =

{ri/

rs·wiws

ri < rs·wiws

and ri < rmax

1 ri ≥ rs·wiws

or ri ≥ rmax(5.17)

Since the screen is two-dimensional, the square of equation 5.17 is a bettermeasure of the quality which results in the quality aspect function as definedin equation 5.18. That is under the condition that the x/y resolution ratio ofthe impostor is the same as the x/y resolution ratio of the screen (which is thecase in GREMM).

γres(object, representation) =

{(ri/

rs·wiws

)2 ri < rs·wiws

and ri < rmax

1 ri ≥ rs·wiws

or ri ≥ rmax

(5.18)

5.4 Impostor generation

The rendering of the impostor may be a bit tricky to implement but the actualtheory is quite simple. Once there is a situation where an impostor should berendered (figure 5.9), the camera5 settings are stored safely. The settings arerecovered once the impostor has been created.

Then the camera is rotated towards the object so that the object is centered(figure 5.10).

OpenGL only allows for texture sizes that are powers of two (like 256x128or 512x64). For that reason the object probably needs to be either enlarged or

5A virtual eye, which defines the view showed on the screen. Also referred to as a viewer.

39


Figure 5.9: An impostor of the tree will be rendered

made smaller. While it would be possible to always use a larger texture, and ifthat is not possible, fall back to true rendering (as in [Sch95]). That would bea waste of texture memory and would also restrict the use of impostors.

The size of the object should only be changed by increasing or decreasingthe field of view (FOV) used in the rendering, while the distance to the object iskept constant. The reason is that changing the FOV only affects the resolutionand the perspective to the object is constant (figure 5.11).

Equation 5.19 defines the function GREMM uses to calculate a suitable newFOV.

FOVnew = k · FOV · sc

sw(5.19)

symbol descriptionsc Current screen size of the objectsw Wanted screen sizek A constant (slightly over 1) used as a safety margin

Once the FOV is set the object and its bounding box should fit inside thetexture (figure 5.12). The only thing remaining is to render the object and totransfer the rendered image to a texture.

There are several possible methods for transferring the rendered image to atexture. The best is by using pixel-buffers [NVI] which admit rendering directlyinto texture memory. Unfortunately, pixel-buffers are currently only availableas an extension to OpenGL and are not part of the OpenGL 1.3 standard. Forthat reason GREMM currently uses the somewhat slower method of renderinginto the framebuffer6 and copying the required area directly into the texture

6A buffer in which the image displayed on the screen is kept.

40


Figure 5.10: The tree is centered on the screen but does not fit the texture

memory. Not the fastest solution, but still faster than some alternatives.There are two major drawbacks. As impostors require alpha channels, the

framebuffer must include them as well. This usually means that a 32 bit screenmode must be used. Another drawback is that the screen resolution limits thelargest possible impostor size as the screen must fit the entire texture. Using800 times 600 pixels limits the impostors to 512 times 512 texels.

Lighting conditions

To avoid the problems related to changing lighting conditions all impostors aregenerated using a directional light source pointed downward (which is not sucha bad approximation for most outdoor scenes). This ensures that all impostorsare created with equal lighting.

To give some illusion of different lighting directions the normals of the im-postor are slightly tilted towards the sides of the impostor, as if the surface hadbeen rounded (figure 5.14 displays the impostor as seen from above).

5.5 The rendering cache

All rendered impostors are inserted into the rendering cache of the model theybelong to. Before rendering each frame the best available impostor is foundfor each object for potential use in the rendering of the frame. Figure 5.15illustrates this basic role of the rendering cache.

Impostors are stored with information on the rendering conditions (suchas viewing direction). When the most fitting impostor is required, that is theimpostor which maximizes the object quality function (section 5.8).

41


Figure 5.11: Changing the FOV

Limited either by the available texture memory or by the complexity ofsearching the cache, the cache must have an upper limit for the amount ofimpostors it can store. An upper limit implies that impostors must also bediscarded. This is the reason why the cache must maintain information on theusage of each impostor. That information is maintained in a usage table:

this frame last frame historynthis nlast nhistory

The usage table contains information on the number of times that each im-postor has been drawn on the screen. Every time the impostor is drawn, nthis

is incremented by one. Once the frame is completed, the table is updated inthe following way (where k is a constant controlling the rate of decline):

UpdateUsageTable():

nhistory = k · nhistory + nlast

nlast = ncurrent

ncurrent = 0

The usage value of each impostor is calculated as in equation 5.20, where c1, c2

and c3 are constants.

usage = c1ncurrent + c2nlast + c3nhistory (5.20)

42


Figure 5.12: The object and its bounding box fit inside the texture

In a full rendering cache, the impostor with the lowest usage value is re-placed if a new impostor is added. Impostors that may potentially be rendered(impostors that fit some visible object best) are never replaced. If the cacheis full and no impostor can be removed, then some alternative method mustbe used. In GREMM, in such a case, the object is represented with the bestavailable impostor. Recently added impostors are not created with an emptyusage table. It will contain some default values high enough to avoid that theimpostor is removed from the cache before it has built up some usage value.

5.6 Planning the rendering

The idea behind GREMM is that the rendering time should be spent where itbenefits the visual quality the most. This optimization problem requires thatthe rendering of the scene is planned. In GREMM, the first step in that processis to find critically important objects. These are objects which are too impor-tant (their importance is above a threshold) for impostored rendering. The nextstep is the building of a selection table where all the choices available to therendering engine are presented. The table below displays a possible selectiontable. Each row represents an impostor which may potentially be used in thescene.

43


Figure 5.13: The impostor will use this area as a texture

Figure 5.14: Fake shading by tilting the normals

Impostor benefit1 time1 benefit2 time2 benefit3 time3

1 -0.1 0.011 0.12 0.015 0.15 0.0212 0.15 0.011 0.22 0.015 0.35 0.0213 0.05 0.008 0.12 0.0124 0.16 0.012 0.23 0.017 0.28 0.020. . . . . . .. . . . . . .

For each impostor, there are a few benefit-time options. These represent therendering of a new impostor for the object with the greatest need for improve-ment (utilizing the impostor of the row). The different option-levels are basedon the different LODs the impostor may be generated at. The greatest needfor improvement is determined by comparing (1 − quality) · importance. Theobjects with the highest (1 − quality) · importance of each impostor are theobjects which may get new impostors rendered to fit them. The other objectsusing the impostor are all forced to use either the newly rendered impostor orthe currently best one. The benefit of each option is calculated as displayed inequation 5.21.

benefitn = (qold − qnew) · importance (5.21)

44


Figure 5.15: The basic role of the rendering cache

symbol descriptionqold Current quality of the object with the worst fit using the impostorqnew Quality of the object should it get a new impostor using LOD n

Paired with the benefit of a level is time. That is the approximate renderingtime needed to render the impostor at that LOD. The selection table is sortedby the best benefit/time of each line. The distribution of rendering time isdone with a greedy algorithm by always selecting the line and the level withthe best benefit/time. Rendering time is distributed until the best (regardingbenefit/time) of some line cannot be used as there is not enough free renderingtime left. Then the remaining rendering time is saved for the next frame andthe scene is created using the selected choices (as described in the algorithm atthe beginning of this section).

5.7 Object clustering

Figure 5.16: Clustering of trees

GREMM supports the automatic clustering of objects by using the K-meansclustering algorithm:

45


For each of the clusters in C:

randomly set the center.

Loop until termination condition is met:

For each data element:

assign that element to a cluster

such that the Euclidean distance from

this element to the center of that cluster is minimized.

For each cluster:

recalculate the means of the cluster based on

the elements that belong to that cluster.

end loop;

The clusters are currently only used to speed up viewport culling, however,they were intended for faster occlusion culling and cluster-level importance cal-culation for scenes with a higher number of objects.

5.8 Implementation details

GREMM was implemented in C/C++, totalling at about 8000 lines of sourcecode not counting comments in the code. It uses OpenGL 1.3 and SimpleDirectMedia Layer [SDL], making it nearly completely platform independentat a source code level (meaning that it can be compiled for most platforms).GREMM has been tested under both Windows 2000 and Linux 2.2, and itwas equally stable under both (though there where some - so far - unexplainedperformance problems under Linux, possibly due to driver issues).

46

Chapter 6

Performance analysis of

GREMM

The big question is, does GREMM really provide such a significant performanceadvantage that it is worth all the overhead caused by the advanced renderingtechniques?

6.1 The visual quality

Impostors are not expected to look as good as the ”real thing”. There is alwayssome visual impact caused by the use of impostors. The dynamically generatedimpostors in GREMM are no exception. In GREMM, the main impact on thevisual quality is caused by either using impostors that do not show the rightview of the object or by using textures that do not fit the resolution of thescreen.

There are some other errors with a minor impact on the visual quality. Oneis caused by the fake shading. While the shading of the impostor is adequatelyrealistic, the transition from impostor to true rendering causes a noticeablechange in colour. The other minor errors are caused by the flatness of theimpostors. Even if the quality of the impostor is perfect, the boundary betweenthe impostor and the environment might be wrong, for instance causing animpostored tree to appear from the ground in a slightly different place than thetrue rendering. Finally, the perspective in the impostors is only 100% correctfor objects that are centered on the screen. The perspective error is generallynot noticeable but it may be if the field of view is very wide.

Using impostors displaying the wrong view of the object mainly causes pop-ping, since the illusion of smooth transitions between the different views of theobject is lost.

When the texture resolution does not fit the resolution of the screen theresults can be severe pixelation as shown in figure 6.1. In GREMM, aliasingerrors are always present but they are usually hardly noticeable. The most

47


Figure 6.1: Impostor using a texture of the wrong resolution

common way to avoid aliasing is by using mip-mapping, but using that solutionwould make the impostor generation substantially slower. Currently, there areno plans to include any kind of anti-aliasing in GREMM, however, the extremeerror in figure 6.1 could be avoided by simply rendering the impostor at a higherresolution.

Testing the performance of GREMM is not completely simple. The engineis designed to reduce the visual quality to reach a requested frame-rate. Theproblem is that the visual quality must be measured as well as the frame-rate.

In section 5.3, a function was defined to measure the visual quality of thescene. However, for testing purposes it is too complex to be useful and thereforeanother simpler measure of the quality was introduced. Whenever some objectwas represented in two consecutive frames by impostors with an directionalerror (as described in section 5.3) of at least 18 degrees (1/20 of a completecircle) it was defined as an impostor failure. In all tests the impostor failurerate (equation 6.1) was measured.

impostor failure rate = impostor failures/number of impostors displayed(6.1)

Though subjectively, the impostor failure rate was found to be a fairly goodmeasure of the quality. The error rate is fairly constant at about 0,0-0,1 % aslong as the engine updates the scene quickly enough. As soon as it starts torise, visual errors start to appear. Below 0,5 %, the errors are hardly noticable.Between 0,5 and 1,0 % the errors are noticeable and mainly in the form of pop-ping. At above 1 % failure rate, the errors are often severe and quite disturbing.This should be seen as a rule of thumb, as there are irregularities. Sometimes,severe errors may occur even if the failure rate is low (but it is quite rare).

48

CHAPTER 6. PERFORMANCE ANALYSIS OF GREMM

Figure 6.2: A virtual fly-through

6.2 Test setup

The testing system was a 1.33 GHz Athlon Thunderbird, with 256 megabytesof DDR SDRAM, running Windows 2000. The graphics card in the systemwas based on a nVidia Geforce 3 ti200 GPU with 64 megabytes of graphicsmemory. Some background tasks were present but none which should have hadany noticeable effect on the results.

The performance test is a virtual fly-through of a forest scene with a cameradisplayed in a windows of 800 times 600 pixels. The camera flies through thescene on a path like the path in figure 6.2. The camera is elevated 3-8 meters(though virtual meters, these are in relation to the size of the trees) abovethe ground (which is not flat) and constantly moves along the path so no twoframes are created from the same position. The path takes exactly 60 secondsto complete and the movement along it is connected to the system clock andnot to the rendering. The camera rotates independently of its movement, andthe rotations are of different speed, the slowest rotations being of about 10degrees/second and the fastest being of about 270 degrees/second.

Figure 6.3 displays a screenshot of the performance test. As the imageshows, no ground is rendered. The ground exists however, and the elevation ofthe trees is determined by it.

The cache was at all times kept as large as allowed by the size of the graphicsmemory. This generally meant that about 250 impostors would fit in the cache.

6.3 Test results

The first seven tests show how the frame-rate develops when the number ofinstances are increased. The target frame-rate (measured in frames/second -FPS) specifies the frame-rate which the impostoring engine tries to keep. Theseven first tests only use a single tree model, of either 23002 or 4254 triangles.Using a single tree model minimizes the need to render new impostors but

49


Figure 6.3: A screenshot of the performance testing program

also maximizes the overhead. The last test shows how the frame-rate developswith an increased number of unique models (with the total number of instancesremaining constant).

50


10 FPS target with 1 tree model of 23002 triangles

instances true rendering (FPS) impostored (FPS) failure rate (%)20 32,8 30,1 0,140 17,2 14,5 0,380 6,0 9,4 0,1160 2,5 9,9 0,1320 1,3 10,2 1,9

51



instances true rendering (FPS) impostored (FPS) failure rate (%)20 32,7 30,0 0,140 17,2 20,1 0,280 5,9 21,7 0,3160 2,5 22,1 0,1

52




53




54



instances true rendering (FPS) impostored (FPS) failure rate (%)80 26,3 12,4 0,0160 11,0 4,9 0,1320 5,9 5,3 0,0640 3,1 5,7 0,01280 1,6 7,0 0,02560 0,8 4,2 0,1

55



instances true rendering (FPS) impostored (FPS) failure rate (%)80 26,3 12,5 0,0160 11,0 10,7 0,1320 5,9 13,3 0,0640 3,1 15,9 0,11280 1,6 7,7 0,9

56




57


15 FPS target with 640 instances of 8186 triangles in average

unique models true rendering (FPS) impostored (FPS) failure rate (%)1 2,3 11,1 0,02 2,3 12,9 0,04 2,3 14,2 0,08 2,3 15,0 0,016 2,3 19,7 30,0

58


6.4 Analysis

In many cases, the use of the impostoring engine is simply a loss of performanceas well as visual quality. However, in some cases, the results are very promising.Such is the case in the 20 FPS test using the high resolution model. Using 20 or40 instances, there is no or very little gain but at 80 instances the performancegain is about 250%. At 160 instances the gain is 500% with an failure rateof 0,1 %. The results at 20 FPS using the low-resolution models are equallyinteresting. At 640 instances the impostored system is more than four timesfaster, keeping 16 FPS with a low failure rate.

The tests show that a higher target FPS increases the failure rate. To someextent this is expected, since a shorter frame time means that more objects witherrors are ignored each frame. That alone does not completely explain the highfailure rates. The main reason for the rapid rise in failure rate as the targetframe-rate increases is probably a kind of render-time underrun. Criticallyimportant trees are always rendered using true rendering and when the totalrender-time available for each frame is less than the time needed to render thecritical objects, then no new impostors will be generated. This may be so severethat it causes gaps of several seconds in the generation of impostors. A fairlyeasy way to avoid this problem would have been to modify the algorithm so thatthe engine will always generate at least one new impostor each frame regardlessof the available time, since a slight drop in frame-rate is generally preferable tounsatisfactory visual quality.

The test results clearly show that the engine does not hit the target frame-rate very well. The benchmark is created not to restrict the frame-rate (whichthe engine otherwise does by sleeping), so there is nothing strange with resultsthat are above the target frame-rate. However, most results are actually belowthe target frame-rate and that is probably mainly caused by the overhead in-volved in the cache-lookup operations. Currently, the engine does not in anyway compensate for the time lost in these operations. Supporting this is the testvarying the number of models used. The frame-rate increases as the number ofmodels increases (because the caches become smaller). However, at 16 uniquemodels the failure rate suddenly increases to 30% from 0% at 8 models. Thisis because one or more of the caches is too small to fit the needed impostors.A higher number of unique models reduces the overhead, but also reduces thereuse of impostors.

The tests using the low-resolution model had some unexpected results. Inboth the 10 and 20 FPS target frame-rate cases, the performance of the enginewas improved as more instances were added. In the 10 FPS test, the frame-rateincreased by 43% as the number of instances increased from 160 to 1280 andin the 20 FPS test, the increase was 49% as the number of instances increasedfrom 160 to 640. Currently, the only explanation is that this is caused by theincreased number if critical renderings. This reduces the available time which

59


makes the greedy planning terminate faster. Also, critical renderings requireno planning.

Figure 6.4: A forest scene with a total of 1280 trees

Some of the results are promising. Gains in frame-rate of up to 500% couldtranslate into outdoor scenes five times more dense than previously possible.Figure 6.4 displays a screenshot of a fly-through in an extremely dense scene.The forest scene had a total of 1280 trees of 4254 triangles each and it wasdisplayed at 7 FPS. 7 FPS is not good enough for entertainment applications,but the testing system was also far from ”cutting edge”. Also, that particularscene is not wise to use as the trees are not rendered efficiently. Using individualtriangles for each leaf in the tree is not an effective way to display trees. A moreeffective representation using textures could reduce the required complexity ofthe trees substantially, without loosing visual quality.

60

Chapter 7

Drawbacks with GREMM

Nothing is free and higher frame-rates are no exception. The costs for thetechniques used in GREMM are the following:

• Reduced visual quality. As previously mentioned, the visual quality isaffected negatively in several ways. Less frequent updates may cause pop-ping. The simplified shading does not look quite as good as true shading,and the transition between the impostor and the true geometry causesa slightly noticeable change in colour. The resolution of the impostor israrely perfect for the screen, which causes some aliasing. The flat natureof the impostors causes incorrect depth values which may result in incor-rect visibility (a solution to this was proposed by Schaufler [Sch97] butit would require an hardware implementation to be really efficient). Allthese causes for errors combined are not an insignificant impact on thevisual quality.

• Less available graphics memory. The impostors are stored as uncom-pressed textures in the graphics memory. Even if the textures are reducedto a 16 bit colour depth, each 512x512 texture still uses 512 kilobytes ofgraphics memory. Fortunately, most of the impostors are distant andtheir textures smaller. 250 impostors may typically require about 40-60megabytes of memory. On a system with 64 MB:s of graphics memory,that is generally unacceptable.

• Overhead causing an increased CPU load. The task of finding the bestavailable impostor for the visible objects of a certain type is an O(nm)task where n is the number of visible objects of that type and m is thesize of the rendering cache. This should be performed once each frameso it can be a fairly heavy task. In some applications, this might be aproblem if the CPU already is under heavy load of other important tasks(like the AI in entertainment applications).

61


None of these three problems is likely to be solved with improvements to theengine, but some of the improvements discussed in section 8 are likely to reducethe problems.

62

Chapter 8

Future development of the

engine

The development of GREMM does not end with this thesis. It is intended for usein computer games and the development of a game using GREMM has alreadybeen started by Criosphinx Studios. The use of GREMM in game developmentrequires optimization of the source code and simplification of its programminginterface. There are also several new features planned, some which merely im-prove performance and others which add new effects, such as shadows. Thesefeatures are alpha blended impostors, shadows, improved texture management,animation support, dynamic clustering, cluster-based impostors and more effi-cient cache lookup.

8.1 Alpha blended impostors

Alpha blending is the most common technique to avoid popping in the transitionbetween two images. Using alpha blending in the transition between the tex-tured representations would reduce the popping, which is currently the greatestvisual problem in GREMM. The drawback would be that each impostor wouldmake use of several textures causing more texture memory to be used.

Two different options are considered. The first possibility, and easiest, isthat the impostor is blended during the transition based on weights that changewith time. Figure 8.1 displays how the alpha weights could change with time.A transition starts as soon as a new view has been rendered and the old viewmay be discarded once its alpha weight is 0.

Another possibility would be to always create the impostor by the blendingof four sampled views as displayed in figure 8.2. The user is positioned at V

and is looking at the object at O. The impostor of the object is created byblending the views rendered from the positions A, B, C and D which create atetrahedron around the position V . When the viewer exists the tetrahedron,only one new view needs to be rendered (unless it already exists). Also, existing

63


Figure 8.1: Time-based alpha blending for transition

impostors may be refined by simply rendering a new view from the center ofthe existing tetrahedron, resulting in three new tetrahedrons.

Figure 8.2: Alpha blending of sampled views

The second alternative would require major modifications to the existingengine, but it is likely it would be far more effective than the current engine.

8.2 Shadows

Even simple shadows greatly enhance the perceived realism. One interestingapplication for the rendering cache would be the reuse of the data in the cachefor the creation of shadows. This could be by accomplished by the use ofimpostors in the shadow-map rendering, but other faster approaches based on

64

CHAPTER 8. FUTURE DEVELOPMENT OF THE ENGINE

transforms of the data are perceivable.

8.3 Cluster-based impostors

As the number of objects in the scene increases so does the heavy work neededto find the best impostors for these objects. This is the main reason for theuse of cluster-based impostors. If distant objects are treated at a cluster levelinstead of at the individual level, then the number of objects requiring theexpensive cache-lookup is reduced.

Cluster-based impostors should be rendered using the impostors of the ob-jects in the cluster, since rendering each object in the cluster using true ren-dering would likely be too time-consuming. Because of this, all objects in thecluster must have fairly good impostors which should affect the planning stageas objects should receive higher priority if they are part of a cluster needing animpostor.

8.4 Efficient cache lookup

Currently, the rendering cache is implemented as a list. To find the best im-postor, every item in the list is examined and that is simply the worst way tosearch the cache.

Instead, the cache should be implemented as a tree structure branching(based on carefully selected intervals of the variables) first by the most impor-tant quality aspect and last by the least important as in figure 8.3.

Figure 8.3: A rendering cache tree structure

65


8.5 Improved texture management

Using OpenGL, the size of a texture must always be (a, b) where both a and b

must be powers of two (64, 128, 256...). The problem is currently that a lot oftexture area is wasted. There are two good solutions. One is that the image isstretched at rendering to fill the texture completely gaining higher resolutionin one direction.

Another, probably better, solution would be to add a texture managementmodule that could make use of the unused parts of the texture as shown infigure 8.4. Such a module would allow allocation of arbitrary texture sizes atthe cost of increased overhead in texture creation.

Figure 8.4: More efficient texture allocation

8.6 Animation support

GREMM must be extended to allow for impostors of animated objects. Whilesome animated objects are clearly unsuitable for the techniques in the engine,a very suitable situation is the rendering of marching soldiers as seen fromfar away. Each model and pose is very likely to appear several times viewedfrom approximately the same direction. In some ways, the task is easier thanrendering static objects as the popping is less noticeable.

What is needed in GREMM to allow animated objects is a quality aspectfunction (section 5.3) for poses and probably a more efficient rendering cache.

66

CHAPTER 8. FUTURE DEVELOPMENT OF THE ENGINE

8.7 Dynamic K-means clustering

To extend GREMM so that it can handle moving objects, a new clusteringalgorithm is required. This is a proposed extension to the K-means clusteringalgorithm (section 5.7) to allow for clustering of moving objects:

Perform ordinary K-means clustering

Loop until termination condition is met:

Move objects.

For each cluster:

C=set of all clusters within boundary to boundary distance k

from this (including this cluster)

For each data element in cluster:

assign data element to the closest cluster in C

For each cluster:

If cluster is empty

use cluster to split the largest cluster

For each cluster:

recalculate the center of the cluster based on

the elements that belong to that cluster

end loop;

The constant k should be equal to the greatest distance any object maymove in each loop.

67


68

Chapter 9

Concluding remarks

This paper presents the theory involved in a new 3D graphics rendering enginecalled the Graphical Rendering Engine for Massive Multiplicity (GREMM). Ba-sically GREMM is an advanced system for rendering and using dynamicallygenerated impostors. Compared to earlier work the methods this thesis de-scribes are more geared towards maintaining a stable frame-rate while reducingvisual quality. The methods used strive to keep the visually important areasof the screen as correct as possible at the cost of the visual quality in the lessimportant areas.

The goal of the thesis was to present methods that could render verypolygon-rich forest scenes at interactive frame-rates. While the test resultsshow that GREMM is not yet ready for highly demanding interactive enter-tainment applications, the results of up to 500% performance gain encouragefurther work with rendering engines based on dynamically generated impostors.

69


70

Bibliography

[BB02] Wolfgang Heidrich Brook Bakay, Paul Lalonde. Real time animatedgrass. In Proc. Eurographics 2002 (Short Presentations), 2002.

[BMH99] Dirk Bartz, Michael Meißner, and Tobias Huttner. OpenGL-assisted occlusion culling for large polygonal models. Computersand Graphics, 23(5):667–679, 1999.

[DCSD02] Oliver Deussen, Carsten Colditz, Marc Stamminger, and GeorgeDrettakis. Interactive visualization of complex plant ecosystems. InProceedings of the IEEE Visualization Conference, page October.IEEE, 2002.

[dREF+88] P. de Reffye, C. Edelin, J. Francon, M. Jaeger, and C. Puech. Plantmodels faithful to botanical structure and development. In Com-puter Graphics 22, pages 151–158, August 1988.

[FL74] D. Frijters and A. Lindenmeyer. A model for growth and floweringof aster novae-angliae on the basis of table (1,0) l-systems. LectureNotes in Computer Science, 15:24–52, 1974. Springer-Verlag.

[FS93] Thomas A. Funkhouser and Carlo H. Sequin. Adaptive display al-gorithm for interactive frame rates during visualization of complexvirtual environments. Computer Graphics, 27(Annual ConferenceSeries):247–254, 1993.

[GKM93] Ned Greene, Michael Kass, and Gavin Miller. Hierarchical Z-buffervisibility. Computer Graphics, 27(Annual Conference Series):231–238, 1993.

[Hon71] H. Honda. Description of the form of trees by the parameters ofthe tree-like body: Effects of the branching angle and the branchlength on the shape of the tree-like body. Journal of TheoreticalBiology, pages 331–338, 1971.

[Jak00] A. Jakulin. Interactive vegetation rendering with slicing and blend-ing. In A. de Sousa and J.C. Torres, editors, Proc. Eurographics2000 (Short Presentations). Eurographics, August 2000.

71


[Lin68] A. Lindenmayer. Mathematical models for cellular interactions indevelopment, I & II. Journal of Theoretical Biology, 18:280–315,1968.Lindenmayer’s original articles on L-Systems.

[Luc84] Lucasfilm. The adventures of andre and wally b. film, Aug 1984.

[MFAC97] Dana Marshall, Donald S. Fussell, and III A.T. Campbell. Multires-olution rendering of complex botanical scenes. In Wayne Davis,Marilyn Mantei, and Victor Klassen, editors, Graphics Interface,pages 97–104, May 1997.

[MN98] Alexandre Meyer and Fabrice Neyret. Interactive volumetric tex-tures. In George Drettakis and Nelson Max, editors, EurographicsRendering Workshop 1998, pages 157–168, New York City, NY, Jul1998. Eurographics, Springer Wein. ISBN.

[MNP01] Alexandre Meyer, Fabrice Neyret, and Pierre Poulin. Interactiverendering of trees with shading and shadows. In EurographicsWorkshop on Rendering, Jul 2001.

[MS95] P. Maciel and P. Shirley. Visual navigation of large environmentsusing textured clusters. SIGGRAPH Symposium on Interactive 3-DGraphics, pages 95–102, 1995.

[MWW01] G. Marshall, T. Watt, and J. Welsh. Automated generation andrealtime display of forested virtual environments, 2001.

[NVI] NVIDIA. Wgl ext pbuffer. Web page (2/2 2003).http://www.nvidia.com/dev content/nvopenglspecs/-WGL EXT pbuffer.txt.

[Opp86] Peter E. Oppenheimer. Real time design and animation of fractalplants and trees. In Proceedings of the 13th annual conference onComputer graphics and interactive techniques, pages 55–64. ACMPress, 1986.

[PC01] Frank Perbet and Marie-Paule Cani. Animating prairies in real-time. In ACM Interactive 3D Graphics, USA, Mar 2001.

[PHHM97] Przemyslaw Prusinkiewicz, Mark Hammel, Jim Hanan, and RdomırMech. Visual models of plant development. In Handbook of formallanguages, vol. 3: beyond words, pages 535–597. Springer-VerlagNew York, Inc., 1997.

[RB85] W. T. Reeves and R. Blau. Approximate and probabilistic algo-rithms for shading and rendering structured particle systems. Com-puter Graphics, 19:313–322, 1985.

72

BIBLIOGRAPHY

[RCB+02] I. Remolar, M. Chover, O. Belmonte, J. Ribelles, and C. Re-bollo. Real-time tree rendering. Technical report, Departamento deLenguajes y Sistemas Informaticos, Universitat Jaume I, Castellon,Spain, March 2002.

[Ree83] W. T. Reeves. Particle systems - a technique for modeling a class offuzzy objects. ACM Transactions on Graphics, 2(2):91–108, April1983.

[Sch95] G. Schaufler. Dynamically generated impostors. GI Workshop onModeling, Virtual Worlds, Distributed Graphics, Bonn, Germany,1995.

[Sch97] Gernot Schaufler. Nailboards: A rendering primitive for imagecaching in dynamic scenes. In Julie Dorsey and Philipp Slusallek,editors, Eurographics Rendering Workshop 1997, pages 151–162,New York City, NY, 1997. Springer Wien.

[SDL] Simple directmedia layer. Web page (2/2 2003).http://www.libsdl.org.

[SS96] Gernot Schaufler and Wolfgang Sturzlinger. A three dimen-sional image cache for virtual reality. Computer Graphics Forum,15(3):227–236, 1996.

[WP95] Jason Weber and Joseph Penn. Creation and rendering of realistictrees. In Proceedings of the 22nd annual conference on Computergraphics and interactive techniques, pages 119–128. ACM Press,1995.

73

gremm: a real-time graphics engine for forest rendering · the ﬁeld of real-time1 computer...

Documents