Application structure

I have written a ship class in javascript that handles the individual parameters of each ship (shipsim.js). The class also implements the ship physics and wake/bow animation. An instance of this ship object is created for each ship in the main program (ships.js) which handles the interface between the ship object and the google earth plugin. Ships.js also is responsible for creating the various resources such as the screen overlays that form the various instruments.

Visual system

Google Earth proves extremely capable to handle many overlays with alpha transparencies which enables developers to create intricate and graphically rich instruments. Proof of that can be seen in the Compass/rudder instrument which consists of 5 layers of bitmaps. (compass rose, rudder dial, rudder position needle, rudder target needle and instrument bevel). Each layered image uses alpha transparency to create a sense of depth and shadows. There really is no limit what can be achieved in the hands of an experienced graphics artist.

3D models

The models have all been created in sketchup 7. Although some texturing steps such as the texture on the airship could not be achieved in Sketchup and needed to be performed in a range of other programs. A nice detail is the fact that the texture for the deck of both the refuel ship and Queen Mary2 were actually taken from Google earth satellite imagery. Although the Google Warehouse contains some wonderful ship models, it is rare to find efficient models that rely on texturing for details. It is important to keep the models simple as not to slow down the rendering speed too much. To all the modelers out there: "Please use textures instead of geometry!"

Simulation frame rate

The entire simulation is using the endframe event which means that a lot of the code is executed at the end of each rendered frame. On a decent computer the frame rate will be consistently around 60 fps so it is important to keep that code as efficient as possible since it is executed so often. I have used a range of global variables where I store computational intensive data that is re used. The simulation logic uses deltaTime which is the time in milliseconds since the last frame was drawn. This make the simulation independet of the PC frame rate.

View Navigation

I found the default Google Earth navigation interface too cumbersome for this application and really wanted the camera to follow the ship. For this I created 3 additional camera modes similar to what can be seen in many games. I am especially happy about the "head view" which locks the viewer to the ship. The fixed view simulates a fixed camera that tracks the ship as it sails by. Once the ship has passed it will randomly relocate itself somewhere in front of the ship. The creation of the additional camera modes was challenging because of the multi threaded nature of Google Earth. You can not simply set a camera position in a mouse down event and expect the frameend event in a different thread to handle this correctly.

Execution Speed

Although web based delivery of the application provides easy access to everyone, it also proves a challenge for the developer to keep the processing speed up. Javascript is not one of the fastest languages around and in simulation speed is of the essence. I needed to resort to a rather primitive ship simulation algorithm just to keep the speed fast enough for most PC's which is a pity because my initial algorithm is much more realistic and support things as asymmetric thrust with two drive units and a bow thruster. Once I have optimised my new ship physics I will try again to put it into "Ships"


Sound was initially implemented using soundmanager2 unfortunately it will only dynamically let me load sound clips in mp3 format (Flash limitation) which makes it unsuitable to loop sounds such as the engine sound. I ended up writing my own flash application and instead compiled in the engine sound. Flash script provides the external interface to control volume and shifting the sound between the left and right speakers depending on the relative location of your ship.

Water shaders

Recently Google released a new version of Google Earth that uses water shaders. The new ocean effects looks great from far away but when up close the effect is diminished and it makes water look way too clear. Especially when passing under the Golden Gate bridge we can see the photo based road at the bottom of the water, the water is so clear that only the ships wake gives away where the water line is. I would love to see google earth improve this feature by scaling down the wave effect in the shader when you get closer and make the water less transparent and closer to the actual color of the water displayed on the imagery.

Land detection

Land detection was a challenge that I failed to solve before this release. Google Earth provides elevation data and initially I thought that I could use the elevation level of 0 for sea level. That at least would give me land detection on sea and in sea ports. Unfortunately this is not the case as you will see in Rotterdam. There are various water hills at points where I suspect ships were sailing when the elevation measurement was taken. Even the more hi-res elevation data rolled out by google now is not going to help us. Besides, I want to go up river as well. The Google Earth plugin does not detect a point in polygon which could be used for land detection as well. My implementation in Javascript worked fine but it just ran too slow. Then of course there is Google maps. Obviously Google possesses the water land data in very fine detail, there just isn't an api that let's me access this data quick enough. I am now working on a client side quadtree solution that will generate high speed clientside water/land lookup out of polygons once and then performs lookups in the quadtree on every frame. This technique should work well for a range of high frequency area lookup requirements.



©2009 All Rights Reserved  •  by