Because "Ships" is a case study you can find some tech details here:
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.
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!"
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.
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.
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.
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.
©2009 All Rights Reserved • by PlanetInAction.com