{End Bracket}
Developing the Virtual Earth 3D Control
Duncan Lawler
The Virtual Earth 3D control is a new tool released by Microsoft for visualizing the entire world in three dimensions. Rather than a standalone application, Virtual Earth™ 3D is implemented as a managed control, which allows seamless integration with Web sites or standalone applications. The Microsoft® .NET Framework security model gives users the capability of dynamically loading plug-ins to supply data, but restricting them to execution in a partial-trust environment.
One of the primary goals of the Virtual Earth 3D team's project was to enable developers to build their own applications. The beta release integrates seamlessly with the JScript® API available in the Virtual Earth SDK. Web developers who use the SDK to integrate mapping functions into their Web sites will now be able to show a 3D view with no additional work. For those not doing Web development, there will soon be SDK documentation available on how to embed the control directly in your own Windows® Forms or native application. We will also be documenting and providing samples of how to write and use your own plug-in extensions to change the control model, add your own data to the scene, and more.
To create the Virtual Earth 3D control, the team developed techniques for automatically generating 3D textured models of structures in the real world based on aerial photography with resolutions better than 12 inches. This control allows application developers to create mapping or visualization apps that show real-world locations with a level of detail that gives the user the experience of actually "being there."
.gif)
Figure 1 (Click the image for a larger view)
As you might expect, the data required to visualize the world at the resolution we wanted was many tens of terabytes in size. So it was immediately obvious that we would not be able to host all this data locally on the user's PC. The data would have to be hosted on a large server and transmitted to the client as needed. Even so, we needed to reduce the file sizes. We started by using standard terrain-rendering techniques to create the surface mesh with high detail in the foreground of the scene and lower detail as you move away from the camera. The fully textured buildings presented a real challenge because of the amount of data that can be visible in a single scene (each of the surface textures generated by the Virtual Earth automated process is unique).
To improve performance, first we created multiple levels of detail for the building models. The source data has a full detail geometry model and a texture map for each building face. Initially, we created a single texture atlas from the source textures for the building. We then took nearby buildings and created a single composite mesh that included all the buildings and a single associated texture atlas. Smaller buildings were removed since they generally won't be visible when the lower-detail level is displayed. We repeated this process with nearby composite meshes collapsed into larger and larger composite meshes. As a result, when the frame is rendered, the lower-detail composite meshes are displayed in the background of the scene instead of the full-detail meshes. Collapsing the textures and models allows Virtual Earth to render them with a single set of calls and greatly improves performance.
Bandwidth required for transmitting this data was the next challenge. To get the best quality for a given texture size, we used the new image formats available in Windows Imaging Components to compress textures for transmission.
Since users often want to visit more than one city, the control continuously monitors the current view and tries to guess where the user will go next. It asynchronously issues priority-ordered requests for the areas that are currently visible or will soon be visible. Also, the control reduces the level of detail it requests based on the connection speed so the user gets a more interactive experience.
Most users will tend to view their own city most often, so caching is a very effective way to improve performance on subsequent visits. Once the data is downloaded, Virtual Earth keeps the textures in system memory to render them to the screen. When the hardware supports it, the textures are converted to a compressed format in video memory. However, this conversion is CPU-intensive, so the team had to carefully throttle this on background threads to avoid causing stutters in the frame rate.
For more information and SDKs, visit the Virtual Earth forums at
http://dev.live.com.
Duncan Lawler is Development Manager for the Virtual Earth 3D team. He has been with Microsoft for 10 years, all of it with the Virtual Earth team, and has contributed to MapPoint, Atlas, Streets & Trips, MSN Maps, and Pocket Streets. Contact him at
duncal@microsoft.com.