Virtual Earth 3D team blog : VE3D

GraphicsProxy RenderState

NikolaiF — Tue, 22 Sep 2009 23:03:00 GMT

I've gotten a few questions lately about how to do some alpha effects using models, specifically MeshGraphicsObject. After you create the GraphicsObject, it has a RenderState object available on it. The fields on this object will be familiar to those experienced with DirectX, but here's a rundown of a few especially useful ones:

Allow your model to cast shadows on the ground.

newMesh.RenderState.Lighting.CastShadows = true;

Allow your model to have directional shading (you can adjust the direction of the light using Host.WorldEngine.Environment.SunPosition).

newMesh.RenderState.Lighting.DirectionalLightEnabled = true;

Allow your model to use transparency, whether from vertex colors, textures, or TextureFactor (see below).

            newMesh.RenderState.Alpha.Enabled = true;
            newMesh.RenderState.Alpha.SourceBlend = Blend.SourceAlpha;
            newMesh.RenderState.Alpha.DestinationBlend = Blend.InvSourceAlpha;

Allow use of TextureFactor to control the overall color of the model. For example, you can create a model that has a texture with a white patch, and then create two models, one red and one blue, both using the same texture but differing on the value of TextureFactor.

            newMesh.RenderState.Stages[0].Blending.ColorArgument1 = TextureArgument.TextureColor;
            newMesh.RenderState.Stages[0].Blending.ColorArgument2 = TextureArgument.TFactor;
            newMesh.RenderState.Stages[0].Blending.ColorOperation = TextureOperation.Modulate;

Allow use of TextureFactor to control the overall opacity of the model. This is great for fading effects, as changing the TextureFactor per-frame is cheap.

            newMesh.RenderState.Stages[0].Blending.AlphaArgument1 = TextureArgument.TextureColor;
            newMesh.RenderState.Stages[0].Blending.AlphaArgument2 = TextureArgument.TFactor;
            newMesh.RenderState.Stages[0].Blending.AlphaOperation = TextureOperation.Modulate;

Change the filtering used for textures. For example, in the XFile sample, if you zoom in close to the model the texture gets blocky. Dropping this code in improves the situation.

newMesh.RenderState.Stages[0].Sampler.MagnificationFilter = TextureFilter.Linear;
newMesh.RenderState.Stages[0].Sampler.MinificationFilter = TextureFilter.Linear;

The TextureFactor value mentioned above. This value would make the model ghostly transparent and red-tinged. This (and other values in RenderState) can be cheaply changed every frame.

newMesh.RenderState.TextureFactor.Value = Color.FromArgb(128, Color.Red);

One additional note: to use alpha, you must also call AddAlphaRenderable in your actor's Render function instead of just AddRenderable. The distance is a sorting function that lets the renderer know what order to draw the alpha in (affects blending). A constant value works in some situations, but if you find things look wrong, especially when one of your models occludes another, try using a value based on the distance between the model and the camera.

Here's a few shots to demonstrate the effects of these switches:

Everyone's favorite XFile sample model.

The same model, with shadows and directional lighting (the sun is above and a bit behind, if you move it the shading and shadows move appropriately).

The same again, with an alternate texture that contains transparency and the various alpha switches on. Note one detail: the shadow casting code does not account for transparency.

Same again, with all switches described above turned on. The texture filtering is improved (look for blockiness in the center of the body in the previous shot), the color is shifted red, and the whole model is somewhat transparent, even parts where the texture is opaque.

Actor data source questions

NikolaiF — Sun, 26 Jul 2009 21:06:00 GMT

I just fielded a few good questions via email about actor data sources, and thought it would make a good post.

Actor data sources are a way of getting little bits of your code (actors) into the world, handing spatial indexing and cache management for you. When each actor is in view, they are given the opportunity to execute code in the Render and Update functions. When the cache is full and an actor is evicted, they again may execute code in the OnRemove function.

You create them by implementing a DataSource with usage Actor, and an ActorBuilder which translates the Primitives returned into Actor objects, along with information like what areas of the Earth the actors should be used in, as an ActorBounds object. All of this can be seen in the ActorDataSource sample.

In the sample, however, only one Primitive is returned per request, and only one Actor. What if you want more? The important thing to know is that there has to be a 1-1 correspondence between Primitives and Actors *. You must create one Actor for every Primitive used. If you create more than one Actor for a single Primitive, only one will appear.

The reason for this is the Actor update story. It is possible to update an Actor already in the system by two methods. When an Actor is updated, the PrimitiveId from the passed-in primitive is used to find and update the actor in question. If you add multiple actors per primitive, an ambiguity arises as to what you actually want to do.

It is possible to resolve this ambiguity by creating "nested" actors. This is simple. Just create the actors you want, and then a "container"

*: actually you can create a single Actor with multiple Primitives, but I don't want to confuse the issue for now.

Updating an Actor:

Expiration. On the Entity attached to your primitive, add a property "ExpiresInSeconds":

e.EntityTypes["bunny"].Properties.Create("ExpiresInSeconds", typeof(double));

...

entitySpec.Properties.SetValue("ExpiresInSeconds", 10.0);

Your QueryPrimitivesInternal function will be called again for every area the affected Actors live, and OnRemove will be called for the expiring Actors.

Manual. You can specify a specific PrimitiveId to update using OnDataChanged in your source DataSource.

PrimitiveIdWriteableCollection wc = new PrimitiveIdWriteableCollection();
wc.Add(new BunnyPrimitiveId(this, tile));
OnDataChanged(new SpatialExtent(null, null, wc.GetReadOnlyCopy()));

You must also implement the QueryPrimitivesByIdsInternal function. A collection of ids is provided, and you must return an array of Primitives that matches the input (so, the first item in the id collection should result in a Primitive at array index 0, etc). If an element of the array is left null, that means to delete the Actor corresponding to that PrimitiveId. Your ActorBuilder is then called to allow you to create the new replacement Actors.

You can also specify a region of the Earth to update in the SpatialExtent, but update by entity is not supported. Updating very large areas can be expensive, so use spatial regions with care. Update by PrimitiveId is the most efficient.

Data Format update and reminder

NikolaiF — Wed, 10 Jun 2009 01:07:00 GMT

You may recall that I posted about a data format change for the new version. The final switch-over is going to happen July 9th. If you are still using an old version, models will stop displaying. So upgrade now, the new version is better anyway.

For those already on the new version (assembly version 4), you do not need to change anything at all.

The plus side is that all of you developers have, for reasons of compatibility, been getting the old data for some time now, even if you have upgraded (right now, only Bing Maps gets the new data, everyone else gets the old). On that date you will automatically start getting the new data, and yes you will notice.

WMS Data

NikolaiF — Tue, 09 Jun 2009 20:21:00 GMT

I was having a discussion with Kurt Guenther from Infusion yesterday on the topic of WMS servers and VE3D. There is a large amount of very interesting spatial data out there served by Web Map Services, or WMS servers. VE3D is able to process this data using ConnectionParameter-based DataSources. Setting it up is pretty easy:

ConnectionParameters cp = new ConnectionParameters(http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Portland/Portland_ESRI_Neighborhoods_AGO/MapServer/export?bbox={16},{17},{18},{19}&bboxSR=4326&layers=&layersDefs=&size=256,256&imageSR=102113&format=png&transparent=true&dpi=&f=image);

string connectionParameters = cp.ToString();

DataSourceLayerData layerData = new DataSourceLayerData(LayerName, Name, connectionParameters, DataSourceUsage.TextureMap);

Host.DataSources.Add(layerData);

Drop this in to your Activate (plug-in) or Initialized handler (winforms etc) app and fly to Portland, OR to see the data (thanks to ArcGIS for the sample data and Kurt for the pointer).

I won't go into all the details of the WMS spec here, but I will call out a few important parts. First, in order for this to work you must specify the bbox to be in Geographic coordinates (4326). This is usually the default. Second, you must pay attention to the returned projection. In the above case, we have instructed the server to return 102113, which is Web Mercator, VE3D's native image projection. This data can be consumed directly with very little overhead. However, different servers support only certain formats and projections, and you must be careful for any particular server (it is possible to query this using WMS's GetCapabilities). Nearly all support returning images in Geographic coordinates, 4326. It is possible to instruct VE3D to reproject this to Web Mercator (this is the only reprojection VE3D will do for you, fortunately it will work for the majority of data).

Now, to look at ConnectionParameters and what it can do for you. First, there's the big url. Notice that the bbox has string.Format replacement variables in it: {16}, {17}, etc. Requests to the server are made on a per-tile basis (the T key is useful here). For each request, these variables are replaced with data specific to the tile in question. Here is a list of available parameters:

0 Reserved

1 Map Style

2 Round-robin integer

3 Reserved

4 Quadkey

5 Extension

6 Generation

7 Stripe (0-3)

8 Tile Host

9 App Host

10 Language code

11 Region code

12 Tile LOD

13 Tile X

14 Tile Y

15 Low order stripe (0-1)

16 MinLong

17 MinLat

18 MaxLong

19 MaxLat

20 RequestToken

21 Culture name

The most interesting ones are 4 (the main quad-key, very useful for already-tiled data), 12, 13, 14, and and 16-19. To see some of this in action, check out the TerrainImages sample (also available in the sample code of course). Programatically, you can investigate these values using the TileId class, using GetRequestCode, GetPosition, and GetLatLonBoundingBox.

As for other values on ConnectionParameters, you can control reprojection (if your data is in Geographic, specify CoordinateReferenceSystem = WGS84CoordinateReferenceSystem.Instance, as noted before this is the only reprojection natively supported, so otherwise leave this field uninitialized), the bounds of where the data is valid is terms of Lat/Long and LOD (useful to reducing unnecessary network requests), and caching behavior.

Caching behavior deserves special discussion, because WMS servers are often quite slow. By default, data loaded using ConnectionParameters is not cached locally. Once it moves out of memory, it must be re-queried. If you set CacheRetention however, the data will be kept locally for the period of time specified (unless it is evicted due to space restrictions in the interim). If you set CacheRetention = new TimeSpan(24, 0, 0), for example, for 24 hours from the time of query a given tile will not be re-queried. Note that some servers are dynamic, such as weather data, so it's important to use an appropriate value here.

And just to give Kurt a poke in the ribs, please remember to only add DataSources after/during the Initialized event!

Update:

John Fletcher from Latitude Geographics pointed out that the example I give above isn't actually WMS compliant in its query parameters. He suggests an alternate sample, of the British Columbia, CA area:

ConnectionParameters p = new ConnectionParameters("http://openmaps.gov.bc.ca/mapserver/libcwms2?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=DBM_7H_MIL_BATHYMETRIC_POLY,BC_LABEL,DBM_7H_MIL_DRAINAGE_LINE,DBM_7H_MIL_DRAINAGE_POLY,DBM_7H_MIL_ROADS_LINE,DBM_7H_MIL_POLITICAL_POLY_PS,DBM_7H_MIL_POPULATION_POINT&STYLES=,,,,,,&SRS=EPSG:4326&BBOX={16},{17},{18},{19}&WIDTH=256&HEIGHT=256&FORMAT=image/png&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_inimage&");

p.CoordinateReferenceSystem = Microsoft.MapPoint.CoordinateSystems.Wgs84CoordinateReferenceSystem.Instance;

Host.DataSources.Add(new DataSourceLayerData("foo", "bar", p.ToString(), DataSourceUsage.TextureMap));

John also provided a link to the WMS spec repository (http://www.opengeospatial.org/standards/wms). Note that the sample above is for WMS 1.1.1. The most current version is 1.3.0, but many servers use the older, or support both. No matter which you use (or even for something a little off spec like my original example) the interface with VE3D is the same.

Modifying cache location

NikolaiF — Tue, 09 Jun 2009 20:06:00 GMT

My, it has been a long time since I posted. I promise I will try to be better.

Recently I was asked if it is possible to change the location of the cache file. It is, with certain minor restrictions. You can change the location by adding this to user.config:

Or, when creating the GlobeControl directly, pass in a GlobeControlInitializationOptions object with PersistentCachePath set.

In either case, you can either specify a full path to anywhere, or a relative path from the current location (\AppData\LocalLow\Microsoft\Virtual Earth 3D\).

Putting the file outside LocalLow will cause problems when running in IE7/8 protected mode (Vista/Win7 with UAC on). For a WinForms or WPF-based solution, it’s fine. In such a case, the GlobeControlInitializationOptions setting is generally preferred as it will prevent problems when running Bing Maps on the same machine. On the other hand, this will also cause two caches to be written, one in the default location and containing data from runs in Bing Maps, and one in the specified location. The best approach depends on your exact usage.

New Version Released!

NikolaiF — Fri, 10 Apr 2009 01:46:00 GMT

Our new version has gone live. Head on over to maps.live.com and click "3D" to upgrade. This release is billed primarily as a perf and bug release because it doesn't add a lot of new features at the end-user level (though I think you will be pleased with the perf improvements), but we did have time to throw in some good stuff for the devs.

I've updated the Samples entry, and clicking on the link should get you the new sample set. As usual, please pass along any problems in comments or blog feedback. The samples are mostly the same, with a few new additions, but they have been cleaned up for best practices and new features. I do recommend that you take a glance at them even if you're already familiar with the API. The Camera sample is most changed, and hopefully should help explain the flow of camera control a little better.

Get the code!

Here's a sampling of new and expanded areas:

Initialized event
A new event on RenderEngine that simplifies the startup scenario. Check out SimpleForm to see it. Remember that use of this event or FirstFrameRendered is now required!

Anisotropic Filtering
Greatly improves the appearance of terrain when at an angle. It's off by default, since there are some graphics cards that don't play nice with it (usually old and rare, but still). You can turn this on through the website in the options box, or you can set it programmatically. See SimpleForm.

Dem Data
The ability to supply custom DEM data, and have it automatically stitched into existing data. Previously DEM datasources did not work very well, mostly because we did not automatically stitch. They are still a bit trickier than imagery, but there's a new sample DemData to help you out.

ILocationListener
An interface that allows automatic and efficient query of a location to determine elevation as data changes. ActorDataSource now uses it. Essentially, you register this object and report its Lat/Lon position. If the ground or other solid object moves or changes there, you will get a call to update.

Manual Rendering
Manual render functions that allow use your own thread as the render thread, good for offline rendering or incorporation into another product. RenderEngine.ManuallyInitializeRender and ManuallyRenderNextFrame.

Datasource ConnectionParameters
Helper function for specifying data sources without a content manifest. The string parameter was very hard to use, this is nicer. There are also a few new options, like allowing caching of data specified this way. See TerrainImages.

CelestialStyle
Allow display of a stylized sky with constellations. This is used on the website in Road Mode, but you can set it yourself. See SimpleForm.

Versioning
Support for running code built against previous control versions, if it meets certain requirements. I've outlined this in http://blogs.msdn.com/virtualearth3d/archive/2009/04/01/upcoming-new-version.aspx. To show it working, I've set up a page with samples built from the previous version and from the new version. Both sets work just fine with the new release.

Pixel-width lines
GeometryManager supports pixel-width 3D lines (previously only single-pixel or meter-width). See the Camera sample. We also now have nice looking text labels. See the XFile sample.

Constant value datasources
Helper functions for supplying flat color or elevation data. The Mandelbrot sample uses one to display flat elevation. Please note that a DEM and an Imagery datasource are actually required for proper display. These constant value sources are useful for this case.

Terrain Scaling
WorldEngine.Min/MaxElevationScaling. It is actually possible to have varying scale based on your altitude, but there is some cost associated and I recommend that you set the two values equal to each other. Our default value is 1.0, unscaled.

Override Loading Screen
You can now render (or suppress) the loading screen (affectionately known as "The Circle Of Hope" since our first version, back when the startup flow was a bit less stable than it is now). In the very simplest case, write this:

class MyControl : GlobeControl
{
    protected override void OnPaintLoading(...)
    {
    }
}

This will get you a black screen. You can also grab a reference to the control's Graphics object from the PaintEventArgs and draw anything you like.

Building culling value
Allows control of how many buildings are displayed, based on distance and size of the buildings. WorldEngine.BuildingCulling. The effectiveness of this varies on hardware -- some hardware benefits a great deal, some very little.

Turn on/off street level navigation
Can turn off some of the special navigation effects that occur when right next to the ground, such as sticking to the ground, and the screen drag regions on the sides of the screen when at low altitude. WorldEngine.Enable*.

We have not yet updated the docs. However, we did not make many fundamental changes to the code from an API perspective, and in fact existing code is as much as possible exactly the same. So it is just lacking detail on the new features, and still a good reference.

Upcoming new version

NikolaiF — Wed, 01 Apr 2009 21:29:00 GMT

Next week we'll be releasing a new version of the control. The focus of the release is on perf and bug fixes, but it also adds a set of interesting new functions for managed code developers. I'll be posting updated samples, and more detail on the changes, when the control goes public.

But will it break me?

This is of course the biggest question for most devs, and the reason why you're getting a heads up. We've tried hard to minimize breakage. The main differences between this update and the previous is that we've maintained binary compatibility for the "public" assemblies, and are also including version redirect assemblies. The upshot is that if you are only hitting public members in those assemblies, your code should continue to function without a recompile. If you are hitting other assemblies, you will have to recompile.

Here are the public API assemblies:

Microsoft.MapPoint.Data.dll
Microsoft.MapPoint.Geometry.dll
Microsoft.MapPoint.Rendering3D.dll
Microsoft.MapPoint.Rendering3D.Utility.dll
Microsoft.MapPoint.UtilityPartialTrust.dll

Note that these are also the assemblies accessible to partial trust.

There is one caveat to the compatibility story, and that is startup. This is significant enough that I posted about it already. If you haven't looked at this yet please do so. But overall I think the transition will be easier this time around, and we aim to make that better as we go.

As usual I will be available via the comments section or blog feedback to help with any issues. Thanks!

WPF and VE3D

NikolaiF — Wed, 11 Mar 2009 22:10:00 GMT

I do love having a developer community out there. We've had lots of requests for direct WPF integration of VE3D, and we've certainly wanted to make it part of the story... and then someone else just goes and does it. Marc Schweigert called this to me attention yesterday. Infostrat has taken VE3D and wrapped it up in a WPF control that you can just drop right into your XAML, which is precisely what folks have wanted out of it.

But it gets better. Infostrat has also put this project, including the source, onto CodePlex under LGPL. I've downloaded the source and built myself with no problems. You just need VS 2008 and .NET 3.5 SP1. The central problem and the trickiest part for most folks is how to efficiently get VE3D to composite into the rest of the WPF app, and they've done a good job. For more sugar, they also have a Surface version with multi-touch support.

Many thanks to Josh Blake, the primary developer on the project, and the Infostrat team. Have fun!

Multitouch in VE3D

NikolaiF — Wed, 04 Mar 2009 21:24:00 GMT

Ever since I got a Touchsmart at home I've been very interested in the desktop touch experience, and so in the last couple days I decided to play with how I could incorporate it into VE3D. The code itself isn't really ready for consumption, but if you'd like to see where I'm at, I've built a very preliminary plug-in that you can install and play with.

Download

This requires Windows 7 and a machine that has multitouch support, such as a Touchsmart or Latitude XT. The package is a self-extracting zip, just run it and accept the defaults. The next time you launch VE3D, the plug-in will load shortly after startup. There's no UI or anything. The gestures will just quietly start working. The plug-in will work on any app that uses GlobeControl (and loads it), but since it calls native code it does require installation.

Currently supported are two-finger zoom and two-finger rotate. I'm using the built-in gesture engine from Win7, which makes things very easy, but in the future I would like to use direct touch input instead. This should eliminate a few artifacts like a momentary delay between when you start input and when the map starts moving. It should also allow support of some more interesting types of inputs, like a two-finger pan, combining rotate and zoom into a single fluid motion, etc. The point is that there's a lot of potential beyond what I've done here.

The touch interface in Win7 relies on Windows Messages and a few native functions. To listen to Windows Messages, use Host.CommunicationManager.AttachToMessage. To interact with the native gesture API, here's something to get you started (this code will work just as well in any managed application). After that it's a matter of redirecting gestures to existing navigation Actions using bindings. To really do it right you'd probably also want to write a few things in your own CameraController.

Here's the gesture documentation on MSDN. Here's the raw touch docs.

Note: there's a bug in the current GlobeControl where the lParam and wParam values are reversed in the handler to AttachToMessage. Whoops! This is fixed in the next version, so be prepared. I will be releasing my code as a sample at that time, and will update the installer as well.

Note 2: I noticed on my Touchsmart that the rotate gesture has some trouble when your fingers are diagonal relative to the screen. I think this is a driver thing, since it doesn't happen on the Latitude XT, which uses a different touch technology and, obviously, different drivers. However, it looks like they are releasing improved drivers on Windows Update, so I hope this is just a bleeding edge thing.

Edit: the "Download" link has been updated to a version that is compatible with the current build on Virtual Earth 3D. Please uninstall the old version first and then install the new one. Functionality is still the same, that is to say, less than ideal. From what I have seen, using WM_TOUCH instead of WM_GESTURE will provide a far superior experience. Stay tuned.

Startup and Host interaction

NikolaiF — Sat, 21 Feb 2009 22:39:00 GMT

When the control first starts, there are several stages that need to complete before it is really ready.

1 Construction. This occurs when you call GlobeControl's constructor.

2 Initialization on the UI thread. Some objects can initialize themselves here. This happens when the control starts receiving windows messages.

3 Initialization on the Render thread. Other objects need information from the graphics system, which must happen on the render thread to keep DX happy.

4 Start rendering. The control is now ready to go.

If you start playing with the control before it's done, accessing properties and functions on the various Host objects, you can get bad behavior. You may get an error, and you may not. In the current version, there is no validation for this, so you might be fine, or there could be subtle or rare badness. To get past all of this, you should hook up to the Host.RenderEngine.FirstFrameRendered event and do all of your GlobeControl-related setup there, like adding DataSources and PlugIns, really everything should happen in or after the event. Properties that derive from Control (the winforms class), such as Height and Width, are ok.

In the next version, we will be validating startup to make sure you don't call most functions until it's ready. You will be able to access the events on RenderEngine right after construction, but that's all you should do. There will be a new event, Initialized, to make this process more obvious and logical.

So I encourage everyone to hook up to the FirstFrameRendered event now. If you're not using it, you may be broken and not realize it. In the next version, you will definitely be broken. The FirstFrameRendered event will still be available, and there will not a big difference between it and Initialized, but Initialized will be the best practices way of doing it.

We have tried hard to minimize breaking changes for the next version, and in fact I can't think of any others off the top of my head, but for this we decided it is for the best.

Microsoft Photo Calibration Tool

NikolaiF — Wed, 11 Feb 2009 22:16:00 GMT

Siddharth Jain, one of the devs on our team, wrote a tool using VE3D to place photos in 3D and save this information as a tag in the file itself. In short, you open a picture in the program, fly to roughly where the picture was taken from, click on points in the world and in the photo that you know are the same (for example, the chimney of a house, or the edge of a lake), and the program tries to determine where the picture was taken from. You can then view this picture in the world.

We have a picture that another dev on the team took in Las Vegas for you to play with. This picture already has some rough information in it to help you get started, and it might be a good idea to start with it. There's also an image that has already been placed, so you can see how it might look after you're done (load this picture into the tool instead of the first one to see it). Generally speaking your own photos will probably not have any positioning information in them to begin with, unless you have a very fancy camera, so it is important that you know pretty much where you were when you took it. Also keep in mind that this is a tool and demonstration, not a finished product.

Here’s Sid’s writeup of the tool. Enjoy!

Install

Download the zip file and extract its contents to any folder (there is no installer program). As long as all four dll/exe files are in the same directory it should just run by double-clicking the exe file.

Introduction

The Microsoft Photo Placement Tool can be used to find the geographic coordinates of the camera that took a photo. In this way a photo can be geolocated in the 3D world. There are seven parameters which need to be determined to geoposition a photo in the 3D world. Six of them are latitude, longitude, altitude, roll, pitch, yaw which define the position and orientation of the camera. The seventh parameter is the focal length of the camera that took the photo. The Photo Placement Tool allows determination of these seven parameters via manually specified correspondences between points in the photo and 3D world.

System Requirements

Virtual Earth 3D (VE3D) must be installed on user’s machine.

Usage

On running the exe following screen is displayed:

Step 1: User uploads a photo by clicking on Load Image button

Any exif information in the image such as GPS position and focal length is automatically loaded.

Step 2: User navigates in VE3D to a position from where s/he can begin adding correspondences

An example screen is shown below:

Step 3: User turns on calibration by clicking on Turn ON Calibration button

When you are ready to begin adding correspondences, click on the Turn ON Calibration button. This sets the initial camera position and orientation, which is then optimized as correspondences are added. To get back to step 2, click on the Load Image button again.

Step 4: User adds point correspondences between photo and 3D world

As the user adds correspondences via left mouse click, the tool calibrates the photo in the background. The Preview Result button is automatically enabled after adding 3 or more correspondences. An example is shown below:

While in calibration mode it is still possible to navigate in VE3D using the arrow keys, and change the view by holding the shift and ctrl keys while dragging with the mouse. Normal mouse drag is disabled in this mode.

Step 5: Preview the result by clicking on Preview button

When the RMS reprojection error becomes small (say less than 20 pixels), preview the result by clicking on Preview button. The smaller the error, the better the preview would be.

Step 6: Either Accept the result or Revise

User can either Accept or Revise. Clicking on Accept will display the solution and prompt user to save the calibrated photo as a JPEG. The latitude, longitude, altitude, roll, pitch, yaw, and focal length are saved as EXIF tags in the JPEG. Roll, pitch, yaw are relative to the local coordinate system at (lat,lon,alt). All angles (lat, lon, roll, pitch, yaw) are stored in degrees. Next time the photo is opened in this tool, the camera will automatically fly to that location.

By clicking on Revise user can continue to add more correspondences and refine the result. Note that as more correspondences are added, the RMS reprojection error may become better or even worse.

Miscellaneous Features

Use Locate feature to quickly fly to a location e.g. New York

Use the Locate button on the Menu to quickly fly to a location e.g. New York

Deleting a pushpin

Move mouse pointer over pushpin. Its color changes. Press delete key to delete the pushpin. Note that deleting a pushpin also deletes the corresponding pushpin, if any, in the other view.

The Settings Window

By clicking on the Settings button, user can control the parameters to optimize. The user would generally not need to change the default settings. However, for completeness the options provided by this window are described here. If the altitude option is unchecked, the tool will not optimize the altitude of the camera. For example, if you took a photo from the ground and have positioned the Virtual Earth 3D camera on the ground, you may want to uncheck the altitude button as the correct altitude has already been set by you. Similarly, if the focal length option is left unchecked, the tool will not optimize the focal length of the camera. You may want to do this, for example, when you are sure that the EXIF focal length is the correct focal length.

Technical Note: user may find that when a calibrated photo is opened, the camera does not fly to the exact calibrated location. Usually when this happens the camera is positioned too high. This is because the background data in the area, specifically the DEM, is not yet fully loaded, and the program wasn’t able to get to the right spot. Loading the image again should correct the problem.

Acknowledgements

Bill Chen in VE3D Research originally developed a photo geopositioning tool. His work can be found here. The present tool has been developed from scratch and is 100% managed code. I would like to acknowledge Nikolai Faaland, David Buerer, Bret Mulvey for helping me out on this project. David Buerer provided the Hilton Las Vegas image used in this writeup. Jonathan Doughi provided the Smith Tower image used in the writeup.

Documentation!

NikolaiF — Sun, 25 Jan 2009 22:21:00 GMT

Due to the outstanding efforts of our team's tech writer, we've produced some lovely help documentation and are able to share it with you, the intrepid VE3D dev community. Why intrepid? Well, at least some of you coded for some time and did some impressive work without even the intellisense files! Even I think that takes dedication (and I'm not really being self-deprecating or anything, any signficant codebase is hard to work with when all you have is function names). Lots of folks have asked for some more standard documentation files, and now we're able to deliver.

Here they are!

As always, let us know if you have any trouble or suggestions. Some of the usual caveats apply. Both the API and documentation are still in beta form and are not officially supported. That said, still make sure to let us know about what you want to do, issues you encounter, etc, and we'll do our best to help you out.

Update: the link now points to a zip file, which should bypass the "blocked" issue with the chm.

Busy busy busy...

NikolaiF — Sun, 11 Jan 2009 22:31:00 GMT

I haven't posted in quite awhile, as development on the next version has been pretty intense. However, we are still monitoring the blog feedback and comments, so don't feel as if VE3D or the blog is being neglected. When I have time I will be getting back to writing.

Happy New Year!

Oh, one thing: apparently in the Win7 Beta (which I just installed on my TouchSmart at home... it is so far very stable and complete and I have been quite happy with it) there is a permissions issue with the LocalLow directory that may cause VE3D to encounter an error on startup. This is in IE8 in Protected Mode. There is a workaround. From an elevated prompt, run this command:

Icacls c:\users\<username>\appdata\locallow\microsoft /setintegritylevel low

We are of course working with the Win7 team to make sure there are no problems when our respective products reach release.

Information Pop-ups in WinForms

NikolaiF — Tue, 25 Nov 2008 00:47:00 GMT

We've had several questions about how to do a pop-up form in WinForms, similar to the one on the website. The website pop-up is implemented entirely within the browser, using an IFrame. Therefore, the functionality does not exist by default in the managed code alone. However, the events you need are provided, and creating your own pop-up is not difficult.

The event you need is EngineEvents.OnHover, accessed via the CommunicationManager. It will fire when the mouse hovers over any GeometryManager object that has hit detection on. The event arguments (CommunicationParameters) tell you which item was hovered and where on the screen it is. I used the Tag property on WorldGeometry to hold the name and description I wish to display, so when I get the hover event I retrieve the item back again and pass the tag to my Popup form.

The next step is to render the form. There are two behaviors we want: first, the auto-closing. This was pretty simple to do using a Timer. When you get an OnHoverEnd (another EngineEvent), start a timer. If the mouse moves into the popup, stop the timer. When the mouse leaves it, start the timer again. The second behavior is rendering HTML. This was trivial on the website, but a little tricker in winforms. Fortunately Windows ships with mshtml, which has a ready-made browser window. I based my work on this, and had it working in just a few minutes.

I'm certain all of this could be done more attractively and elegantly, but it should get you started. I updated the main samples package to have the new HtmlForm project. Just grab the zip file again and pull out that project directory.

Get the code!

P.S. If you want to open an ERO from a plug-in without having to go through the JS API first, do this:

CommunicationParameterSet set = new CommunicationParameterSet(8);
set.Add("layerId", null);
set.Add("pushpinId", null);
set.Add("rX1", p.X);
set.Add("rY1", p.Y);
set.Add("rX2", p.X);
set.Add("rY2", p.Y);
set.Add("header", name);
set.Add("content", desc == null ? string.Empty : desc);
Host.CommunicationManager.FireEvent(EngineEvents.Group, EngineEvents.OnHover, set);

p is the location on the screen you want it, name is the title, and desc is your html content.

VE3D on a Mac

NikolaiF — Sun, 23 Nov 2008 21:10:00 GMT

Parallels, which is a program that allows running Windows software on a Mac, has recently released version 4, which has support for DirectX 9.0. This means that Mac users can now see VE3D in all its glory. Well, most of it anyway. I don't have a Mac in my office to test with, but it kind of sounds from the description like it emulates DX in software. If I'm wrong about that someone please correct me. It also only supports up to pixel shader 2.0, which means that a few of the advanced features like weather will be off by default (you can turn it back on though if you go into the options page and click the local weather checkbox). Again, I'm not able to test, but I see no reason why plug-ins or apps written with VE3D wouldn't work as well.

http://www.digitalgeography.co.uk/archives/2008/11/parallels-4-brings-live-maps-3d-to-the-mac/

I also encourage any Mac users out there to check out World Wide Telescope, it is well worth it.