Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Main Goal Development of an application that allows flying virtually over El Hierro Island (Canary Islands), showing the building structures of a hydroelectric power station that is in construction.
Input data: Aerial photos Aerial photos at scale 1:5.000 (approx. 1 m 2 per pixel) Number of images: 66 Image resolution: 2.500 x 2.500 File format: TIFF Individual image size: 19 Mb Total image size: 1.2 Gb Converted to PNG: 800 Mb 2.500 x 2.500 pixels
Input data: Height map Rectangular grid with data value each 10 meters. 2.500 points 3.000 points
Input data: Building and structures design Planes, photos and designs of buildings and structures of the power station (including one new harbour).
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
First test: using CS walktest application Aplication included in CS to fly on a simple textured terrain. Automatic collision detection Height map and texture map are read from disk.
Defining the scene in XML Plugins Textures Shaders Materials Renderpriorities Triggers Terrain is defined in three entities: Terraformer (height map info) Terrainfact (terrain size and position) Terrain obj (material and LOD params)
Creation of the terrain There is one only height map for the whole terrain Terrain dimension must be square, so we add two horizontal bands Theres is a lot of sea vertices (with height 0) Finally we choose the three sub-terrains, that minimize the number of sea vertices. 3.000 x 2.500 3.000 x 3.000 18M triangles 9M triangles
Problems to read height map in CS Height units were in meters, from 0 to 1.800 Needed more than 1 byte per vertex Crystal code was modified to read a height map from an RGB image (3 bytes per pixel) 1.800 meters Result value was R*256+G This method was added to Crystal core in following versions
Creation of simplified texture map All the 66 photos are included in a square of 30.000 x 25.000 resolution For this initial version, we used a simplifed texture of 3.000 x 2.500 resolution Adding two blue horizontal bands we obtain a square texture of 3.000 x 3.000 Finally, three sub-textures are generated and associated to each terrain 3.000 x 2.500 3.000 x 3.000 9M pixels 4.5M pixels
Level of Detail (LOD) LOD algorithm implemented in CS current version is chunk-lod (brute force): The terrain is divided in blocks recursively as a quad-tree The stop condition is when block is too far, or when reaching a minimum size Every final block is divided in n x n triangles LOD params must be adjusted for each terrain to obtain an optimum visualization
LOD errors in terrain unions Terrain unions are not completely closed in these cases: when both terrains have different LOD level, when having different size One solution: implement a joiner between each pair of neighbouring terrains Another solution: create more terrain objects independent LOD control for each terrain Another minor problem occurs when changing to a different level of detail Current CS version does not include geomorphing
Creation of meshes for the sea All the vertices belonging to sea has null height A mesh object is a fixed vertices grid, with no LOD Finally, 6 meshes are created with a blue texture
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Texture mapping problems - I Initial solution proposed: one Terraformer object to load the whole height map (3.000x3.000), one Terrain Fact to visualize the whole terrain, and one Terrain object with the whole texture Problem: Crystal forces to map the whole texture over the whole terrain there is no graphic card that support that resolution!! 30.000 pixels 25.000 pixels Terrain object
Texture mapping problems - II Next solution: using several terrain objects one Terraformer object to load the whole height map (3.000x3.000), one Terrain Fact to visualize the whole terrain, and 66 Terrain objects, each one with a 2.500x2.500 texture Problem: if only a Terrain Fact is specified, the 3.000x3.000 height map is repeated in every terrain!!
Texture mapping problems - III Next solution: using several Terrain Facts one Terraformer object to load the whole height map (3.000x3.000), 66 Terrain Fact to visualize the whole terrain, and 66 Terrain objects, each one with a 2.500x2.500 texture Problem: each Terrain Fact uses the right part of height, but do the same with the texture!! Example: The effect is that only the proportional part of the texture is mapped on the terrain, instead of the whole texture
Texture mapping problems - IV Next solution: forcing that texture be mapped as a mosaic This could be done setting the Opengl variable named TEXTURE_WRAP to the GL_REPEAT value (inside CS source code) GL_REPEAT
Texture mapping problems - V In order to use mosaic mode, we are forced to use Material Map Material Map consists of an intermediate texture that allows to combine different textures on a terrain Every pixel value of the material map indicates what texture is mapped on that area It is used in walktest application to define grass areas, water areas, etc.
Texture mapping problems - VI A test with one only Terrain object with a Material Map of 66 different values (as a chessboard) was implemented The good news are that LOD problems are solved Problem: execution time is very very very slow!! Final solution: using several Terrain Fact objects one Terraformer object to load the whole height map (3.000x3.000), 66 Terrain Fact, each one with a material map of one only value, and 66 Terrain objects, each one with a 2.500x2.500 texture
Doing reflection in Opengl Reflection in mosaic mode has a problem in the borders, when computing the linear average with the outside of the texture Solution: setting the Opengl variable named TEXTURE_WRAP to the GL_MIRRORED_REPEAT value (only in newer opengl versions)
Flipping textures To work properly, every texture was flipped according to its position in the mosaic Example: Texture image F4 must be saved after horizontal flipping: Flipping
Redimensioning textures to a power of 2 Every texture is re-dimensioned to 2.048 x 2.048 Exporte to JPG file format Total disk size: 102 Mb 2.500 x 2.500 1 pixel = 1m 2 2.048 x 2.048 1 pixel = 1.5 m 2
Results of this second version Initial loading time is too big (more than 5 minutes in a P-IV 3.4GHz) Loading images in cache: 2.5 minutes approx. Computing data structures for collision detection (named OBB): 3 minutes approx. Small LOD error in terrain borders
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Final implementation in C++ A C++ application has been created that draws the scene directly without using XML file: No time needed to parse the XML file with the scene Better LOD control, because we have direct access to terrain data in run-time. Also, there is a new LOD param that is not available from XML file Our own collision detection algorithm could be implemented, avoiding the initial time computing OBBs y Viewer height Terrain height under viewer x, z
Converting textures to DDS format DDS (Direct Draw Surface) format avoids the time needed to load texture images in cache It uses the same compression algorithm that most of current graphic hardware File size is a little more than JPG, but includes Mipmap info: Performance is better than using JPG The wrong pixel values in terrain borders is solved, because Mipmap info is inside the file it does not use neighbours texture to compute border colors 2.048 x 2.048 Total disk size: 176 Mb 1.024 x 1.024 512 x 512 256 x 256
Two solutions to generating the sea One solution consist of placing a synthetic blue plane under the island. The problem is the intensity changes between both seas. Another solution is process the sea in each texture, to achieve that the synthetic blue reaches the coast. The problem is that we lose the realism close to the coast.
Final solution for the sea Final solution consist of blurring the sea smoothly in each texture in order to avoid the intensity change.
Problems with the Z-buffer Sea plane has a height 0, and the island height is between 0 and 1.800 units. When camera moves up far away, z-buffer have a precision problem, and the sea could overlaps the coast. Solution: let down gradually the plane height value when camera moves up, and increase it again when camera moves down. We think this problem is due to overflow errors in z-buffer implementation.
Sky representation The sky is represented by a semisphere. A synthetic sky with clouds was generated and texture mapped on the semisphere: Image center maps on the pole Image borders map on the horizon In areas close to horizon, the sky was blurred to achieve a more realistic effect.
Shaders Shaders are XML files that allow the implementation of visual effects. The default shader used by Crystal adds realistic atmospheric effect, but it does not work in many computers. In order to work properly in most of computers, these techniques must be removed.
Shaders in OpenGL Older graphic cards do not have programmable pixel operations. Default shader in Crystal put all the information defined in the XML file into the Pixel Operation. Older graphic cards had not access to these data, so the pixel data transferred to Texture Assembly were wrong. Solution was insert texture data in Pixel Data, and make nothing in Pixel Op. The problem was that we lose definitively all the atmospheric effects OpenGL Rendering Pipeline
Removing light sources Every photo had shadows in the opposite direction of real light sources when they were taken. When placing light sources in Crystal, it was impossible to make correspondence between the position of the light and the orientation of all shadows. Solution: set the ambien light to the maximum value in the shader, and remove all the light sources. This allows an uniform brightness, and also avoid computation of normal vectors.
Problems with graphic card syncronism Sometimes, when rotating the camera, overlapping of frames occurred in the same refresh. Solution: enabling the syncronism in the graphic card the computer is forced to wait next vertical refresh before display the next frame. It is specified in the file video.cfg, setting the param vsync to true. The problem then is that sometimes, the application accelerates or slows down (ejem, running in a 60 Hz system, it passes suddenly from 60 to 30 fps) Solution: limit the fps, including a sleep time when the frame is computed very fast.
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Inserting 3D objects The buildings were modelled in 3D-studio. They must be converted to a different format to be imported to Crystal: An option is using the library CAL3d, but it is more oriented to articulated models, and we were forced to create a skeleton for the objects. The other option is using a converter included in Crystal (3ds2lev). Problems when using 3ds2lev: It must be only one texture per object. Texture coordinates could not be specified (at least, we didn t know). This means that the texture must map the whole object surface,. That forces us to declare one object per texture. Once the models have been converted to lev, they are loaded inside the source code. After that, models are scaled and translated to their final position.
Positioning problems Differences between height map of the island and height level curves in the design plane. In some areas, height values would change after the construction of the power station (like walls of the dam)
Wind turbines Modelled from real turbines design. Blades must be rotating during the flight
Animating the models Rotation are defined in 3DS using pivot points as the center of rotation. The problem is that Crystal does not use these points, and rotates objects around the origin. We were forced to modify all the 3ds models to center each one in its rotation center point. Animations of wind turbines were made inside the source code.
Power station Modeled from syntethic photos Several palms have been added. Some electric towers have been modelled from a grid structure.
Upper dam We must fill the hole in the terrain. Appearance must be like a traditional dam. Finally, we ruled out 3d-modelling, and retouched the photo.
Pipes Pipes must be at ground level Problem is that ground level in the poligonal mesh is not evident.
Harbour We started from design planes and present photos. A small sailing ship has been added
Natural structure design Modelled from photos. The same photo was used as a texture for the model.
Light sources for the models The current shader had the ambient light to the maximum value, and no point light sources added objects appeared flat Solution: a second shader was created with additional light sources just for the models. The terrain kept the same shader with only ambient light.
Additional details: shadows of turbines
Additional details: sea foam near Bonanza Rock
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Developing the interface with AWS We started from the example file awstest.cpp There exist a.def file indicating all the windows and components to be shown. There exist a second file.cpp with two important functions: Initialize: loads all the windows and components (some of them could be invisible), Event handlers: activated when an defined event (defined in the file.def) has been produced. Here we decide the commands to execute.
Interface appearance We chose to define all the components as images, to avoid the appearance of a traditional window system. Every menu, in every language, is a different image. Every image must be power of 2.
Upper menu bar Language change
Upper menu bar Options menu
Upper menu bar Show viewer position and view direction
Upper menu bar Show numeric info about UTM coordinates and viewer height
Upper menu bar Show current viewer speed
Upper menu bar To handle the flight using mouse
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Population names Every population name must be shown in its exact 3D position. A perspective projection must be computed to obtain the 2D coordinates on the screen. Red color indicates populations. Blue color indicates places of interest. Font size indicates importance of the place.
Algorithm to display names Factors to take into account: Distance from the place to the viewer d Angle with view direction Population importance level (between 1 and 3) View up vector We also have to detect if the place is visible from viewer To compute this, the height of several inner points belonging to the ray is comparted with the height of the terrain View up vector y View direction d Population x, z
Finding a well contrasted font The problem is that fonts has one only color, and their visibility depends on background color. Ideal solution would be using an outline font, but we did not find anyone. Final solution: we display 9 times the names: one with the right color, 8 more with black color and 1 pixel displaced.
Information cards Several cards with photo and text are defined for every place of interest. The card is displayed automatically when user approaches that place. When user leaves the place, the card dissapears. The text must be written in the selected language.
Algorithm to display cards To select the card to display (if any), two conditions must be fulfilled: The distance from the place to the viewer must be lower than a threshold value, The place must be inside the viewing volume. If more than one card pass the conditions, the one closer to the view direction is selected. Conditions are evaluated every two seconds, in order to keep visible the card several frames y View direction d Place of interest x, z
Automatic flights The user could flight automatically to any place in the island. The flight starts from the user position, and ends in the desired place. The view direction when arriving a place is predefined for each one.
Computing the automatic flight path (2D case) The goal is starting from point A and arrive to the point B with the desired view direction. First we look for the circle tangent to B with radio R Final view direction Then we look the straight line starting from A and tangent to the circle. The flight starts with a rotation in the initial point A R B 3. Final turn Current view direction 1. Initial turn 2. Straight path A In 3D, a sphere is used
Predefined routes There exist 6 predefined routes. Every route passes by several places of interest. Information cards are displayed during the flight.
Computing route path Every route is defined by a list of points. Every point has a view direction associated. The route path is defined using a spline curva that touches all the points. View directions are interpolated between each two points. 6 1 2 3 4 5
Navigation devices Keyboard Joystick Mouse
Index 1. Definition of the project 2. Initial version (simplified texture) 3. Second version (full textures) 4. Final version in C++ 5. Modelling and inserting 3D objects 6. Interface design 7. Additional Features 8. Conclusions and future work
Conclusions Crystal Space is a suitable tool to develop a terrain visualization DDS is the ideal file format for textures Things that could be done to improve CS library: Terrain object perfomance and LOD algorithm must be improved Insertion of 3D objects works fine, but animating it could be a little complex Interface design with AWS library has a very traditional look, and to obtain a cool design you need to work only with images. An outline font would be a very interesting tip Automatic camera path algorithm could be included
Future work The future goal is to obtain a system that allows flying the whole archipelago Canary Islands Two main problems: Enhance the terrain object and LOD performance Dealing with large texture maps
First problem: LOD performance The problem of holes in the unions between different terrains must be solved. One solution could be using an only terrain object (or only one for each island) the object should allow several textures simultaneously! Perhaps the best solution is to rewrite the terrain object. Geomorphing feature would be very interesting. Canary Islands
Second and main problem: large texture maps El Hierro is the smallest island (268 Km2) Texture size: 176 Mb (DDS format) The seven islands has a surface of 7.447 Km2 Estimated texture size: 4,9 Gb All these textures could not be loaded simultaneously in texture memory. Solutions in the literature: Texture paging Texture subimage loading Hardware support clipmapping on SGI Performer Canary Islands