Virtual Earth 3D team blog : Bing Maps 3D

Two good questions

NikolaiF — Tue, 08 Dec 2009 18:52:00 GMT

Posting some answers to questions I've gotten recently.

Bug in the samples:

Kind of silly that I hadn't noticed this until now, but there's an error in the sample html for most of the samples. The name of the functions used for plug-in load and activate conflict with an internal name used in the AJAX code. Change "On3DPlugInLoaded" and "On3DPlugInActivated" to any other name, for example "PlugInLoaded" and "PlugInActivated". Remember to change both your function name and the string passed to AttachEvent.

Zoom or Rotate around a point:

There have been several requests about how to allow people to zoom or rotate around a particular point on the screen, rather than the center. The code here isn't as cleaned up as I normally like it, but it illustrates the ideas. You can do the rotate by purely calling built-in VE3D functions via the bindings system, but zoom requires a bit more work. To run the code, replace files in the Multitouch sample with the files in the zip. You will want to call or adapt the calls to GestureEventSource to be in response to your inputs, rather than the worker thread I created.

Remember you can contact me any time via the contact form, or if you prefer via comments. Even if it looks like I haven't posted recently :)

Installing VE3D without the setup package

NikolaiF — Sun, 27 Sep 2009 22:53:00 GMT

In some scenarios it may be desirable to install the VE3D engine without visiting the www.bing.com/maps site, and/or to avoid the individual downloads that the setup package performs (eg offline or enterprise installations).

The main installation msi files are available at:

http://go.microsoft.com/fwlink/?LinkID=117319 for x86

http://go.microsoft.com/fwlink/?LinkID=117320 for x64 systems

If installed this way, the pre-requisites must already be installed: the .NET 2.0 Framework and Windows Imaging Components. Vista and Windows 7 already have both of these by default, for XP the latest versions are available by searching for them on the Microsoft Download Center.

For convenience, here are some links to the prerequisites:

http://go.microsoft.com/fwlink/?LinkID=106132 .NET 2.0 x86

http://go.microsoft.com/fwlink/?LinkID=106134 .NET 2.0 x64

http://go.microsoft.com/fwlink/?LinkID=101060 WIC x86

http://go.microsoft.com/fwlink/?LinkID=101061 WIC x64

Hosting VE3D in native code

NikolaiF — Thu, 24 Sep 2009 21:54:00 GMT

Sorry for the glut of posts this week. I hadn't been able to write much, but there were still interesting topics and questions coming up and I'm trying to address that backlog now. So, without further ado:

It is possible to host VE3D in a variety of contexts, and so far we've seen WinForms, WPF, and the browser. It is also possible to host in straight native code. In this sample, I address the COM interactions needed to host VE3D, and use OpenGL as an example hosting environment.

Download the code here.

This sample demonstrates four concepts:

Interaction with native code.
Back buffer retrieval.
Direct camera control.
OpenGL integration.

Native code:

Managed code provides easy and convenient methods for exposing your code to COM, and hence to native callers.
From the managed side, check "Register for COM interop" in your project's Build tab. Decorate an interface
with ComVisible(true) and provide a guid, and the backing class with the interface type as shown. Your types
are now visible and callable.

On the native side, you can now instantiate your managed code using typical COM calls, as shown. It can then
be called similarly to any other object.

To add a new function to the interface, simply add it to the interface file and the backing .cs file, then
recompile. By designing your interface in appropriately, you can then decide whether to do most of your logic
in native or managed code, depending on where you feel more comfortable.

Backbuffer retrieval:

The Render function provides the most efficient way of pulling VE3D's back buffer into main memory. In general
it is better to not do this, rather let the hardware render to the screen directly, but some situations demand
using the scene in some other fashion. Here, we get the memory as a direct pointer. Note that this approach
assumes that you are handling any format and stride issues yourself.

It is also possible to get a graphics object from systemMemorySurface, an HDC from that, and then use functions
like BitBlt to copy out data and handle some of these issues for you.

Direct camera control:

Most samples thus far have demonstrated use of bindings and actions, or deriving camera controller. The
CameraController class here shows how to write a controller that can react directly to user input, modifying
camera values directly. The "best practices" method is to wrap your input device in a EventSource, and use
bindings and actions to communicate the information to your controller. These structures provide simple
remapping of inputs, if necessary, and handle any threading or marshalling issues.

However, it is also possible and sometimes appropriate to take the simpler approach used here.

OpenGL integration:

It is possible to integrate VE3D into an existing OpenGL application. Using the Render method described above,
the pointer produced is suitable for direct consumption by OpenGL. There are differences in how textures are
handled by the two APIs, but these are fairly simple to overcome, and are described in DrawOpenGLWindow().

Note that there is nothing that limits this sample to OpenGL, anything that can consume the buffer as provided
can host VE3D in the exact same manner.

Note on debugging:

The Visual Studio debugger requires some direction on how to deal with mixed native and managed code.
In the VE3DOpenGL properties page, expand Configuration Properties, click Debugging, then choose Debugger
Type. You can elect to only attach to native, only to managed, or to both ("mixed"). "Auto" in this case
will be native-only. If you find your breakpoints are not hitting, it is likely this setting.

Note on glut.h:

For some reason, in the release version only, I managed to get it thinking that it needed glut and I haven't
been able to figure out why. If you encounter problems while compiling due to glut, just run in debug mode.
This is a problem that is specific to the sample app, not the methodology used.

Enjoy, and as usual please let me know about any questions or problems you may have.

X File bulk display

NikolaiF — Mon, 21 Sep 2009 00:42:00 GMT

I was asked the other day about how to load multiple x file -based models into VE3D without having to place each one manually. I've written up a sample here. The idea is more or less a fusion of the existing ActorDataSource and XFile samples, using the actor from the XFile sample rather than the bunnies. I've also mocked up a very simple data file that contains placement information, rather than generating data on the fly as for the bunnies.

The way I've done this, the parsing code for the x files is done in the actor. In this way, swapping out file formats should be straightforward so long as you have parsing code for it (sorry, only x files are directly implemented in the engine, but the results of any parse should still be easily convertible into VE3D graphics objects).

For the sake of simplicitly I did do one thing wrong. The flow of the code is like this: multiple background threads all execute QueryPrimitivesInternal at the same time, and when they are finished, they move through a lock into ActorBuilder. They are still on background threads, but they now execute serially. So, really the data retrieval (in this case, loading from resources, but probably a network request) and the parsing, as appropriate, should happen in QueryPrimitivesInternal, and the action in ActorBuilder should be kept to a minimum. I violated this rule in the sample code for the sake of illustration, but you should be aware of it.

Finally, an important consideration is level of detail. Dense and numerous models can slow down loading and rendering. DataSources take advantage of the ActorBounds and scale concepts, such that it is possible to use simplified models at certain LODs, and switch to more detailed as the user zooms in. If your needs are less extreme, then you can simply use scale to cause models to stop rendering when not in view, and at a certain distance, which is what I have done in the sample.

Have fun!

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.

Bing Maps 3D

NikolaiF — Sun, 14 Jun 2009 21:07:00 GMT

As you may be aware, the website changed names to Bing Maps: http://www.bing.com/maps/. The 3D view on the site is now called "Bing Maps 3D".

As a developer it doesn't change much for you, and in terms of the engine/SDK it's still valid to refer to it as "Virtual Earth 3D". The only technical issue I can think of is to repeat that it's a good idea to use fwlinks for the urls for our base layer data, as explained at the end of the post here.

Thanks!