3D immersive visual simulation of terrain and water phenomena in Java3D

2008:013

M A S T E R ' S T H E S I S

3D Immersive Visual Simulation of Terrain and Water Phenomena

in Java3D

Alberto del Val Ferrer

Luleå University of Technology Master Thesis, Continuation Courses

Computer Science and Engineering

Department of Computer Science and Electrical Engineering Division of Computer Science

2008:013 - ISSN: 1653-0187 - ISRN: LTU-PB-EX--08/013--SE

3D immersive visual simulation of terrain and water phenomena in

Java3D

Alberto del Val Ferrer

Lule˚ a University of Technology

Dept. of Computer Science and Electrical Engineering

March 7th, 2008

To my family and friends

who made this opportunity possible to me.

R ESUMEN EN ESPA NOL ˜

Autor: Alberto del Val Ferrer Tutor: Matthew J. Thurley

Instituci´ on: Lule˚ a Tekniska Universitet Responsable Erasmus: Christina Hamsch

Lugar y fecha de lectura: Lule˚ a, 7 de marzo de 2008

Simulaci ´ on 3D visual inmersiva de terrenos y fen ´ omenos del agua en Java3D

En la actualidad, los gr´ aficos por ordenador van teniendo cada vez m´ as importancia. Los sectores donde seguramente m´ as demanda tiene esta tecnolog´ıa son los relativos al cine y a los videojuegos.

Java3D es una API de programaci´ on 3D para Java que permite crear aplicaciones y applets con gr´ aficos 3D. Java3D es un lenguaje relativamente nuevo en los gr´ aficos 3D, pero tiene grandes posibilidades de incrementar notablemente su relevancia el sector, apoy´ andose por un lado en las ventajas inherentes a Java y por otro en que permite una ejecuci´ on basada en OpenGL y/o en DirectX (los usuarios de Linux o Solaris s´ olo podr´ an usar OpenGL, pero los de Windows podr´ an usar ambos).

Como resultado, Java3D es un API multiplataforma, software libre (bajo licencia GPL), que no necesita ning´ un tipo de hardware o software adicional para poder ejecutarse correctamente.

i

La ventaja principal de Java3D consiste, por tanto, en que permite dise˜ nar las escenas pensando en objetos geom´ etricos en vez de en tri´ angulos, y en la escena y su composici´ on en vez de en que el c´ odigo sea eficiente desde el punto de vista del renderizado.

Debido a lo anterior, este Proyecto Fin de Carrera tiene como objectivo llevar a cabo una evaluaci´ on de las caracter´ısticas ofrecidas por Java3D, y muy especialmente aqu´ ellas relativas a los sistemas de part´ıculas. Para ello, se presenta la implementaci´ on de una aplicaci´ on para la simulaci´ on de agua usando sistemas de part´ıculas en Java3D.

Dicha aplicaci´ on es capaz, adem´ as, de crear terrenos fractales con par´ ametros aleatorios, permitiendo la ejecuci´ on de operaciones morfol´ ogicas en 3D (erosi´ on, dilataci´ on, apertura, clausura, top-hat blanco, top-hat negro, gradiente, y segmentaci´ on watershed -ver Figuras 3.3 y 3.5 -) y del fen´ omeno de la escorrent´ıa superficial del agua (“water runoff”, en ingl´ es) a trav´ es del terreno generado.

La idea m´ as importante al respecto es conseguir el m´ aximo realismo posible, teniendo siempre en mente el rendimiento como factor indispensable en la implementaci´ on de c´ odigo relativo a gr´ aficos 3D.

Los sistemas de part´ıculas en Java3D pueden ser implementados mediante las subclases de GeometryArray, formando arrays de puntos, l´ıneas, tri´ angulos o quads. Estas clases permiten, adem´ as, aumentar en gran medida la eficiencia del sistema definiendo los par´ ametros de las part´ıculas (posiciones, colores, . . . ) por referencia (usando el bit

‘BY REFERENCE ’), por lo que el objeto GeometryArray no posee estos datos sino referencias a ellos como par´ ametros.

A´ un as´ı, las part´ıculas deben tener un determinado volumen por motivos de realismo y detecci´ on de colisiones, por lo que se utilizan para ello cubos formados por seis quads (clase QuadArray) junto con una imagen como textura del agua, como se puede ver en las Figuras 4.1 y 4.2.

En lo que se refiere a las escorrent´ıas superficiales del agua a trav´ es del terreno, las part´ıculas (o gotas) del sistema deben descender siguiendo las direcciones del gradiente de superficie m´ as negativo, desde el punto de contacto con el terreno hasta alcanzar un m´ınimo, modificando convenientemente los valores de sus componentes de aceleraci´ on, velocidad y posici´ on en cada actualizaci´ on.

Pero el problema surgi´ o al intentar detectar las colisiones de las part´ıculas con el terreno, ya que los m´ etodos proporcionados por Java3D fallan cuando las intersecciones te´ oricas se producen con aristas de alguno de los objetos (tanto externas como internas), por lo que hubo que dise˜ nar un sistema detector de colisiones propio, a pesar de que seguramente ser´ a menos eficiente.

ii

Por un lado, las interacciones part´ıcula-part´ıcula no han podido ser implementadas, puesto que han resultado ser una tarea inabordable debido a su excesiva complejidad, pudiendo ser perfectamente el tema de un Proyecto Fin de Carrera por s´ı misma. Para su realizaci´ on ser´ıa necesario un amplio rango de conocimientos como la teor´ıa de fluidos, presi´ on, viscosidad, etc.

Como resultado, no existe ning´ un tipo de implementaci´ on para detectar colisiones entre part´ıculas, siendo posible, por tanto, que varias part´ıculas ocupen el mismo espacio, de- bido a que s´ olo se podr´ıa evitar esta situaci´ on implementando el comportamiento que define al agua y a las correspondientes part´ıculas que lo componen.

Por otro lado, la formaci´ on de charcos y lagos puede ser vista como una consecuencia directa de la interacci´ on entre part´ıculas, acumuladas en los m´ınimos del terreno. Sin embargo, una posible aproximaci´ on de lo anterior puede consistir en crear una malla a modo de superficie en cada m´ınimo que aumente el nivel con la llegada de nuevas gotas, aunque el rendimiento de la aplicaci´ on se ver´ıa notablemente afectado.

Con esta soluci´ on, y sin tener el cuenta los problemas de rendimiento, ser´ıa posible tambi´ en a˜ nadir efectos (peque˜ nas olas, salpicaduras, reflejos, . . . ) para simular agua en las superficies de los charcos y lagos de una forma m´ as realista.

Durante el desarrollo de este Proyecto, se han encontrado numerosos problemas, con- siguiendo soluciones satisfactorias s´ olo para algunos de ellos, debido principalmente a las limitaciones de Java3D y de tiempo disponible. Dos de los m´ as destacados problemas descubiertos durante la fase de implementaci´ on son los siguientes:

1. Fallos en el sistema de detecci´ on de colisiones de Java3D, como se ha expuesto m´ as arriba.

2. Java3D permite utilizar modelos de sombreado programados por el usuario; sin embargo, el modelo Phong (el m´ as avanzado en cuanto a realismo), usado en los ejemplos oficiales sobre una esfera, parece no funcionar correctamente al aplicarlo sobre los objetos GeometryArray que constituyen los terrenos.

Como conclusi´ on m´ as significativa, parece l´ ogico decir que Java3D tiene cualidades su- ficientes como para ser capaz de tener una mayor relevancia entre las APIs de gr´ aficos 3D m´ as importantes del sector, en un corto o medio plazo de tiempo. No obstante, para poder alcanzar este objetivo ser´ an necesarias muchas m´ as implementaciones de c´ odigo nativo, y as´ı lograr rendimientos elevados (de hecho, ´ esta es una de las prioridades para las pr´ oximas versiones de Java3D), ya que actualmente es todav´ıa demasiado lento para proyectos en los que la velocidad sea una caracter´ıstica fundamental, como es el caso de los sistemas en tiempo real.

iii

Y, con respecto a la posibilidad de a˜ nadir un nuevo paquete para simulaciones de agua al repositorio de la Comunidad de Java3D [1] (c´ odigo procedente de colaboraciones), depender´ a principalmente del an´ alisis final relativo a la utilidad y calidad del c´ odigo desarrollado, comprobando previamente si la web contin´ ua activa, puesto que la ´ ultima actualizaci´ on fue hecha en 2006.

Seguramente haya un gran n´ umero de mejoras y optimizaciones que podr´ıan ser aplicadas al proyecto actual; sin embargo, la mayor´ıa de ellas exceder´ıan por s´ı solas el alcance de este Proyecto Fin de Carrera. Por lo tanto, una peque˜ na relaci´ on de las tareas m´ as destacadas (en t´ erminos de eficiencia y realismo) con posibles ampliaciones del proyecto actual para el futuro ser´ıa:

• Viento interactuando con las part´ıculas en ca´ıda libre, modificando conveniente- mente sus trayectorias.

• Capacidad de uni´ on y divisi´ on de las part´ıculas de agua para formar, respectiva- mente, otras m´ as grandes y m´ as peque˜ nas.

• Permitir elegir entre diferentes tipos de formas para las part´ıculas del agua.

• Implementaci´ on de las interacciones part´ıcula-part´ıcula, simplific´ andolo de alguna forma.

• Implementaci´ on de la formaci´ on progresiva de charcos y lagos.

iv

A BSTRACT

Nowadays, Computer Graphics are more and more in demand, especially, in video games and movies. In this respect, Java3D is a relatively recent 3D programming API for Java, which makes it powerful because of the possibility of taking advantage of Java capabilities: platform independence, portability, etc. Therefore, for this reason, Java3D deserves at least an opportunity to prove its worth.

This Master’s Thesis presents a water simulation using particle systems in Java3D, by means of an application which is able to generate random fractal terrains allowing pro- cesses in their surfaces. This is the case of the water runoff in the direction of the surface negative gradient and the formation of puddles and lakes.

The aim of this project consists in evaluating the Java3D capabilities, from the point of view of particle systems, while trying to improve this aspect by creating a new package for the Code Repository of the Java3D Community [1] which is able to model as realistic water as possible, always having in mind the efficiency as the most important issue.

This document also offers a general overview of Java3D, regarding to its main features and characteristics, and specially to its scene graph structure, while commenting some of its most important classes.

v

P REFACE

This Master’s Thesis has been fulfilled between the months of September 2007 and March 2008 in the Department of Computer Science and Electrical Engineering at Lule˚ a Uni- versity of Technology (LTU).

I would like to thank my supervisor Matthew J. Thurley for offering me this opportunity, and for his assistance, guidance and advice through the work.

Alberto del Val Ferrer

vi

C ONTENTS

Chapter 1: Introduction 4

1.1 Computer Graphics . . . . 4

1.2 Scene graph . . . . 5

1.3 Particle systems . . . . 7

1.4 Water simulation . . . . 9

1.5 Overview of the document . . . . 11

Chapter 2: 3D Programming API: Java3D 13 2.1 Introduction . . . . 13

2.2 Particle systems . . . . 15

2.3 Water simulation . . . . 16

Chapter 3: Test platform 17 3.1 General features . . . . 17

3.2 Terrain filtering . . . . 20

3.3 Watershed segmentation . . . . 22

Chapter 4: Water simulation 26 4.1 Implementation . . . . 26

4.2 Water runoff . . . . 29

4.3 Particle-particle interaction . . . . 36

4.4 Puddles and lakes . . . . 37

Chapter 5: Discussion 38 5.1 General evaluation . . . . 38

5.2 Conclusions . . . . 39

Appendix A:Java3D versus OpenSceneGraph i A.1 Introduction to Java3D . . . . i

A.2 Overview of Java3D . . . . ii

Appendix B:Java3D Tutorial (slides) xiii

Appendix C:Collision detection system: Source code review xxxv

L ^{IST OF} F ^IGURES

1.1 Shadowing optimizations [2] . . . . 8

3.1 “Spatial subdivision” technique . . . . 18

3.2 Fractal grid with different number of iterations . . . . 18

3.3 Example of fractal terrain (512 × 512) . . . . 19

3.4 Different types of height maps . . . . 20

3.5 Simple example: Height map of 5 × 5 (2 iterations) . . . . 21

3.6 3D morphological operations (very simple example) . . . . 21

3.7 3D morphological operations (very simple example): Height values . . . . 22

3.8 3D morphological primary operations (complex example) . . . . 23

3.9 Height map example: Watershed transformation using “rain simulation using pixel arrowing” (eight-connected neighbourhood) . . . . 24

3.10 Watershed lines, right, depending on the input terrain, left (very simple example) . . . . 25

4.1 Water texture . . . . 27

4.2 Box-shaped drops with water texture . . . . 27

4.3 Primitive shapes (boxes and spheres) as drops with water texture . . . . 28

4.4 Case when the Java3D detection system fails . . . . 30

4.5 Terrain following . . . . 32

4.6 X and Z slopes in a triangle . . . . 33

4.7 Inclined plane with friction . . . . 33

4.8 Approximate trajectories for a particle, depending on the inclination angle and the coefficient of friction, with α _z = 45 ^o . . . . 34

4.9 Rainfall and runoff of the water particles (sample images) . . . . 35

4.10 Class diagram of the water package . . . . 36

A.1 Partial Java3D class hierarchy showing subclasses of NodeComponent [3] iii A.2 Java3D scene graph (DAG) [4] . . . . iv

A.3 View object, its component objects, and their interconnection [4] . . . . vi

L ^{IST OF} T ^ABLES

4.1 Average FPS, varying the numbers of particles, depending on the type . 28

4.2 Time to left the terrain, for different values of µ and α _x , with α _z = 45 ^o . 34

A.1 Layers diagram with Java3D . . . . ii

L ^{IST OF} A ^CRONYMS

2D Two dimensions/dimensional 3D Three dimensions/dimensional

ACM Association for Computing Machinery API Application Programming Interface BVHs Bounding Volume Hierarchies CAD Computer Aided Design

CFD Computational Fluid Dynamics

Cg C for Graphics

DAG Directed Acyclic Graph FFT Fast Fourier Transform

FPS Frames Per Second

GLSL OpenGL Shading Language GPL General Public License GPU Graphics Processing Unit JDJ Java Developer’s Journal LOD Level Of Detail

LTU Lule˚ a Tekniska Universitet

OGRE Object Oriented Graphics Engine OpenGL Open Graphics Library

OS Operating System

PHIGS Programmer’s Hierarchical Interactive Graphics System

RGB Red Green Blue

SIGGRAPH Special Interest Group on GRAPHics and Interactive Techniques UPM Universidad Polit´ ecnica de Madrid – Technical University of Madrid VTP Virtual Terrain Project

WS Watershed

C HAPTER 1 Introduction

This chapter shows the relationship among the concepts used in this thesis from a generic point of view. Then, an overview of the rest of the document is presented.

1.1 Computer Graphics

Computer Graphics [5, ch. 1] is a subfield of computer science which, from certain point of view, studies the simulation of the real world using computational techniques.

A possible classification in computer graphics, depending on the studied topic, may be geometry (surfaces), animation (motion), rendering (lights), and imaging (images). All of them have a tight relationship and, thus, they often appear together in computer graphics applications and, obviously, in rendering APIs.

The geometry block studies the representation of 3D objects by approximating their surfaces in order to transform them to the discrete digital world.

The movement and deformation of surfaces is studied by the animation block. As a result of the current improvements in software and hardware, the physical simulation topic is the one with more growth in the last years.

The aim of rendering consists in converting 3D objects (models) into images, which prob- ably constitutes the major subfield in computer graphics. In case of realistic rendering, there are two basic operations, which are transport (describing the light from one place to another) and scattering (interaction between light and surfaces).

4

1.2. Scene graph 5 The most significant results in this sector are published by means of international confer- ences and journals. Special mention deserve the SIGGRAPH and Eurographics confer- ences and the Association for Computing Machinery (ACM) Transactions on Graphics journal.

Digital art, special and visual effects, and video games appear as the main applications of computer graphics.

1.2 Scene graph

By definition, a scene graph [5, ch. 10] is a data structure representing the objects which have to be shown in a certain environment (graphical scene), with the corresponding logical and often spatial distribution of each element. It is commonly used by vector- based graphics editing applications.

If it is possible to represent all the elements of a scene (cameras, lights, materials, ge- ometries, . . . ) as objects, they could be represented as nodes, with or without children nodes depending on the scene complexity, of a scene graph.

Possibly the best consequence of using this kind of structure is the fact that any operation applied to a node automatically propagates its effect to all of its children, recursively.

But there are more advantages in a scene graph:

• Modification: It can describe the scene and then modify only small parts.

• Reuse: It can avoid (re)writing the code to display the hierarchical representation.

• Portability: It can save the scene in a file to reuse it.

By this reason, most of 3D graphics rendering APIs are scene-graph based: PHIGS (first commercial scene graph specification, 1988), JMonkey Engine, Java3D, OGRE, OpenSceneGraph, etcetera.

Nodes can be classified into group nodes and leaf nodes. The first type include transfor-

mations and switch nodes and can have any number of child nodes. The second set of

nodes is formed by those which can be considered ‘rendered’ in some abstract way like

objects, lights, sounds, etc. (terminal nodes).

1.2. Scene graph 6 Then, once the scene has been represented using a tree, it can be rendered by traversing the scene graph, since it provides the hierarchical representation of it.

A traversal consists in, starting in a node, applying the required operation, going down the tree recursively until reaching a leaf node, and then traversing back up the tree. In most of the cases, these operations are updating and rendering, and because of this, it is in this point where scene graphs try to be more efficient. The improvements can be done by reordering the nodes to simplify the traversals; for instance, in 2D scenes, placing the most foreground objects in the leaf nodes of the tree could execute the painter’s algorithm [6, 7]. While rendering, there are two different phases, one to traverse down the tree (PreRender operation) and another to traverse back up the tree (PostRender operation).

Therefore, the graph traversal consists in visiting each node once, displaying the part associated to it, and applying the corresponding transformation matrix to that part.

And so, there is a transformation associated to each node, defining rotation, translation and scale, represented by a matrix.

Regarding to the implementation of the scene graph, the simplest case would use an array or linked list as data structure, but this can be valid only if the scene is small enough.

Otherwise, the most used data structure is the tree, allowing to create complex scenes as hierarchical representations of nodes quite easily.

The next improvement of the scene graph is the directed acyclic graph (DAG), being more efficient than the tree. DAGs are directed graphs with no directed cycles, which means that there are not non-trivial solutions to find a path starting and ending in the same node. These graphs allow to share objects and states across multiple locations in the tree, due to their multiparent property.

The bounding volume hierarchies (BVHs) are spatial structures used to do some hard tasks, like culling and speeding up collision detection between objects in the scene. This structure is a tree of bounding volumes, like spheres or bounding boxes, with smaller ones at the bottom and bigger ones at the top (root’s bounding volume contains all the volumes in the tree, forming the scene), and this means that if an object’s bounding volume does not intersect a volume higher in the tree then it cannot intersect any object below that node, simplifying notably the task.

A BVH can be added to a scene graph, by associating a bounding volume to each node,

allowing to make simpler many of the calculations in the represented scene.

1.3. Particle systems 7

1.3 Particle systems

The first particle system was created by William Reeves, in 1983. He had to simulate a planetary creation effect, which was called the Genesis effect, in Star Trek II: The Wrath of Khan. Reeves defined a particle system as:

“. . . one defined by clouds of primitive particles or points in three dimensions.

These particles change and move with time making a particle system dynamic.

How a particle changes or moves is based on a controlled stochastic process giving it a natural look. How particles evolve in a particle system is called the particle life cycle” [8].

Each element in this particle system had eight attributes: position, velocity, colour, lifetime, age, shape, size and transparency.

The objective of a particle system consists in creating irregular or fuzzy phenomena like clouds, smoke, fireworks, snow, hair, grass. . . and even water. These elements are very hard to reproduce using the conventional rendering techniques since they require intensive computation.

Ideally, a particle system is composed by an emitter, where every particle is created with its own characteristic parameters (initial position, velocity, acceleration, colour, and/or any other attributes), which will do more interesting and even realistic the effect as more truly stochastic is the process. Then, during the lifecycle of the particles, they are exposed to the influence of external forces, which modify some of the defined parameters. And, finally, each particle is destroyed when its lifetime finishes, or when it has left the region of interest, or any other mechanism designed to do that function. Moreover, depending on the type of system, dead particles can be created again in the emitter (infinite systems), or they can simply be deleted (finite systems).

The stochastic behaviour is usually developed by adding a random value to the default one of each parameter which should not be the same in every particle in the system.

Two years later, in 1985, Reeves created a different type of particle system, based on the first one. It was used to model trees in the animated short movie The Adventures of Andre and Wally B. [2]. Each tree was composed by a particle system, and the position of all of them in the forest was controlled by another particle system.

He used small circles to represent leaves and lines to represent branches; however, shad- ows and lighting effects were computationally too expensive, so he had to make some optimizations:

• Due to the self shadowing of each tree, particles on the outside of the tree were

more illuminated than the points on the inside.

1.3. Particle systems 8

• Ambient lighting was used, but in a simplified way, since the ambient component for the particles dropped off exponentially as the distance into the tree increased, with a minimum value (see Figure 1.1-a).

• Finally, considering the shadows from neighboring trees, the process consisted of tracing a line from the top of each neighboring tree to the light source, being not shadowed particles above the line and having a change of being in shadow (proportional to the distance) in points below (see Figure 1.1-b).

(a) Ambient lighting (b) External shadowing

Figure 1.1: Shadowing optimizations [2]

Moreover, the shadows on the ground should be approximated, therefore an image of the trees from a viewpoint on the ground was rendered (adding a suitable texture).

The final rendering technique was based on the painter’s algorithm, and the main mod- ification was that there was no need to make an exhaustive sort all the particles, since they were placed in a number of depth sorted bins. This approximation was valid due to the huge number of particles.

It was possible to find a third kind of particle system, which was used to model flocking birds. It was designed by Craig Reynolds [9], in 1987, and he called the particles ‘boids’.

The most remarkable differences with the particle systems designed by Reeves were:

• Each boid was an entire polygonal object (rather than a primitive).

• Each boid had a local coordinate system.

• There was a fixed number of boids, which meant that they were neither created

nor destroyed.

1.4. Water simulation 9

• The number of boids was small enough so that traditional rendering methods could be used.

• The behaviour of each boid depended on what other boids were doing.

Reynolds established three requirements of a boid: Collision avoidance (with other boids or obstacles), velocity matching among neighboring boids, and flock centering (each one close to nearby flockmates).

The official website [10] contains examples and explanations with applets, images, and much more information with references to software, online resources, articles and projects.

1.4 Water simulation

During the last two decades, the importance of the physics based animations is growing in an almost incredible way in computer graphics, specially the real-time simulations in movies (Titanic, The Day After Tomorrow, Waterworld, . . . ), games (Myst, and adven- tures in general) and commercials, among others. Water simulation is clearly one of the most interesting challenges for the computer graphics world.

At the present time, there are many non-real-time tools for simulating water in all its different types. Nevertheless, at the same time, there are not many techniques being able to simulate realistic real-time water. Obviously, the reason about this is known by everyone: performance.

It could be possible to differentiate between two parts: the rendering technique and the optic effects.

The idea of simulating water can seem not so hard (maybe not), however, nowadays it is necessary to find the balance between obtaining realistic results and performance. In other words, it is very difficult to calculate a really big amount of data twenty five times per second (as minimum, probably better thirty, so that the changes of images -frames- are not detected by the human eye), even now that hardware and processing ability are improving so much that computers are able to manage more and more information quickly.

Simulations, in the most basic case, are created by means of grids of points with different

heights, constituting irregular surfaces formed by quads or triangles. But this technique

offers poor results, from the point of view of the realism.

1.4. Water simulation 10 A straight improvement of this is the approximation of using columns connected by pipes [11], which means that variations in the height of a point in the grid will mod- ify the ones around it (volume model with eight-connected neighbourhoods); although, however, some optimizations can be done, like reducing memory footprint by avoiding redundant pipes between columns of water, parallel implementation by removing output dependency on the shared data, and a single height field representing both terrain and water surface [12], although the water volume model keeps on suffering from vertical isotropy due to the column based system, and the calculation time step must be small enough in order to avoid instability and oscillations in the system.

Among others, the most outstanding solutions employing simplified models are mainly two. On the one hand, there are some using the shallow water equations, as Kass and Miller or Stoker [13, 14] expose, where wave velocity is proportional to the square root of the depth of the water in the height field, resulting a tridiagonal linear system for each row and column of the height field per frame. And, on the other hand, there are others representing water surface by means of the Gerstner model of waves, where particles of water describe circular or elliptical stationary orbits, as Fournier and Reeves [15] propose to model the ocean surface allowing waves where the disturbing force is from the wind and the restoring force from gravity.

Some of the approaches are also based on the 2D and 3D Navier-Stokes equations, de- scribing the motion of fluid substances. Chen [16] solves the 2D equations using a CFD method, mapping the surface into 3D using the corresponding pressures in the fluid flow field, and achieving realistic real-time fluid surface behaviours by employing the physical laws of fluids instead of 3D fluid dynamics computations. And Foster and Metaxas [17]

solve the 3D case by discretizing both the equations and the environment to be mod- elled, determining velocity and pressure fields within the liquid, and using a height field equation to track the position of a free surface.

The newest methods are based on the Fast Fourier Transform (FFT), which is a rapid method of evaluating sums, and they are used to produce realistic tilable wave height fields [18], being their best characteristic the scalability, what means that they can be used for high quality water animations and real-time applications.

And the other remarkable alternative to simulate water consists in using particle systems.

This way is being used more and more each day, mainly due to it gives a higher level of

control, since it allows to modify several parameters for each particle in the system (not

only the height, as it happens in the points of a grid), being able to create much more

effects in order to get realism.

1.5. Overview of the document 11 In the optic effects, ray-tracing and reverse ray-tracing are very commonly used methods.

This can be seen, for example, in commercial products like Autodesk 3ds Max [19].

There are a lot of projects working on this, at the beginning by universities around the whole world, but now many companies and even independent programmers are joining to research on this area. One might choose some of these references:

• The Virtual Terrain Project (VTP) presents a list of projects of water rendering and simulation [20]. As a significant detail, it is possible to see that some of the best results are obtained by projects using GPU computation [21].

• 2D water simulation using Java [22]: Water ripples are created on a background image as the mouse moves over it.

• 2D water Java applet offered by Vovoid Software & Multimedia [23], allowing to include easily this water effect in a website, and with or without mouse interaction.

• 3D water simulation from the Georgia Institute of Technology (GVU) [24], with the possibility of downloading videos of the simulations (project of O’Brien and Hodgins [11]).

1.5 Overview of the document

After this introduction, in Chapter 2, the justification of the choice of Java3D as program- ming API, besides a study relative to its features and capabilities, is presented. Special emphasis is done in the topics of “Particle systems” and “Water simulation” referred to Java3D, regarding to the objectives which are expected to be reached in this thesis.

The test platform developed to verify the Java3D capabilities and to show the results of this thesis work is described in Chapter 3. This chapter focuses on the implemented functions of the application, which allow to apply morphological image processing oper- ations to a 3D fractal terrain, and special attention is paid to the 3D surface watershed segmentation operation.

Chapter 4 analyses the implementation of a water simulation using particle systems. The platform presented before is the environment to test this water simulation.

Finally, Chapter 5 briefly discusses the results, and so, the possibility of adding a new

package to the Java3D Community [25] with the water simulation, presenting some con-

clusions.

1.5. Overview of the document 12 In Appendix A an analysis of the Java3D features and characteristics, together with its structure and the most important operations, is performed.

And, complementing the previous analysis, Appendix B is a Java3D tutorial using slides.

At the end, relevant fragments of source code corresponding to the designed collision

detection system in the application are shown in Appendix C.

C HAPTER 2 3D Programming API: Java3D

This chapter presents an overview of the Java3D features and characteristics, which justifies the choice of using it, and a valuation of its capabilities oriented to use particle systems to simulate water.

2.1 Introduction

The decision of using Java3D as programming language in this thesis is justified by many of its characteristics and more representative features, which are exposed below.

Java3D is a cross-platform low level 3D scene-graph based programming API for Java which is able to use hardware acceleration, based on the underlying graphics architecture of the OS. In other words, only OpenGL is available for Linux, Mac OS X or Solaris; and Windows machines have the option of either OpenGL or DirectX.

Java3D requires neither special Java or Java3D drivers nor direct hardware device driver support like the other APIs, because it can rely on the underlying OS. As a result, it is very efficient with resources, performing optimization of rendering, although the 3D graphics speed depends on the graphics hardware.

Java3D is freely available from Sun’s webpage, together with a quite good documentation.

To get high performance, next implementations of Java3D are supposed to have much more native optimizations. So, if the performance is not a problem then portability and low development cost should be the main arguments to choose it for graphics applications.

13

2.1. Introduction 14 Java3D provides an object oriented abstraction around the underlying graphics archi- tecture of the OS, and “allows the programmer to think about geometric objects rather than about triangles and about the scene and its composition rather than about how to write the rendering code for efficiently displaying the scene” ¹ .

The Java3D scene graph is structured as a tree with nodes, whose only possible connection is parent-child, that is to say, a node may have many children (or none), but only a single parent. There are two basic types of Node objects, one for general purpose grouping nodes (Group objects), and other for those containing the definitions of shapes, lights, fog, sounds, etc. (Leaf objects). The scene graph does not contain cycles, therefore, it belongs to the Directed Acyclic Graphs (DAGs).

Regarding to one of the main advantages of scene-graph based APIs such as instancing, Java3D provides two different ways for reusing nodes or branches. One consists in shar- ing a common subgraph by multiple scene graphs, which can be done by means of Link leaf nodes referring (without incorporating the shared scene graph directly into the scene graph) to a single associated SharedGroup node, serving as the root of the shared sub- graph. The second one, when the objective is not sharing completely the subgraph, is the cloning of the node hierarchy of a common subgraph, while still sharing large component objects such as geometry and texture objects.

The Java3D tree can be divided into two well-differentiated branches: view and content (also known as ‘world’). Every subgraph in the tree (BranchGroup objects) can be compiled as a unit, shared or even cloned. The aim of this compilation in BranchGroup objects consists in making certain kinds of the scene graphs render much faster, by taking into account the operations of attribute sorting (replacing redundant appearances with references to unique ones), shape merging, and the capabilities set on the nodes of the branch.

For instance, one might have just one node, a Shape3D object, whose Appearance makes it invisible, so, in this case, after compiling and, depending on if the flag allowing the Appearance to be written in the Shape3D has been set, the renderer might not have to check up each time to make sure it is still invisible, being necessary only for collision detection and picking.

Animations in Java3D use Behavior objects and classes known as interpolators, with Alpha objects controlling them with respect to timing. The Interpolator objects manip- ulate parameters of a scene graph object to create a time-based animation, being able to change its location, orientation, size, colour or transparency in a predefined way.

1

Java3D API Specification, Chapter 1, “Introduction to Java3D”.

2.2. Particle systems 15 Other features are support for collision detection, picking and spatial sound, besides applets and integration of CAD applications with the Internet.

(See Appendix A for more information)

2.2 Particle systems

Java3D allows to create particle systems by several ways. One might think up a set of Shape3D objects modified somehow by using the animation mechanisms provided by Java3D, applied to them one by one; however, it is impracticable for large system in terms of performance.

Therefore, in order to get efficient particle systems, Java3D supplies the GeometryArray class with its subclasses, depending on the type of element (particle) forming the array:

points, lines, triangles or quads. But, in the common use of this classes, this keeps on being impracticable for large systems, due to the enormous amount of data to be copied (in the GeometryArray object) each time that any particle changes.

Thus, the solution enabled by Java3D is the possibility of creating the GeometryArray objects with parameters (arrays with the coordinates, colours, . . . ) setting a flag called BY REFERENCE, which means that instead of copying the arrays of data as it is com- monly done with attributes in Java, references to these data structures (stored in the user’s execution space) are copied.

In this way, to modify the particle system, the only thing to do is to use the Geome- tryUpdater class to carry out the update synchronously, together with a Behavior object requesting the update to it periodically.

The Java3D Community has a set of packages from contributors [1] relative to geometry, terrain, loaders, etc. There is a particle system package which is included into the geometry one and offers emitters, functions and managers to create particle systems easily. It has even a class to model a directional wind source, but there are not predefined classes supplying water particle systems, which could be really useful for users.

The only problem of this repository (in fact, the whole website) is the fact that it seems

to be outdated, since the last changes were made in 2006, and their set of examples do

not work with the last version of their repository.

2.3. Water simulation 16 Among others, the best free tutorials about Java3D particle systems on the Internet are:

• Article from JDJ with the bases to build a particle system for Java3D, by Mike Jacobs [26].

• From the website of the book “Killer Game Programming in Java”, by Andrew Davison [27].

2.3 Water simulation

As it has been said above, in order to get an efficient large particle system, it has to be done with a GeometryArray object using BY REFERENCE attributes.

Then, if the particle system aims to simulate water, trying to be realistic, the number of particles forming the system must be really high. Thus, the only way to do the particle system as efficient as possible is using this option.

However, it is not all advantages, since the collateral effect of this solution is the limitation of using arrays of points, lines, triangles or quads. As a result, any other (more complex) type of particle will be possible only from associations of particles of the same primary type, that is to say, a box particle could be obtained by placing six quad particles in the right way, although using even more complicated structures as particles is not recommended (as it is the case of spheres) since it would decrease the efficiency besides of breaking the implicit condition of particle systems about that particles should be as simple as possible (primitives).

Each particle in the system should move on irregular surfaces in the right way. More specifically, every drop should ‘slide’ in the direction of the most negative gradient of the surface around it, what is called water runoff.

Another feature for realistic water, which is not needed in most of the common particle

systems like, for instance, fog, fire or smoke, is the fact that there must be some kind

of particle-particle interaction of drops in order to get realistic effects. Therefore, the

formation of puddles and lakes is basically the outcome of accumulating large amounts of

particles around a local or regional minimum in the surface, since water droplets occupy

a finite space that another droplet cannot occupy and the collisions among them (mainly,

gravity and drag) should generate a subset of particles with a flatten pseudo-face on the

top and filling the space between it and the surface.

C HAPTER 3 Test platform

The application developed to verify the Java3D capabilities and to show the results of this thesis work is described in this chapter, paying special attention to the 3D-surface mathematical morphology image processing operations and even more to the watershed segmentation implemented on it.

3.1 General features

The application was initially developed in order to learn Java3D in a practical way and to find out both capabilities and limitations, although it was finally reused as the platform of testing for the water simulation.

First of all, random grid-based terrains can be created, by means of a fractal terrain generator. By definition, a fractal is a semi-geometric object whose basic structure is re- peated on different scales, and so, a fractal terrain consists basically in a two-dimensional form of the fractal coastline.

Nowadays, there are many methods to generate fractal landscapes, and the Java3D Com- munity [1] provides a set of classes to create terrains in this way. In this case, it is used the standard fractal method of subdivision and vertex perturbation (“spatial subdivision”

technique). Some parts of the code from the Java3D Community have been modified be- cause of the requirements of the application, although the implemented algorithm [28]

continues being the same.

17

3.1. General features 18 This algorithm is composed by these steps (see Figure 3.1 ):

1. Split the initial square up into a 2 × 2 grid.

2. Vertically perturb each one of the five new vertices (intersection points) by a random value.

3. Repeat this process for each new square decreasing the pertubation each iteration, as Figure 3.2 illustrates.

Figure 3.1: “Spatial subdivision” technique

(a) 2 × 2 grid (1 iteration) (b) 4 × 4 grid (2 iterations) (c) 8 × 8 grid (3 iterations) Figure 3.2: Fractal grid with different number of iterations

Many parameters can be selected in the generator, allowing to customize the general characteristics of the fractal terrains.

Therefore, the result in the application after applying colours to each vertex in the grid, which depends on its height, can be like Figure 3.3 shows.

Moreover, these terrains will support morphological image processing operations, as it is

exposed in the next sections.

3.1. General features 19

Figure 3.3: Example of fractal terrain (512 × 512)

Then, the program provides user interaction by allowing to change the position, orien- tation or distance of the camera (translation, rotation and scale) and modifying some other parameters in the application, like the terrain properties (above all, colours or transparency) or the render mode (faces, wireframe or points).

Users can also take images of the current view of the program and even record videos,

and it makes available a possibility of loading and saving the current terrain from/to

a file by two different ways, one by using the Java serialization feature to save all the

parameters used to create the terrain, and the other by converting the terrain, seen as a

height map, to its equivalent height map image and saving it to an image file, allowing

the load of height map images to regenerate its equivalent terrain by the reverse process

too. Figure 3.4 shows an example of a terrain with its corresponding height map image.

3.2. Terrain filtering 20

(a) Terrain (height map) (b) Height map image

Figure 3.4: Different types of height maps

There are also some operations performed together with animations. This is the case of the ones presented in the next two sections and the morphing operation, performing an animation by interpolating two different terrains.

3.2 Terrain filtering

The two primary morphological image processing operations [29] are erosion and dilation.

Erosion removes small anomalies by subtracting objects with a radius smaller than the structuring element, which can be interpreted as filtering mask. And dilation fills in holes and broken areas, connecting areas that are separated by spaces smaller than the size of the structuring element. Erosion and dilation of set A (input image) by B (structuring element) are denoted, respectively, by:

Erosion: A B = {x : B _x ⊆ A}

Dilation: A ⊕ B = {x : ( ˘ B) x ∩ A 6= ∅}

where ( ˘ B) _x denotes the reflection of B with respect to its origin.

There are two secondary operations: opening (dilation on the eroded terrain) and closing

(erosion on the dilated terrain). Then, there are also derived operations, like opening

top-hat or white top-hat (original minus opening) and closing top-hat or black top-hat

(closing minus original). Finally, the morphological gradient is defined by dilation minus

erosion.

3.2. Terrain filtering 21 In order to clarify the meaning of all these operations, the following example shows their results in Figure 3.6 (with the corresponding height maps in Figure 3.7 ), by means of a simple height map such as the one in Figure 3.5 and using as structuring element a sphere whose radius is 1.5 grid units, in order to cover all the neighbours of each point (from 3 for the ones in corners, to 8 for the central ones), as Figure 3.5-b and Figure 3.6-a illustrate.

(a) Height values (b) Structuring ele- ment (sphere)

(c) Grid representation

Figure 3.5: Simple example: Height map of 5 × 5 (2 iterations)

(a) Original terrain (b) Eroded terrain (c) Dilated terrain

(d) Opening (e) Closing

(f) Opening top-hat (g) Closing top-hat (h) Gradient

Figure 3.6: 3D morphological operations (very simple example)

3.3. Watershed segmentation 22

(a) Eroded terrain (b) Dilated terrain

(c) Opening (d) Closing

(e) Opening top-hat (f) Closing top-hat (g) Gradient

Figure 3.7: 3D morphological operations (very simple example): Height values

Finally, the two primary operations are also illustrated with a much more complex ex- ample in Figure 3.8, where the structuring element can be seen in the original terrain (little red sphere at the top right corner).

3.3 Watershed segmentation

The watershed is a morphological segmentation. There are many watershed algorithms,

but in relation to the 3D operation (i.e., to the terrain in this case), maybe the most

intuitive definition consists in simulating a progressive flood from below through holes

punched in the marker regions, where the watershed lines are the dams created when

water from different markers touch, showing the catchment basins assotiated to each one

[30]. The classical watershed is based on the last definition, placing markers at all the

regional minima, which usually leads to the oversegmentation problem due to the large

number of regional minima present in digitalized images (2D or 3D) [31].

3.3. Watershed segmentation 23

(a) Original terrain

(b) Eroded terrain (c) Dilated terrain

Figure 3.8: 3D morphological primary operations (complex example)

Another possible method to calculate the watershed transform is by means of rain simu-

lation using pixel arrowing [32]. The implementation in this case is easier than flooding

as it is shown below, which explains why it has been chosen in the application.

3.3. Watershed segmentation 24 In order to determine the catchment basins, and so the watershed lines, one has to know that every point have to belong to only one basin. Since a catchment basin is formed by a regional minimum and all those points whose steepest descending paths finish there, and once all the regional minima have been identified, using an eight-connected neighbourhood, the way to perform this operation for each point is to choose the lowest point around it until reaching to a regional minimum, repeating the same process for all the points except for those which has been already included in some previous path (see Figure 3.9-b).

(a) Order of checking (b) Catchment basins (minima surrounded with a circle)

Figure 3.9: Height map example: Watershed transformation using “rain simulation using pixel arrowing” (eight-connected neighbourhood)

When a point has more than one steepest descending path, the criterion in the application is to choose the first one according to the order shown in Figure 3.9-a. And, finally, when the current point is located in a flat region which is not a regional minimum, the decision is the same chosen in the previous case, that is to say, it is tried to find the next descending point by following the already mentioned order, recursively.

As in the previous section, a simple example is shown in Figure 3.10 to illustrate the

result of applying this operation. The same height map is also used (see Figure 3.5 ).

3.3. Watershed segmentation 25

(a) Original terrain

(b) Closing top-hat (c) WS basins (closing top- hat)

(d) Gradient (e) WS basins (gradient) Figure 3.10: Watershed lines, right, depending on the input terrain, left (very simple example)

It is possible to appreciate differences between the watershed lines from closing top-hat

and gradient. One of the reasons is the small number of points in the grid, which means

bigger spaces among them, increasing the error due to digital noise. However, despite of

this, the results are quite correct since both figures show the edges of the three regions.

C HAPTER 4 Water simulation

This chapter comments the implementation of a particle system to simulate water, re- marking its main features besides the encountered problems and their corresponding achieved solutions.

4.1 Implementation

In Chapter 2, it was explained the best way of using particle systems in Java3D, and the fact that the Java3D Community has neither an updated particle system package nor classes to create water directly.

Therefore, the objective at this point is to create a particle system allowing to simulate water while trying to do it as realistic as possible. As a result, the implemented particle system uses a GeometryArray class with the parameters (like position, among others) passed through their reference (‘BY REFERENCE ’ feature). In a simplified way, the GeometryArray subclasses are arrays of points, lines, triangles or quads, forming the particle system; however, there are inconvenients which do not permit to use them since the outcome is not realistic enough in these cases: on the one hand, the PointArray and LineArray classes have fixed sizes (in pixels) to represent the thickness of their elements which is not compatible neither with zooming the view nor with volume issues (i.e., collisions), and, on the other hand, the TriangleArray and QuadArray classes have the same last problem because of their elements have no volume neither and from some particular angle might be not seen when their normals are perpe ndicular to the camera direction.

26

4.1. Implementation 27 Then, the particles should have volume, however there is no such class provided by Java3D as GeometryArray due to performance issues, thus, the solution is to create the desired volumetric particles by using some of its subclasses. Probably the most efficient volume regarding to collision detection is the box, which can be created by using the QuadArray class and placing six quads in the adequate position.

Figure 4.1: Water texture This solution should be simple enough to avoid excessive per-

formance problems, since the complexity of each particle is not too high. Nevertheless, the realism of box-shaped drops of water may be more than debatable, so something needs to be done and it has to be computationally inexpensive. There- fore, a very efficient way to solve this consists in associating a single transparent rounded image as texture (see Figure 4.1 )

to every face (quad) of the boxes, using the MODULATE flag to mix the texture and the material colour. This approximation gives feeling of spherical particles whenever either the distance observer-to-particle is large or the particle is small enough, as Figure 4.2 illustrates.

(a) A close view of a drop (clearly a box) (b) View of little droplets from the dis- tance (spheres?)

Figure 4.2: Box-shaped drops with water texture

The choice of applying the box-shaped approach with a GeometryArray can be compared with the case of using Java3D primitives to represent each particle, either by means of Box or Sphere objects. In this situation, each particle would use a separate TransformGroup and Shape3D pair, being very simple to understand, but not scalable at all.

From a closer view, the Sphere primitive objects (using 64 polygons) get the best ap-

pearance and there is no difference between boxes built with a QuadArray or with the

corresponding Box primitive, as it was expected. However, from a further view, the re-

sults seem to be quite similar, being very difficult to appreciate differences among these

three cases. This is illustrated in Figure 4.3.

4.1. Implementation 28

(a) Close view of a drop (box) (b) Close view of a drop (sphere)

(c) Distant view of little boxes as droplets

(d) Distant view of little spheres as droplets

Figure 4.3: Primitive shapes (boxes and spheres) as drops with water texture

In order to get more precise data, a timed comparison among the boxes built with a QuadArray object and the Box and Sphere primitives for different numbers of particles is shown in Table 4.1.

Boxes Box Sphere

from QuadArray primitives primitives

Num b er of particles

100 154 88 24

200 140 50 12

500 109 21 5

1000 79 10 2

5000 26 2 1

10000 15 1 0

50000 3 0 *

100000 1 * *

* Computer not responding

Table 4.1: Average FPS, varying the numbers of particles, depending on the type

4.2. Water runoff 29 The averages were for five runs of the application, being performed on a Pentium M PC (1.73 GHz, 512 MB RAM, JDK 1.6.0 VM, Java3D 1.5.1), with a Mobile Intel 915GM/GMS, 910GLM Express Chipset Family display adapter, under Windows XP.

These results were reported by FRAPS [33] and they permit to definitely justify the choice of boxes from a QuadArray object, since it is clear that large particle systems are not practicable if they are composed by primitive objects when executed by end users with normal computers.

So, at this point, what is left to design is the behaviour of each particle, acting as similar as possible like real drops of water. In this issue, that means the fulfilment of the principles of water flow across the terrain which are commented in the next sections.

To do that, the application exposed in Chapter 3 is used. However, another problem appeared while trying to make the terrains more realistic, by means of the ‘programmable shaders’ Java3D feature to use Phong instead of Gouraud (default). Phong shading is computationally more expensive, but it produces much more better results for specular reflection and, so, increasing the realism of the scene.

Java3D supports both OpenGL’s GLSL (default) and NVIDIA’s Cg programmable shader languages, allowing programmers to create their own shaders; but the problem is that the Phong shader designed for the official Java3D examples does not work properly in the GeometryArray object, although it does with Sphere objects and with other shaders provided in the same set of examples. It could be surely due to the fact that the shader package is quite new in Java3D (since Java3D 1.4) and even it has some classes not im- plemented yet, as it is said in the javadoc of the ShaderAttributeBinding class. Moreover, these shader languages are not fully supported by all the graphics cards, so, applications using this option will not be able to work in those cases.

4.2 Water runoff

In order to carry out the water runoff, the drops start from a short distance over the terrain, in a random position and with a random parameter defining the time until each one appears and falls, simulating the rainfall process.

When falling, the only present forces are the one due to the gravity and the drag (speed

increases until the terminal velocity is reached), and then, after a while, each drop must

intersect with the terrain at the corresponding height according to its relative position

over the grid.

4.2. Water runoff 30 Although Java3D provides its own built-in collision detection system, being able to ‘wake up’ when this event occurs, it could not be used since it is not suitable in this case. Java3D allows to choose between checking collisions between bounds or geometries. Nevertheless, for the first option, by means of their associated bounding volumes (usually, BoundingBox objects) containing each shape, there is no way to distinguish the exact particle colliding with the surface, so just the fact that the bounding volume of the whole GeometryArray is colliding with the one of the terrain, since GeometryArray objects has not a different bounding volume for each particle, but one for the whole object. For the second case, the detection is much more precise (exact, in theory) without using the bounds approach, but it still does not distinguish which particle is colliding with the surface.

As a result, the only possible solution had to be a system allowing to know the distance to the terrain from each particle for each moment. Java3D can do this through a set of classes and methods for picking, since it permits to start a virtual line from the current position of each particle with the aim of intersecting with the terrain, and so, to know its height at that point.

However, at this point appeared which possibly is the major problem encountered during this thesis work. The issue was that the picking system provided by Java3D fails when the theoretical intersection point is located just at an edge of the aimed object (the terrain, in this situation), as Figure 4.4 illustrates, where the particle (blue circle) is over an edge of the grid (as the red dashed line shows), and so nothing would be found.

Figure 4.4: Case when the Java3D detection system fails

Several cases where Java3D built-in collision detection fails to detect a collision correctly

were reported by Burrows and England [34] in 2002, and some of them continue obviously

unsolved. Xiao, Aziz and Nowinski [35] presented recently (2007) an exhaustive review

of the Java3D built-in collision detection system, with an alternative hybrid image-based

collision detection method incorporating the Java3D one to the basic image-based system.

4.2. Water runoff 31 Therefore, as these results were not acceptable, it caused that a custom detection system was created to know the terrain height at each position where there was a drop, and so, the distance to reach the surface (if any). The most important lines of code for this task are shown in Appendix C.

This method is surely less efficient than the one provided by Java3D, and also it has to be executed a very high number of times per second (one each update for each particle), but there is no choice if the one provided by Java3D fails. Moreover, in most of the situations drops appear in non-exact grid points and thus the required height was given (in the first versions) by interpolating among the four grid points around it. Nevertheless, the quads forming the surface of the terrain were not flat, since they were formed by two triangles, which means that the approximation was better as smaller was the quad (smaller error too).

For this reason, in the last version of the application, the quads forming the terrains have been substituted by triangles by using the TriangleStripArray class. The motivation of this change was to avoid the error in the interpolations for drops located in non-exact grid points, because, although it could be minimal in some of the cases, it could change the surface for every quad (from the point of view of a water drop) enough for example to create new regional minima which do not really exist.

Every drop is created by calculating its random components (inside of the grid), fixed height and random time-to-start. Whether a drop is falling or flowing, it is needed to know the distance to the terrain (i.e., the height of the terrain at the projected point below the drop), if falling, or the slope of the terrain in the current polygon (quads, at the beginning, and triangles finally), if flowing. The method to achieve this task, commonly called “Terrain Following”, can be divided into these steps:

1. Convert the XZ coordinates of the drop to grid coordinates.

2. Locate the polygon just below the drop (see Figure 4.5 ):

(a) Find the quad containing the aimed triangle.

(b) Select the right triangle, depending on the inequation from the line equation, x = (Q _x + Q _z ) − z, dividing the quad into two triangles:

P _x < (Q _x + Q _z ) − P _z → Green triangle in Figure 4.5

P _x > (Q _x + Q _z ) − P _z → Blue triangle in Figure 4.5

3. Calculate the height at the aimed point in the triangle:

4.2. Water runoff 32 (a) Calculate the normal of the triangle, whose vertices are P ₁ , P ₂ and P ₃ :

N = (P ₂ − P ₃ ) × (P ₁ − P ₃ ) (b) Finally, the height of the point P :

N ·(P − P ₃ ) = 0 =⇒ P _y = P _3y − N x (P x − P 3x ) + N z (P z − P 3z ) N _y

(a) Triangle location from a generic point inside the grid

(b) Generic point in a generic triangle

Figure 4.5: Terrain following

Then, when a drop is flowing across the terrain, in order to calculate the next point, from the moment colliding with the terrain to the one reaching a regional minimum (or leaving the terrain by one of its sides), the following calculations have to be made:

1. Find both X and Z slopes in the current triangle, obtaining the corresponding angles α _x and α _z . As it can be seen in Figure 4.6, where the red point is the current position, ans since all the calculations are made component by component (x, y, and z), it is possible to operate separately with each one.

2. Acceleration: Figure 4.7 shows the free body force diagram for the X component (there would be another one for the Z component, just by changing the x’s by z’s).

The force of friction (F _f ) will oppose the downhill component of the gravitational force (W _x

), with a coefficient of friction µ:

F = W _x

− F _f → ma _x

= mg sin(α _x ) − µN, N = W _y

= mg cos(α _x ) W _x = W _x

cos(α _x ) → a _x (t) = a _x

(t) cos(α _x ) = [sin(α _x ) − µ cos(α _x )]g cos(α _x )

a _x (t) = [sin(α _x ) cos(α _x ) − µ cos ² (α _x )]g

4.2. Water runoff 33 3. Velocity: v _x (t) = v _x (t − T ) + a _x (t)T, T ≡ time step

4. Position: p _x (t) = p _x (t − T ) + v _x (t)T + ¹ ₂ a _x (t)T ²

Figure 4.6: X and Z slopes in a triangle

Figure 4.7: Inclined plane with friction

4.2. Water runoff 34 In order to show the different results from this acceleration model, based on the “inclined plane with friction” problem, several values of the inclination angle and the coefficient of friction have been applied, as Figure 4.8 and Table 4.2 illustrate.

(a) µ = 0.1, α

= 30

(b) µ = 0.25, α

= 30

(c) µ = 0.5, α

= 30

(d) µ = 0.1, α

= 45

(e) µ = 0.25, α

= 45

(f) µ = 0.5, α

= 45

Figure 4.8: Approximate trajectories for a particle, depending on the inclination angle and the coefficient of friction, with α z = 45 ^o

Time (milliseconds)

α _x = 30 ^o

µ = 0.1 1619

µ = 0.25 1812

µ = 0.5 2476

α _x = 45 ^o

µ = 0.1 1503

µ = 0.25 1595

µ = 0.5 1834

Table 4.2: Time to left the terrain, for different values of µ and α x , with α z = 45 ^o

Note that the particle starts flowing after some seconds falling, which means that it has

an initial velocity when these measurements are made.

4.2. Water runoff 35 The task of measuring the time that takes a particle in crossing the whole surface has been done by means of the System.currentTimeMillis() method of Java.

Obviously, both Figure 4.8 and Table 4.2 show, respectively, that the trajectories of the particle are more straight and with less time used to left the terrain as smaller is the coefficient of friction and greater is the inclination angle.

Thus, Figure 4.9 shows the outcome of the final implementation of the runoff method, with different amounts of particles and their sizes.

(a) 1000 particles with size of 5 (b) 100 particles with size of 15 Figure 4.9: Rainfall and runoff of the water particles (sample images)

As it has been said previously, drops are re-created when they leave the terrain or reach to a regional minimum. These minima, points or regions, are found by means of the watershed segmentation algorithm used in the test platform exposed in Chapter 3. These methods iterate row by row through every point in the grid height, using the eight- connected neighbourhood, to finally obtain a list with all the regional minima in the terrain, being able to be formed each one by a single point or a set of them, if the minimum is a flat region.

Therefore, the class diagram at this point relative to the water package used to create

the particle system and its behaviour is the one shown in Figure 4.10.

4.3. Particle-particle interaction 36

Figure 4.10: Class diagram of the water package

4.3 Particle-particle interaction

This feature has been unapproachable due to its implicit complexity, which converts it into a whole Master’s Thesis topic by itself, since it needs a wide range of knowledge, like fluid theory, water pressure, viscosity, etc.

Therefore, in the current application, there is not any implementation done in which

particles can detect if they are colliding with each other, being also possible that two

different particles occupy the same space, since the only way to avoid this would be

implementing the complete list of behaviours defining a drop of water.