YARCA

PROJECT REPORT

FOR

COMPUTER GRAPHICS COURSE

Davide Mottin (133556)

Elda Paja (133732)

Michele Pilloni (126865)

22 July 20, 2009

INTRODUCTION

NASA World Wind

World Wind is a database of the globe images taken by NASA’s satellites, which are reproduced in a

software 3D. This is freeware software, thus it can be downloaded for free by anyone.

Its global information system pulls together a high resolution map of the entire world and layers into it

satellite information from a variety of sources.

World Wind lets PC users zoom from satellite altitude into any place on the globe. Leveraging Landsat

satellite imagery and Shuttle Radar Topography Mission data, World Wind lets you experience Earth terrain

in visually rich 3D, just as if you were really there.

At the time being World Wind is lacking a lot of functionalities. Anyway, thanks to its java architecture,

it offers the possibility to be extended easily. One could add his own layers enriching World Wind with the

missing functionalities. There are many available plug-ins on the net, which could also be used.

Ray casting

Ray casting is a rendering technique that is used to create a 3D perspective in a 2D map. However, it

can also be used to render terrain map. This is the aspect used in World Wind. The basic principle after ray

casting is that of tracing rays backward from viewer’s eyes to objects. That is, rays are casted and traced in

groups based on some geometric constraints. In most cases the technique doesn’t offer high precision,

sometimes producing not very realistic images. However it is relatively fast and suitable for real time

processing. Moreover, as far as the storage is concerned, it does not require that much of space, since the

rendered images are not stored on disk; just the map is, generating the corresponding images on the fly.

Project Scope

The scope of this project is to extend NASA’s World Wind to make it possible to visualize ray casting not

only in intersection with the terrain, but also to consider 3D objects, which we call barriers, that will be hit

by rays emitted by other objects which we call transmitters, calculating the coverage area and field of view

of the transmitters and showing how the transmission signal is reflected onto the objects’ surfaces.

Basically, the problem we need to address is to perform ray casting both on the surface of the world

and on arbitrary 3D objects. The new system should offer the possibility to add/remove on/from the globe

3D model objects such as transmitters and barriers.

The structure of this document is as follows: in the first section the application domain is explained, in the

second section the proposed solution is thoroughly discussed through the presentation of the system

architecture and the reduced class diagram, testing environment, and the two parts of the given solution,

which are ray casting on the terrain and ray casting on 3D objects. The two parts of the solution are

explained in detail in the corresponding subsections. Finally future work is considered and conclusions are

discussed.

The Application Domain

The starting point of our application is composed by two main libraries and two small modules:

1. JOGL

2. WorldWind

3. JoglUtils

4. Movable3DModels

The first is a java wrapper of OpenGL libraries. It allows to easily use a set of primitives, designed to

help the development of 3D virtual worlds. JOGL is used to interact with the graphic card drivers. In this

project it has been used to build 3D objects which can be modeled using GL primitives.

The main performed operations are related to linear and affine transformations computed in the 3D

space, and the use of tests on the different buffers to calculate the textures, which represent the ray

casting result on the 3D objects.

The second is the virtual environment that rebuilds planets and their respective surfaces. In our

implementation we have simulated transmissions on the surface of the earth. But of course, with the liquid

architecture we have proposed, such transmission can also be performed on other models at our disposal.

World wind offers JOGL wrappers, that can be functions used to compute terrestrial coordinates or useful

classes that render the images on the surface of the earth. The framework comes equipped with a set of

layers that altogether define the final view. Hence major part of the work is easily done extending the WWJ

capabilities through the creation of new layers and definition of new object starting from the existing ones.

The primitives used for rendering, sector computation, image application on the terrain, are also very

useful for the realization of the project, since they offer very suitable methods which can be reused

avoiding to “reinvent the wheel”.

The last two represent additional modules that enable the system to load arbitrary 3D models using file

descriptors that are defined according to a specified format such as 3ds, obj, off, and so on. Depending on

the chosen format, different levels of detail for the given description are provided.

Proposed Solution

System Architecture

Figure 1 shows the system architecture. We can distinguish several modules in this architecture:

1. Global is the most important class because it contains all the useful information that is

exchanged between the other classes of the system

2. Support contains classes that define data types and utility methods

3. Engine contains the system kernel

4. GUI defines all dialogs, toolbars, and layers among which the Barrier Layer

5. Controller is composed of different types of listeners

6. Model simply based on JoglUtils load models from files and enable their rendering

Figure 1 System Architecture

Testing Environment

The main frame of the application is depicted in the figure below. On the left hand side there is a tree menu

that represents barriers and transmitters placed on the world surface. The central panel is a

WorldWindowGLCanvas which renders the globe and our layers and objects. In the same Canvas there is a

Toolbar that is described in the following section. There are also the standard menus, File and Edit, that

among other things save and load configurations and set the global options of the environment.

Figure 2 YFrame showing transmission

Toolbar

We add to the frame of World Wind a toolbar that contains the buttons for adding transmitters and

barriers, also those for starting and stopping the transmission. This toolbar has the characteristic of being

extendable depending on the number of buttons we put in it taking into account the spaces between

buttons.

Figure 3 YToolbar

In World Wind all the possible events that occur are handled through a SelectListener. In order to make

it recognize the clicks on the buttons of our toolbar, we make sure it recognizes just the objects of that

type. To accomplish this, YToolbar is created as a particular instance of World Wind Annotation.

The buttons of the toolbar are uploaded from a configuration file. The advantage of our solution is that

a ClickListener can be added, obliging the user to specify inside the configuration file the buttons according

to our specified protocol. If we would have a look at the properties of the configuration file, the button

names are specified as follows:

yarca.buttons.name = start, stop, antenna, bulb, barrier

As it can be noticed from Figure 2, the button names are defined in order, the same order they will

appear on the toolbar. Then, the path to the images representing the button icons is associated to each of

them as follows:

yarca.buttons.src = […]/start.gif, […]/stop.gif, […]/antenna.gif,

[…]/bulb.gif, […]/barrier.gif

First Part: Ray casting on the terrain

Transmitters

The new system offers the possibility to add/remove on/from the globe 3D model objects such as

transmitters, which are of two types:

antennas, and

bulbs.

The two different types of transmitters support different types of signals. This is the only difference; as

far as interaction with the terrain is concerned, in terms of ray casting, they behave the same way.

A toolbar is added to World Wind to control all the performed operations regarding transmitters.

In order to manage transmitters on the surface of World Wind, they are associated a sector. So, parallel

to the creation/selection of a transmitter a corresponding sector is created. Since we need to show the

coverage area of their signals, apart from associating a sector, we also associate a matrix which is mapped

to the sector. The values of the matrix vary according to a Gaussian or a bilinear law, the user can choose

between the two, having the maximum (1) in the center and descending toward the sides (from 1 to 0).

This matrix is mapped to the real image that will be shown to represent the coverage area of the

transmitter. The color of the image will vary in compliance with the values of the matrix. Different policies

are adopted by each transmitter to compute the resulting image. For instance, one transmitter sets positive

values for light and corresponding alpha (i.e. opacity) values for shadows.

Basically, this kind of structure enables us to perform all computations on the matrices, not on the

images themselves, exploiting in this way all the power of matrices’ operations.

Ray Casting Technique

Ray casting is performed based on the algorithm provided by Patrick Murris. It finds out where in the

world does a line intersect the terrain surface.

The WorldWind Java SDK allows to resolve the intersection from the eye point of view using the pick

process, based on drawing objects in unique colors, but that does not help much when you need to

compute such intersections from another perspective, like for line of sight calculations.

The ray casting code samples points at regular intervals along the 'ray' until it finds one in which

elevation is below ground. It then recursively resamples the last segment every tenth of the previous

sample length, until that sampling step is smaller than or equal to the required precision.

The longer the initial sample length, the quicker an intersection will be found, and the sub sampling

process will start narrowing onto the terrain. However, the larger the value the less accuracy you will get

since the ray will be able to go through some surface features in just one step and completely miss them.

The default values for sampling length and precision are 100 meters and 10 meters and can be overridden

in the methods arguments.

Figure 4 Ray Casting

Ray Casting with barriers

Although the main idea behind ray casting is based on the algorithm created by Patrick Murris, we have

performed several changes to adopt the algorithm so that it could meet our system requirements.

Figure 5 Ray Casting Algorithm

Figure 6 Ray Intersection Algorithm

Even though ray casting is performed over the terrain, we consider also 3D objects, that we call

Barriers, and show how ray casting is affected by the presence of such objects. The transmitter needs to

know at what distance these 3D object are positioned.

World Wind does not recognize 3D objects on its surface. For it to establish that there is a barrier on a

given point, to each 3D object we associate a sector, that represents the base area. Basically, barrier is an

object containing:

a sector for the extent of the object base that is a world wind object, and

the barrier itself that is a Model to render a 3D object using openGL primitives.

Since barriers have more or less a passive role, this is enough to control them.

There are different shapes of barriers, and this is the only difference from barrier to barrier. The shapes

we are currently using are: cubic, cylindrical, pyramidal, and spherical.

Ray casting works for each type and shape of barrier as long as the barrier defines the base sector and

the height of the barrier corresponding to each point of the base sector.

Any time, the system computes on the fly the transmission, graphically showing the images

corresponding to the coverage area of the signals emitted by each transmitter. Barriers are movable

objects that tend to block the transmission.

During ray casting, of course we make some approximation, which is of an acceptable level. The

tolerance is such that when the transmitter is moved, we do not require high accuracy, giving the algorithm

the possibility to be faster, but when the transmitter stops, we require high precision. From the user point

of view, this will not even be noticed.

Groups of transmitters

We can put more than one transmitter on the terrain. Different types of transmitters transmit different

types of signals. In case we have signals of the same type that are within the coverage area of one another,

they intersect. Except for the intersection, the resultant transmission is also computed and this is shown

graphically using a more intensive color. On the other hand, signals of different types cannot intersect with

one another, even if they were close together.

We compute the intersection of the transmitted signals, always working on the corresponding

matrices. The computation is performed on pairs of matrices. Below the algorithm to compute the

intersection is provided.

1) Compare t1 with t2. If they intersect, compute resulting matrices setting the resulting value in the

intersection part for t1 and 0 in that of t2.

2) repeat step 1 with ti for i = 1 … n

3) repeat comparing ti for i = 2 … n and ti+j for j = 3 … n, until no comparisons are needed

4) compute images starting by the matrices

t2

t3

t1

t1

r

1 r2 …

t2 0 0 …

Figure 7 Computing intersection between matrices

Figure 8 The respective values in the intersection part for each colliding matrix

Taking into account that we map the image to a matrix which is of the scale of the transmitters’ sector,

the values of the resulting matrix containing all the given matrices will be calculated as show in Figure 9:

Matrices can have potentially different dimensions, so the intersection part on each of them will

occupy a different space. We need to map the two parts of the intersection, computing the intersection

points relative to each matrix.

m2

m3

m1

Γ

Ymax Yimax Yimin Ymin Xmin Ximin Ximax Xmax

Figure 10 Computation of intersection area

Figure 9 Resulting sector

The following Δ values represent the ranges that differences in position between the two matrices and

permit the computation of the overlapped part (Figure 10):

1. Δxmin = ximin – xmin

2. Δxmax = xmax – ximax

3. Δymin = yimin – ymin

4. Δymax = ymax – yimax

The main problem of casting each image individually was that the borders were not so well defined,

mainly because world wind performs some operations, to improve the quality of the textures such as

Gaussian filtering. To solve this problem we came up with the idea of grouping sectors of transmitters. We

calculate a resultant sector, as for a resultant matrix, creating a map of groups, along with a unique index to

identify them. This kind of indexing and grouping offers great flexibility when moving, adding, removing, or

stopping a transmitter, updating the current view accordingly, coming out with an high quality texture.

Second Part: Ray casting on 3D objects

Except for computing ray casting on the terrain we need to take into account the barriers, and

show how the signal is reflected on these objects if they are in the coverage area of the transmitters.

Barrier Layer

Barrier Layer is responsible for the computation and mapping of the textures of the transmission signal

onto the barriers. This layer loops on every active transmitter in the world and computes the transmission

for every barrier in their coverage area. The transmission is computed by applying a texture that represents

the signal image, whose intensity changes according to a propagation function, considering values of

distance from the source, height of transmission and shadows casted by other objects in the same area.

As we have mentioned before, Barrier is an object containing:

a sector for the extent of the object base that is a world wind object, and

the barrier itself that is a Model to render a 3D object using openGL primitives.

Since we have barriers of different shapes and these barriers as every other model in openGL are not

solid (they are composed of a set of triangles meshed together to represent the shape) we need to

encapsulate the barriers inside a bounding box, that is enclosed by the near plane, far plane, top, bottom,

left and right planes.

The simplest way is to constructed a nearly cubic bounding box, defined by the before mentioned

planes. This method is valid for every barrier given that the sector is known. This barriers are considered to

be “generic” as later on during the development of our system we introduced a new type of barriers, called

Directionable Barriers.

Directionable barriers are constructed based on 3D models that are loaded from files where this

models are described. This permits us to compute the bounding box as a sphere, having as center the

centroid of the solid. So far the two directionable models we have implemented are the cube and the

parallelepiped.

This kind of barriers know where the transmitter is positioned with respect to their relative position

and using this information they can easily compute their bounding box using these parameters: field of

view, near distance, far distance and the window ratio. The advantage of having such barriers is that they

can distinguish which of their faces are illuminated by the transmission and which are in shadow. Except for

this, they can determine which is the nearest point to the transmission center. This value is used to

determine the near plane of the frustum as shown in Figure 11.

Figure 11 Setting the Frustum

Compute texture

To perform ray casting on the object surface the transmitter needs to know at what distance the 3D

objects are positioned.

To find out the distance from the transmitter to the barrier:

(1) we set the frustum, defining the eye position, the eye direction, which is from the transmitter to

the centroid of the barrier, the up vector and the near clipping distance.

(2) DEPTH_TEST is enabled to render the barrier.

(3) the result of the DEPTH_TEST is written on the Depth Buffer. This matrix is saved.

(4) associate the values of the Depth Buffer to world wind distances. The idea is that the values inside

the Depth Buffer do not have unit measures though they already express information about

distances. We need to make some kind of calibration to do the right mapping between values and

real distances. We use proportion for this purpose. A known point, for which we know the position

in our matrix, is considered. We chose the vertex of the barrier nearest to the transmission center.

Having this known point, we do know this information about it:

a. the corresponding value in the depth matrix

b. the distance to the transmitter, which is calculated as the distance from the transmitter to

this point of the barrier

In this way, we can build a correspondence between the values of the depth buffer to the

distances, to calculate the actual distance for each point.

Since we want to find the value in the depth matrix corresponding to the nearest point, we check the

values in the depth matrix till we find the smallest one DM [rnearest, cnearest]. For every other element of the

matrix, if it has a depth value for the barrier of course, we calculate the difference between the value

DM[r,c] for that element and the value for the nearest vertex vdepth.

This difference constitutes an increment ratio i, showing how we could compute the distance of each

point starting from the known distance of the nearest point vdist:

In the case of non directionable barriers we consider a bounding box calculated considering just the

base sector. This allows having two bounding vectors starting from the center of the transmission to the

vertices of the base sector, taking as end points the leftmost and rightmost vertices of the base in our field

of view. The angle created by these two vectors will define the extent of the field of view. We take the

value of the depth matrix DM [rleft, cleft] corresponding to the left most point and then we compute the

value for every point DM[r, c] as follows:

This last method still works, but it suffers from approximations that are due to the way the world wind

framework computes the barrier sector that is rectangular and maps it on the spherical shape of the world.

So much better results are obtained using Directionable barriers.

To show how the signal is reflected on the surface of the barriers, apart from the depth we need as well

to associate to each point the maximal height to which the transmission can reach. Since the transmission

changes according to a propagation law, having such maximal point, would help us exclude all the points

above that one. To accomplish this we have used proportion at first. This is a simple method that calculates

the proportion between the known height of the barrier and the corresponding number of cells given by

the depth matrix. The method works as follows:

1) scroll the depth matrix till we find the first cell that contains a significative value (value

different from 1.0), this element is considered to be the highest point of the barrier

2) save the index of the column of this element

3) scroll the rows in this column till we find the last element with significative value (i.e the

successive row contains a value of 1)

4) save the index of the row of this element

5) count the number of cells between and including the two elements

6) calculate the height for each cell of the matrix through the proportion between the maximal

height of the barrier and the above count

This method worked correctly when the height of the transmitter was more or less the same with that

of the barrier, so that the transmitter could have a frontal view of the barrier. In other cases, when the

transmitter was positioned higher than the barrier, there were errors in calculating such proportions using

the values of the depth matrix. A big disadvantage of such approach was the fact that the calculations were

highly depending on the shape of the barrier.

Due to these restrictions, we chose to consider a second approach. If we think of the cone of

transmission, we could split it into an infinite number of circles, starting from the biggest one that is at the

base to the transmitter. The diameter of the circles is as wide as the transmission at the specified height.

We choose one of this circles and assign a color to it. Looking at the direction and position where the

barrier is supposed to be prospectively through this circle we can see the extension of the transmission for

that particular perspective. We save such information in what we call a “stencil” buffer, that is color buffer

used as a mask and is represented by the selected circle. All the values of the stencil buffer that do not

coincide with the given color of the selected circle, are considered to be out of the transmission area, as

they are higher than the maximum transmission height.

Afterwards we use the information contained in the depth buffer to eliminate the values corresponding

the elements out of the transmission perspective.

At this point, the last step at finalizing the necessary computations, is to determine whether there are

other barriers between the given barrier and the transmitter.

We know precisely where the barriers are with respect to the transmitter, so we only need to order

them in descending order based on their distance to the transmission center. This will ensure that the most

distant barriers will be rendered first allowing to obey the actual positioning order of the barriers. In such

case, we need to use the color buffer to identify possible intersections of the line of sight which would

result in eventual shadows casted on the back barriers. In order to distinguish between the different

barriers we have assigned each of them a unique color.

To summarize, ray casting on the barriers is performed by the following algorithm:

For each Transmitter

For each Barrier with center ≤ transmission radius

1. set the frustum based on the bounding box

2. calculate the “stencil buffer” and save it

3. clean the color buffer

4. calculate depth buffer and save it

5. disable depth test so that nothing is overwritten in the depth buffer

6. render other barriers starting from the most distant, in order to know whether there are other

barriers in front of the one that is being considered

7. Calculate the texture by combining the information taken from the three buffers.

It is important not to forget to disable the depth buffer test before performing the “stencil” buffer and

the color buffer test, otherwise it would destroy the view in the 2nd and the 5th step, because every new

object would have to pass this test first.

Texture mapping

Textures are images that are mapped in a 3D world. Each texture has its own casting matrix. Having

such a structure, to perform the texture mapping we need to map texture coordinates to vertices. There

are two ways to generate texture coordinates:

object coordinates, and

eye coordinates.

The first ones are fixed with respect to the coordinate system of the object, whereas the second are

fixed with respect to the eye.

Both these types of texture coordinates can be generated either manually or automatically.

If we had to do it manually, that would be quite difficult. We would have to determine and calculate all

the vertices on which the mapping can be done, decompose the texture, find out whereas the face of the

object is the front or the back one.

But then, when the coordinates are generated automatically, we do not have to determine and

calculate the vertices on which the mapping of the texture should be performed, neither need we do the

decomposition of the texture. All this is done automatically.

There is still a problem though. This issue is related to the need of determining the positioning of the

different sides/faces of the object. To solve this enquiry we consider the normal vector of each face of the

object and compute the scalar product between such vector and the vector of eye direction:

If the product is positive, it means that the angle between the two vectors is less than 90°, and

texturing should be enabled.

Otherwise, if the product is negative, the angle is greater than 90°, and texturing should be

disabled.

This task is possible only knowing the position of the transmitter in the relative coordinates of the

barrier. The problem is that the transmitter has world coordinates, whereas the barrier has coordinates of

its own coordinate system. For this reason, we need to transform the world wind coordinates to

coordinates of the barrier’s relative system.

Multiple Texture Mapping

In the case of multiple transmission on the same barrier we considered the overlapping of all the

casting textures. We used multipass texture mapping and blending to represent how signals from different

transmitters intersect or overlap on the barrier.

Figura 12 Multipass techture mapping

This method renders the textures following this multi passing scheme:

For every barrier that has to be rendered and has a texture on it:

1. If the barrier has not been rendered before, draw it normally and map the texture on it;

2. If the barrier has been already rendered, draw a fully transparent barrier over it with only the

texture visible.

In this way we realize the intersection of the different textures, showing the same object once opaque

while the rest of times totally transparent in order to visualize just the textures. The way we achieved the

transparency of the barriers representing subsequent transmissions is by using the blending technique. We

simply draw subsequently black barriers with the additional textures. In fact the RGB values of black (0,0,0)

plugged into the standard blending operation gives the complete transparency:

,

where and are blending factors for Source and Destination respectively.

Future work

There are still a lot of features that could be improved to the offered system. First velocity could be

increased. Second, better precision could be achieved. Though during our system development we have

considered several methods to perform different computations always increasing the precision of

calculations, still approximation and tolerances do exist. Another direction of extending our system would

be to consider barriers of other shapes and dimensions. Furthermore flying objects could be taken into

account. And last but not least, our system is built on top of world wind version 0.5, so a major

improvement could be to adapt it to the latest version of the world wind framework.

Conclusions

The proposed solution is a first attempt to solve problems regarding raycasting in world wind environment.

The developed system has a modular architecture that allows great expendability, so can be considered as

a good library to study and expand this problem. Although the work exposes only a testing system, the idea

behind it are interesting and can be exploited in order to produce a fully working module. Raycasting is a

huge problem that cannot be completely explored in a prototype architecture such as the one proposed.

Some operations are pretty slow compared to modern raycasting algorithm, but this is mainly due to the

fact that computations are performed for many different objects. In addition, the two proposed

techniques are different approaches to this problem. Provided that, this work come with a liquid and

reliable architecture, useful to improve this work on top of it.