Hello all,

When we announced that we're "discontinuing investment" in VE3D earlier this year, many of you expressed concern that this would mean you can't use VE3D anymore.  I deal with technical issues, so let me address those.  There's certainly nothing time-bomby in the code, so it'll keep right on functioning as it always did.  The obvious concern is that VE3D is very much a web-connected bit of code, and what happens if the servers we run get turned off?

Well, the first thing to say is that we really have no reason to turn them off.  Most of the data VE3D uses is also used in our other products, and that which isn't doesn't represent a significant cost in server capacity.  But that's not a technical thing to say, is it?  And I said I deal with technical issues, so what DOES happen if the servers get turned off?

If you're using the built-in default data sources, VE3D stops working.  It won't crash or anything, but it'll be pretty boring:  no data, nothing to see.  But, as you know, you can replace those data sources quite readily.  So it should be easy to just point it somewhere else, right?

Well, slight complications, then good news and bad news.  The complications stem from the fact that we never designed the system from the ground up to be completely separated from the mothership.  So, the system does make some assumptions about what servers it can see.  Fortunately, using Reflection you can do just about anything, and I've put together a Windows Forms sample that controls (or removes) those assumptions on a flag-by-flag basis.

The good news is that by using the right combination of flags, you can have the code run only against servers you control, or even against no servers at all, using only locally stored/generated data.  In these configurations you no longer care if our servers are on or off, and the code is easily copy/pastable into your own projects (just pay attention to where each flag is implemented in the startup process).

The bad news is that Weather, DEM, and Model data is a bit tricky.  I haven't spelled out precisely how to supply your own data, because unlike web mapping imagery data there really isn't a standard, even a de facto one.  So I provide pointers in the code to where you need to look to write your own sources, but you'll need to do the lifting on your own.

Here's where you can find the code.

Have fun, and please contact me with questions and comments.  Thanks, it's been great!

We have just announced that we will be discontinuing investment in VE3D.  In the short term, the 3D view will be removed from bing.com/maps.  The 3D control itself will continue to function, and data will continue to be served to it.  The support will continue until December 2011, and during that time it will still be in the AJAX map control (version 6.3) for 3rd party use.  I will personally continue to monitor the comments sections and the contact link, so you can keep sending me questions.

Thanks for all the great comments, feedback, and questions over the last two years.  It’s been a lot of fun and I’ve really enjoyed working with you all.

Here is the announcement:

https://www.bing.com/community/site_blogs/b/maps/archive/2010/11/02/changes-to-bird-s-eye-and-3d-maps.aspx

 Host.WorldEngine.Environment.Weather.Clear();

// specify the type of clouds you want, their density (0 to 1), and their altitude in meters
CloudLayer cloud = new CloudLayer(CloudType.CumulusHumilis, 0.3f, 2000);

// specify the layer you want, its level (strictly speaking the altitude does not have to be in order
// of the layers, but it helps to keep them organized), and a timestamp for when the data is
// relevant -- for automatically generated data like this Now is sufficient.
// Wind and rain are not implemented.
WeatherLayer layer = new WeatherLayer(cloud, CloudLayerLevel.Low, DateTime.Now);

// To add weather evenly everywhere, use LatLon.Empty.  To add a specific location, specify that location.
// The closest points to the camera's position will be used to determine actual weather.
WeatherPoint weather = new WeatherPoint(LatLon.Empty, layer);
Host.WorldEngine.Environment.Weather.AddPoint(weather);

Here's a view of a two-layer cloud system:

You can find some sample code here.

Have you seen the Microsoft Surface Globe application in the Microsoft Touch Pack for Windows 7?  There are plenty of videos of the app in action on YouTube: https://tinyurl.com/YouTubeSurfaceGlobe.

Would you like to build an app like this yourself?  Thanks to InfoStrat.VE, you can! Josh Blake just announced the R2 release of InfoStrat.VE.  Amongst other improvements, it includes support for the same touch interaction on Windows 7 you have available in the Microsoft Surface Globe app.  Full details on Josh’s blog:

https://nui.joshland.org/2010/01/infostratve-release-2-is-now-up.html

 Via Marc

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 :)

The main installation msi files are available at:

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

https://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:

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

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

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

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

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.

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.

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!