“Hello World” Mixed Reality Demo from the UK TechKnowDay Event 2018

I had the privilege to be invited to speak at the UK TechKnowDay Event today as part of International Women’s Day;

and I went along with my colleague, Pete, and talked to the attendees about Windows Mixed Reality.

As part of that, I’d put together a very simple “Hello World” demo involving taking a 3D model of an avatar who appeared when air-tapped on a HoloLens and then fell with a parachute to the floor. This is really just a way of showing the basics of using the Unity toolkit, the Mixed Reality Toolkit and Visual Studio to make something that runs on HoloLens and which blends the digital with the physical.

At the event, we shortened the demo because we were running a little low on time and so I promised to include the materials on the web somewhere and that’s what this post is about.

First, I made 3 models using Paint3D and so I wanted to include that little video here – it’s intended to be spoken over so there’s no audio on it;

and then there’s a little video showing me working through in Unity to bring in the assets from Paint3D and add some very, very limited interactivity to them using Unity and the Mixed Reality Toolkit.

The way the app is supposed to work is that an air tap will cause the creation of an instance of the avatar. She will then fall under (reduced) gravity landing on a surface when her parachute should disappear and then she might sort of ‘snowboard’ to a stop where her snowboard should also disappear Smile

I’m not sure that anyone would want this coding masterpiece Smile but if they did then it’s on github over here;


Feel very free to re-use, share or whatever you like with this if it’s of use to you.

Baby Steps with Spatial Mapping in 2D and 3D Using XAML and SharpDX

NB: The usual blog disclaimer for this site applies to posts around HoloLens. I am not on the HoloLens team. I have no details on HoloLens other than what is on the public web and so what I post here is just from my own experience experimenting with pieces that are publicly available and you should always check out the official developer site for the product documentation.

I’ve been living in fear and hiding from a particular set of APIs Winking smile

Ever since HoloLens and Windows Mixed Reality first came along, I’ve been curious about the realities of the spatial mapping APIs and yet I’ve largely just treated them as a “black box”.

Naturally, that’s not to say that I haven’t benefitted from those APIs because I’ve been using them for many months in Unity via the Mixed Reality Toolkit and its support for spatial mapping and the prefab that’s fairly easy to drop into a Unity project as I first explored in this post last year;

Hitchhiking the HoloToolkit-Unity, Leg 3–Spatial Understanding (& Mapping)

That said, I’ve still had it on my “to do list” for a long time to visit these APIs a little more directly and that’s what this blog post is about.

It’s important to say that the post is mostly meant to be just “for fun” to give me a place to write down some explorations – I’m not planning to do an exhaustive write up of the APIs and what I’ll end up with by the end of this post is going to be pretty “rough”.

It’s also important to say that there are official documentation pages which detail a lot more than I’m about to write up in this post.

Spatial mapping

Spatial mapping in DirectX

but (as usual) I hadn’t really read those documents in nearly enough detail until I started to explore on my own for this post – it’s the exploration that drives the learning.

Additionally, there’s a great official sample that goes along with those documents;

Holographic Spatial Mapping Sample

but, again, I hadn’t actually seen this sample until I got well into writing this post and was trying to figure things out and I realised that I was largely trying to produce a much simpler, less functional piece of code which targeted a different type of application than the one in the sample but there are many similarities between where I ended up and that sample.

So, if you want the definitive views on these topics there are lots of links to visit.

In the meantime, I’m going to write up my own experiments here.

Choosing a Sandbox to Play In

Generally speaking, if I’m wanting to experiment with some .NET APIs then I write a console application. It seems the quickest, easiest thing to spin up.

In a Mixed Reality world, the equivalent seems to be a 2D XAML application. I find it is much quicker to Code->Deploy->Test->Debug when working on a 2D XAML application than when working on (e.g.) a 3D Unity application.

Of course, the output is then a 2D app rather than an immersive app but if you just want to test out some UWP APIs (which the spatial mapping APIs are) then that’s ok.

Specifically, in this case, I found that trying to make use of these APIs in a 2D environment seemed to actually be helpful to gaining some understanding of them as it stopped me from just looking for a quick Unity solution to various challenges and I definitely felt that I wasn’t losing anything by at least starting my journey inside of a 2D XAML application where I could quickly iterate.

Getting Going – Asking for Spatial Mapping API Access

I made a quick, blank 2D XAML UWP application in Visual Studio and made sure that its application manifest gave me the capability to use Spatial Mapping.

When I look in Visual Studio today, I don’t see this listed as an option in the UI and so I hacked the manifest file in the XML editor;


where uap2 translates as a namespace to;


in case you ever got stuck on that one. From there, I had a blank app where I could write some code to run on the Loaded event of my main XAML page.

Figuring out the SurfaceSpatialObserver

At this point, I had an idea of what I wanted to do and I was fairly sure that I needed to spin up a SpatialSurfaceObserver which does a lot of the work of trying to watch surfaces as they are discovered and refined by HoloLens.

The essence of the class would seem to be to check whether spatial mapping is supported and available via the IsSupported and RequestAccessAsync() methods.

Once support is ascertained, you define some “volumes” for the observer to observe for spatial mapping data via the SetBoundingVolume/s method and then you can interrogate that data via the GetObservedSurfaces method.

Additionally, there’s an event ObservedSurfacesChanged to tell you when the data relating to surfaces has changed because the device has added/removed or updated data.

This didn’t seem too bad and so my code for checking for support ended up looking as below;

  async void OnLoaded(object sender, RoutedEventArgs e)
      bool tryInitialisation = true;

      if (Windows.Foundation.Metadata.ApiInformation.IsApiContractPresent(
          "Windows.Foundation.UniversalApiContract", 4, 0))
        tryInitialisation = SpatialSurfaceObserver.IsSupported();

      if (tryInitialisation)
        var access = await SpatialSurfaceObserver.RequestAccessAsync();

        if (access == SpatialPerceptionAccessStatus.Allowed)
          tryInitialisation = false;
      if (!tryInitialisation)
        var dialog = new MessageDialog(
          "Spatial observation is either not supported or not allowed", "Not Available");

        await dialog.ShowAsync();

Now, as far as I could tell the SpatialSurfaceObserver.IsSupported() method only became available in V4 of the UniversalApiContract so I’m trying to figure out whether it’s safe to call that API or not as you can see above before using it.

The next step would be perhaps to try and define volumes and so I ploughed ahead there…

Volumes, Coordinate Systems, Reference Frames, Locators – Oh My Winking smile

I wanted to keep things as simple as possible and so I chose to look at the SetBoundingVolume method which takes a single SpatialBoundingVolume and there are a number of ways of creating these based on Boxes, Frustrums and Spheres.

I figured that a sphere was a fairly understandable thing and so I went with a sphere and decided I’d use a 5m radius on my sphere hoping to determine all surface information within that radius.

However, to create a volume you first need a SpatialCoordinateSystem and the easiest way I found of getting hold of one of those was to get hold of a frame of reference.

Frames of reference can either be “attached” in the sense of being head-locked and following the device or they can be “stationary” where they don’t follow the device.

A stationary frame of reference seemed easier to think about and so I went that way but to get hold of a frame of reference at all I seemed to need to use a SpatialLocator which has a handy GetDefault() method on it and then I can use the CreateStationaryFrameOfReferenceAtCurrentLocation() method to create my frame.

So…my reasoning here is that I’m creating a frame of reference at the place where the app starts up and that it will never move during the app’s lifetime. Not perhaps the most “flexible” thing in the world, but it seemed simpler than any other options so I went with it.

With that in place, my “start-up” code looks as below;

  void InitialiseSurfaceObservation()
      // We want the default locator.
      this.locator = SpatialLocator.GetDefault();

      // We try to make a frame of reference that is fixed at the current position (i.e. not
      // moving with the user).
      var frameOfReference = this.locator.CreateStationaryFrameOfReferenceAtCurrentLocation();

      this.baseCoordinateSystem = frameOfReference.CoordinateSystem;

      // Make a box which is centred at the origin (the user's startup location)
      // and is hopefully oriented to the Z axis and a certain width/height.
      var boundingVolume = SpatialBoundingVolume.FromSphere(
        new SpatialBoundingSphere()
          Center = new Vector3(0, 0, 0),
          Radius = SPHERE_RADIUS
      this.surfaceObserver = new SpatialSurfaceObserver();

Ok…I have got hold of a SpatialSurfaceObserver that’s observing one volume for me defined by a sphere. What next?

Gathering and Monitoring Surfaces Over Time

Having now got my SpatialSurfaceObserver with a defined volume, I wanted some class that took on the responsibility of grabbing any surfaces from it, putting them on a list and then managing that list as the observer fired events to flag that surfaces had been added/removed/updated.

In a real application, it’s likely that you’d need to do this in a highly performant way but I’m more interested in experimentation here than performance and so I wrote a small SurfaceChangeWatcher class which I can pass the SpatialSurfaceObserver to.

Surfaces are identified by GUID and so this watcher class maintains a simple Dictionary<Guid,SpatialSurfaceInfo>. On startup, it calls the GetObservedSurfaces method to initially populate its dictionary and then it handles the ObservedSurfacesChanged event to update its dictionary as data changes over time.

It aggregates up the changes that it sees and fires its own event to tell any interested parties about the changes.

I won’t post the whole source code for the class here but will just link to it instead. It’s not too long and it’s not too complicated.

Source SurfaceChangeWatcher.cs.

Checking for Surface Data

At this point, I’ve enough code to fire up the debugger and debug my 2D app on a HoloLens or an emulator and see if I can get some spatial mapping data into my code.

It’s worth remembering that the HoloLens emulator is good for debugging spatial mapping as by default the emulator places itself into a “default room” and it can switch to a number of other rooms provided with the SDK and also to custom rooms that have been recorded from a HoloLens.

So, debugging on the emulator I can see that in the first instances here I see 22 loaded surfaces coming back from the SpatialSurfaceObserver;


and you can see the ID for my first surface and the UpdateTime that it’s associated with.

I also notice that very early on in the application I see the ObservedSurfacesChanged event fire and my code in SurfaceChangeWatcher simply calls back into the LoadSurfaces method shown in the screenshot above which then attempts to figure out which surfaces have been added/removed or updated since they were last queried.

So, getting hold of the surfaces within a volume and responding to their changes as they evolve doesn’t seem too onerous.

But, how to get the actual polygonal mesh data itself?

Getting Mesh Data

Once you have hold of a SpatialSurfaceInfo, you can attempt to get hold of the SpatialSurfaceMesh which it represents via the TryComputeLatestMeshAsync method.

This method wants a “triangle density” in terms of how many triangles it should attempt to bring back per cubic metre. If you’ve used the Unity prefab then you’ll have seen this parameter before and in my code here I chose a value of 100 and stuck with it.

The method is also asynchronous and so you can’t just demand the mesh in realtime but it’s a fairly simple call and here’s a screenshot of me back in the debugger having made that call to get some data;


That screenshot shows that I’ve got a SpatialSurfaceMesh and it contains 205 vertices in the R16G16B16A16IntNormalized format and that there are 831 triangle vertices in an R16Uint format and it also gives me the Id and the UpdateTime of the SpatialSurfaceInfo.

It’s also worth noting the VertexPositionScale which needs to be applied to the vertices to reconstruct them.

Rendering Mesh Data

Now, at this point I felt that I had learned a few things about how to get hold of spatial mapping meshes but I thought that it wasn’t really “enough” if I didn’t make at least some attempt to render the meshes produced.

I thought about a few options around how I might do that given that I’m running code inside of a 2D XAML application.

I wondered whether I might somehow flatten the mesh and draw it with a XAML Canvas but that seemed unlikely and I suspected that the best road to go down would be to keep the data in the format that it was already being provided in and try and hand it over to DirectX for rendering.

That led me to wonder whether something from Win2D might be able to draw it for me but Win2D stays true to its name and doesn’t (as far as I know) get into the business of wrapping up Direct3D APIs.

So…I figured that I’d need to bite the bullet and see if I could bring this into my 2D app via the XAML SwapChainPanel integration element with some rendering provided by SharpDX.

It’s worth saying that I’ve hardly ever used SwapChainPanel and I’ve never used SharpDX before so I figured that putting them together with this mesh data might be “fun” Winking smile

A UWP SharpDX SwapChainPanel Sample

In order to try and achieve that, I went on a bit of a search to try and see if I could find a basic sample which illustrated how to integrate SharpDX code inside of a XAML application rendering to a SwapChainPanel.

It took me a little while to find that sample as quite a few of the SharpDX samples seem to be out of date these days and I asked around on Twitter before finding this great sample which uses SharpDX and SwapChainPanel to render a triangle inside of a UWP XAML app;


That let me drop a few SharpDX packages into my project;


and the sample was really useful in that it enabled me to drop a SwapChainPanel into my XAML UI app and, using code that I lifted and reworked out of the sample, I could get that same triangle to render inside of my 2D XAML application.

That gave me a little hope that I might be able to get the mesh data rendered inside of my application too.

Building a SharpDX Renderer (or trying to!)

I wrote a class SwapChainPanelRenderer (source) which essentially takes the SwapChainPanel and my SurfaceChangeWatcher class and it puts them together in order to retrieve/monitor spatial meshes as they are produced by the SpatialSurfaceObserver.

The essence of that class is that it goes through a few steps;

  1. It Initialises D3D via SharpDX largely following the pattern from the sample I found.
  2. It creates a very simple vertex shader and pixel shader much like the sample does although I ended up tweaking them a little.
  3. Whenever a new SpatialSurfaceInfo is provided by the SurfaceChangeWatcher the renderer attempts asks the system to compute the mesh for it and creates a number of data structures from that mesh;
    1. A vertex buffer to match the format provided by the mesh
    2. An index buffer to match the format provided by the mesh
    3. A constant buffer with details of how to transform the vertices provided by the mesh
  4. Whenever the renderer is asked to render, it loads up the right vertex/index/constant buffers for each of the meshes that it knows about and asks the system to render them passing through a few transformation pieces to the vertex shader.

It’s perhaps worth noting a couple of things around how that code works – the first would be;

  • In order to get hold of the actual vertex data, this code relies on using unsafe C# code and IBufferByteAccess in order to be able to grab the real data buffers rather than copying it.

The second point that might be worth mentioning is that I spent quite a bit of time trying to see if I could get the mesh rendering right.

  • I’m not 100% there at the time of writing but what I have managed to get working has been done by consulting back with the official C++ sample which has a more complex pipeline but I specifically consulted it around how to make use of the SpatialSurfaceMesh.VertexPositionScale property and I tried to make my code line up with the sample code around that in as much as possible.

I must admit that I spent a bit of time staring at my code and trying to compare to the sample code as a way of trying to figure out if I could improve the way mine was seeming to render and I think I can easily spend more time on it to make it work better.

The last point I’d make is that there’s nothing in the code at the time of writing which attempts to align the HoloLens position, orientation and view with what’s being shown inside of the 2D app. What that means is;

  • The 2D app starts at a position (0,0.5,0) so half a metre above where the HoloLens is in the world.
  • The 2D app doesn’t know the orientation of the user so could be pointing in the wrong direction with respect to the mesh.

This can make the app a little “disorientating” unless you are familiar with what it’s doing Smile

Trying it Out

At the time of writing, I’ve mostly been trying this code out on the emulator but I have also experimented with it on HoloLens.

Here’s a screenshot of the official sample 3D app with its fancier shader running on the emulator where I’m using the “living room” room;


and here’s my 2D XAML app running in a window but, hopefully, rendering a similar thing albeit in wireframe;


and, seemingly, there’s something of a mirroring going on in there as well which I still need to dig into!

Wrapping Up & The Source

As I said at the start of the post, this one was very much just “for fun” but I thought I’d write it down so that I can remember it and maybe some pieces of it might be useful to someone else in the future.

If you want the source, it’s all over here on github so feel free to take it, play with it and feel very free to improve it Smile.

Experiments with Shared Holographic Experiences and AllJoyn (Spoiler Alert: this one does not end well!)

NB: The usual blog disclaimer for this site applies to posts around HoloLens. I am not on the HoloLens team. I have no details on HoloLens other than what is on the public web and so what I post here is just from my own experience experimenting with pieces that are publicly available and you should always check out the official developer site for the product documentation.

This post is an interesting one in that it represents two sides of a day or so of technical failure! I tried to get something up and running and it didn’t quite work out but I thought it was worth sharing regardless but apply a large pinch of salt as the result isn’t anything that works too well Smile

Background – Catching up with AllJoyn

It’s been a little while since I looked at AllJoyn and the AllSeen Alliance.

In fact, long enough that the landscape has changed with the merger between the OCF (IoTivity) and the AllSeen Alliance (AllJoyn) with the result that (from the website);

Both projects will collaborate to support future versions of the OCF specification in a single IoTivity implementation that combines the best of both technologies into a unified solution. Current devices running on either AllJoyn or IoTivity solutions will be interoperable and backward-compatible. Companies already developing IoT solutions based on either technology can proceed with the confidence that their products will be compatible with the unified IoT standard that the industry has been asking for.

and so I guess that any use of AllJoyn at this point has to be seen against that backdrop.

Scenario – Using AllJoyn to Share Holograms Across Devices

With that said, I still have AllJoyn APIs in Windows 10 and I wanted to see whether I could use those as a basis for the sharing of Holograms across devices.

The idea would be that a HoloLens app becomes both an AllJoyn consumer and producer and so each device on a network could find all the other devices and then share data such that a common co-ordinate system could be established via world anchors and hologram creation/removal and positioning could also be shared.

If you’re not so familiar with this idea of shared holographic experiences then the official documentation lives here;


and I’ve written a number of posts around this area of which this one would be the most recent;

Hitchhiking the HoloToolkit-Unity, Leg 13–Continuing with Shared Experiences

My idea for AllJoyn was to avoid any central server and let it do the work of having devices discover each other and connect so that they could form a network where they consume each others’ services as below;


Now, I don’t think that I’d tried this previously but there was something nagging at the back of my mind about the AllJoyn APIs not being something that I could use in the way that I wanted to on HoloLens and I should really have taken heed.

Instead, I ploughed ahead…

Making a “Hello World” AllJoyn Interface

I figured that the “Hello World” here might involve a HoloLens app offering an interface whereby a remote caller could create some object (e.g. a cube) at a particular location in world space.

That seemed like a simple enough thing to figure out and so I sketched out a quick interface for AllJoyn to do something like that;

<interface name=”com.taulty.RemoteHolograms”>
   <method name=”CreateCube”>
     <arg name=”x” type=”d” direction=”in” />
     <arg name=”y” type=”d” direction=”in” />
     <arg name=”z” type=”d” direction=”in” />

I then struggled a little with respect to knowing where to go next in that the tool alljoyncodegen.exe which I used to use to generate UWP code from an AllJoyn interface seemed to have disappeared from the SDKs.

I found this doc page which suggested that the tool was deprecated and for a while I landed on this page which sounded similar but turned out have only been tested on Linux and not to generate UWP code so was actually very different Smile

I gave up on the command line tool and went off to try and find AllJoyn Studio which does seem to still exist but only for Visual Studio 2015 which was ‘kind of ok’ because I still have VS2015 on my system alongside VS2017.

Whether all these changes are because of the AllJoyn/IoTivity merging, I’ve no idea but it certainly foxed me for a little while.

Regardless, I fed AllJoyn Studio in Visual Studio 2015 my little XML interface definition;


and it spat out some C++/CX code providing me a bunch of boiler plate AllJoyn implementation code which I retargeted to platform version 14393 as the tool seemed to favour 10586;


Writing Some Code for Unity to Consume

At this point, I was a little over-zealous in that I thought that the next step would be to try and write a library which would make it easy for Unity to make use of the code that I’d just had generated.

So, I went off and made a C# library project that referenced the newly generated code and I wrote this code to sit on top of it although I never really got around to figuring out whether this code worked or not as we’ll see in a moment;

namespace AllJoynHoloServer
  using com.taulty.RemoteHolograms;
  using System;
  using System.Threading.Tasks;
  using Windows.Devices.AllJoyn;
  using Windows.Foundation;

  public class AllJoynCreateCubeEventArgs : EventArgs
    internal AllJoynCreateCubeEventArgs()
    public double X { get; internal set; }
    public double Y { get; internal set; }
    public double Z { get; internal set; }

  public class ServiceDispatcher : IRemoteHologramsService
    public ServiceDispatcher(Action<double, double, double> handler)
      this.handler = handler;
    public IAsyncOperation<RemoteHologramsCreateCubeResult> CreateCubeAsync(
      AllJoynMessageInfo info,
      double x,
      double y,
      double z)
      return (this.CreateCubeAsyncInternal(x, y, z).AsAsyncOperation());
    async Task<RemoteHologramsCreateCubeResult> CreateCubeAsyncInternal(
      double x, double y, double z)
      // Likelihood that the thread we're calling from here is going to
      // break Unity's threading model.
      this.handler?.Invoke(x, y, z);

      return (RemoteHologramsCreateCubeResult.CreateSuccessResult());
    Action<double, double, double> handler;
  public static class AllJoynEventAdvertiser
    public static event EventHandler<AllJoynCreateCubeEventArgs> CubeCreated;

    public static void Start()
      if (busAttachment == null)
        busAttachment = new AllJoynBusAttachment();
        busAttachment.AboutData.DateOfManufacture = DateTime.Now;
        busAttachment.AboutData.DefaultAppName = "Remote Holograms";
        busAttachment.AboutData.DefaultDescription = "Creation and Manipulation of Holograms";
        busAttachment.AboutData.DefaultManufacturer = "Mike Taulty";
        busAttachment.AboutData.ModelNumber = "Number One";
        busAttachment.AboutData.SoftwareVersion = "1.0";
        busAttachment.AboutData.SupportUrl = new Uri("http://www.mtaulty.com");

        producer = new RemoteHologramsProducer(busAttachment);
        producer.Service = new ServiceDispatcher(OnCreateCube);
    public static void Stop()
      producer = null;
      busAttachment = null;
    static void OnCreateCube(double x, double y, double z)
        new AllJoynCreateCubeEventArgs()
          X = x,
          Y = y,
          Z = z
    static AllJoynBusAttachment busAttachment;
    static RemoteHologramsProducer producer;

There’s nothing particularly exciting or new here, it’s just a static class which hides the underlying AllJoyn code from anything above it and it offers the IRemoteHologramsService over the network and fires a static event whenever some caller remotely invokes the one method on that interface.

I thought that this would be pretty easy for Unity to consume and so I dragged the DLLs into Unity (as per this post) and then added the script below to a blank GameObject to run when the app started up;

using AllJoynHoloServer;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Startup : MonoBehaviour
  // Use this for initialization
  void Start()
    AllJoynEventAdvertiser.CubeCreated += this.OnCubeCreated;
  void OnCubeCreated(object sender, AllJoynCreateCubeEventArgs args)



Clearly, this isn’t fully formed or entirely thought through but I wanted to just see if I could get something up and running and so I tried to debug this code having, first, made sure that my Unity app was asking for the AllJoyn security capability.

Debugging the AllJoyn Experience

I used the IoT AllJoyn Explorer to try and see if my Unity app from the HoloLens was advertising itself correctly on the local network.

That app still comes from the Windows Store and I’ve used it before and it’s always been pretty good for me.

It took me a little while to remember that I need to think about loopback exemption when it comes to this app so that’s worth flagging here.

I found that when I ran my Unity code on the HoloLens, I didn’t seem to see the service being advertised on the AllJoyn network as displayed by the IoT Explorer. I only ended up seeing a blank screen;


in order to sanity check this, I ended up lifting the code that I had built into Unity out of that environment and into a 2D XAML experience to run on my local PC where things lit up as I’d expect – i.e. IoT Explorer then shows;


and so the code seemed to be ok and, at this point, I realised that I could have tested out the whole concept in 2D XAML and never dropped into Unity at all – there’s a lesson in there somewhere! Smile

Having proved the point on my PC, I also ran the same code on my phone and saw a similar result – the service showed up on the network.

However, no matter how I went about it I couldn’t get HoloLens to advertise this AllJoyn service and so I have to think that perhaps that part of AllJoyn isn’t present on HoloLens today.

That doesn’t surprise me too much and I’ve tried to confirm it and will update this post if I get a confirmation either way.

If this is the case though, what might be done to achieve my original aim which was to use AllJoyn as the basis of a shared holographic experience across devices.

I decided that there was more than one way to achieve this…

HoloLens as AllJoyn Consumer, not Producer

It wasn’t what I’d originally had in mind but I figured I could change my scenario such that the HoloLens did not offer an AllJoyn service to be consumed but, instead, consumed an AllJoyn service offered by a device (like a PC or Phone) which could offer a service onto the network. The diagram then becomes…


and so there’s a need for an extra player here (the PC) and also a need for using events or signals in AllJoyn to inform devices when something has happened on ‘the server’ that they need to know about such as a world anchor being created and uploaded or a new hologram being created.

A New Interface with Signals

I figured that I was onto a winner and so set about implementing this. Firstly, I conjured up a basic interface to try and model the code scenarios of;

  1. Devices join/leave the network and other devices might want to know how many devices they are in a shared experience with.
  2. World anchors get uploaded to the network and other devices might want to import them in order to add a common co-ordinate system.
  3. Holograms get added by a user (I’m assuming that they would be added as a child of a world anchor and so there would be an association there).
  4. Holograms get removed by a user.

In addition, I’d also want to add the ability for the transforms (scale, rotate, translate) of a hologram to be changed but I left that to one side while trying to see if I could get these bits to work.

With this in mind, I created a new AllJoyn interface as below;

AllJoyn Interface on Github

and once again I should perhaps have realised that things weren’t going too well here.
Everything about that interface is probably self-explanatory except a couple of small things;
  1. I used GUIDs to identify world anchors and holograms.
  2. I’m assuming that types of holograms can be represented by simple strings – e.g. device 1 may create a hologram of an Xmas tree and I’m assuming that device 2 will get a string “Xmas tree” and know what to do with it.
  3. I wanted to have a single method which returns the [Id/Name/Type/Position] of a hologram but I found that this broke the code generation tool hence my methods GetHologramIdsAndNames and GetHologramTransforms – these should really be one method.

and a larger thing;

  • My original method for AddWorldAnchor simply took a byte array but I later discovered that AllJoyn seems to have a maximum message size of 128K whereas world anchors can be megabytes and so I added a capability here to “chunk” the world anchor into pieces and that affected this method and also the GetWorldAnchor method.

I should have stopped at this point as this limitation of 128K was flashing a warning light but I ignored it and pressed ahead.

A ‘Server’ App to Implement the Interface

Having generated the code from that new interface (highlighted blue below) I went ahead and generated a UWP app which could act as the ‘server’ (or producer) on the PC (highlighted orange below);


That involved implementing the generated IAJHoloServerService interface which I did as below;

AJHoloService implementation on Github

and then I can build this up (with the UI XAML which isn’t really worth listing) and have it run on my desktop;


waiting for connections to come in.

A Client Library to make it ‘Easier’ from Unity

I also wanted to have a small client library my life easier in the Unity environment in terms of consuming this service and so I added a 3rd UWP project to my solution;


and added a static class which gathered up the various bits of code needed to get the AllJoyn pieces working;

AJHoloServerConnection Implementation on Github

and that relied on this simple callback interface in order to call back into any user of the class which would be my Unity code;

Callback interface on Github

Consuming from Unity

At this point, I should have really tested what it was like to consume this code from a 2D app as I’d have learned a lot while expending little effort but I didn’t do that. Instead, I went and built a largely empty scene in Unity;


Where the Parent object is an empty GameObject and the UITextPrefab is straight from the HoloToolkit-Unity with a couple of voice keywords attached to it via the toolkit’s Keyword Manager;


I made sure my 2 DLLs (the AllJoyn generated DLL plus my client library) were present in a Plugins folder;


with appropriate settings on them;


and made sure that my project was requesting the AllJoyn capability. At this point, I realised that I needed to have some capability where I could relatively easily import/export world anchors in Unity without getting into a lot of code with Update() loops and state machines.

Towards that end, I wrote a couple of simple classes which I think function ok outside of the Unity editor in the UWP world but which wouldn’t work in the editor. I wrote a class to help with exporting world anchors;

WorldAnchorExporter implementation on Github

and a class to help with importing world anchors;

WorldAnchorImporter implementation on Github

and they rely on this a class which tries to do a simplistic bridge between the Update() oriented loop world of Unity and the async world of UWP as I wanted to be able to write async/await code which ‘waited’ for the isLocated flag on a WorldAnchor to be set true;

GameObjectUpdateWatcher implementation on Github

With that all done, I could attach a script to my empty GameObject to form the basis of my logic stringing together the handling of the voice keywords with the import/export of the world anchors, creation of a single, simple type of hologram (a cube) and calls to the AllJoyn service on the PC;

Startup script on Github

That took quite a bit of effort, but was it worth it? Possibly not…

Testing – AllJoyn and Large Buffers

In testing, things initially looked good. I’d run the consumer app on the PC, the client app on the HoloLens and I’d see it connect;


and disconnect when I shut it down and my voice command of “lock” seemed to go through the motions of creating a world anchor and it was quickly exported from the device and then it started to transfer over the network.

And it transferred…

And it transferred…

And it took a long time…minutes…

I spent quite some time debugging this. My first investigation was to look at the network performance graph from the HoloLens and it looked like this while transferring a 2-3MB world anchor across the network in chunks (64KB) using the AllJoyn interface that I’d written;


It’s the classic sawtooth and I moved my same client code onto both a Phone and a PC to see if it showed the same behaviour there and, to some extent, it did although it wasn’t as pronounced.

I played quite a bit with the size of the chunks that were being sent over the network and I could see that the gaps between the bursts of traffic seemed to be directly related to the size of the buffer and some native debugging combined with a quick experiment with the Visual Studio profiler pointed to this function in the generated code as being the cause of all my troubles;


and in so far as I can tell this runs some relatively expensive conversion function on every element in the array which burns up a bunch of CPU cycles on the HoloLens prior to the transmission of the data over the network. This seemed to slow down the world anchor transfers dramatically – I would find that it might take minutes for a world anchor to transfer which, clearly, isn’t very practical.

Putting the terrible performance that I’ve created to one side, I hit another problem…

Testing – Unexpected Method Signatures

Once I’d managed to be patient enough to upload a world anchor to my server, I found a particular problem testing out the method which downloads it back to another device. It’s AllJoyn signature in the interface looks like this;

<method name=”GetWorldAnchor”>

    <arg name=”anchorId” type=”s” direction=”in”/>

    <arg name=”byteIndex” type=”u” direction=”in”/>

    <arg name=”byteLength” type=”u” directon=”in”/>

    <arg name=”anchorData” type=”ay” direction=”out”/>


and I found that when I called this at runtime from the client then my method’s implementation code on the server side wasn’t getting hit. All I was seeing was a client-side AllJoyn error;


now my method has 3 incoming parameters and a return value but it was curious to me that if I used the IoT Explorer on that interface it was showing up differently;


and so IoT Explorer was showing my method as having 2 inward parameters and 2 outgoing parameters or return values which isn’t what the interface specification actually says Confused smile

I wondered whether this was a bug in IoT Explorer or a bug in the runtime pieces and, through debugging the native code, I could use the debugger to cause the code to send 2 parameters rather than 3 and I could see that if I did this then the method call would cross the network and fail on the server side so it seemed that the IoT Explorer was right and my function expected 2 inward parameters and 2 outward parameters.

What wasn’t clear was…why and how to fix?

I spent about an hour before I realised that this problem came down to a type in the XML where the word “direction” had been turned into “directon” and that proved to be causing my problem – there’s a lesson in there somewhere too as the code generation tool didn’t seem to tell me anything about it and just defaulted the parameter to be outgoing.

With that simple typo fixed, I could get my code up and running properly for the first time.

Wrapping Up

Once I’d got past these stumbling blocks, the code as I have it actually seems to work in that I can run through the steps of;

  1. Run the server.
  2. Run the app on my HoloLens.
  3. See the server display that the app has connected.
  4. Use the voice command “lock” to create a world anchor, export it and upload it to the server taking a very long time.
  5. Use the voice command “cube” in a few places to create cubes.
  6. Shutdown the app and repeat 2, 3 above to see the device connect, download the anchor (taking a very long time), import it and recreate the cubes from step 5 where they were previously.

and I’ve placed the source for what I built up here;


but, because of the bad performance on copying the world anchor buffers around, I don’t think this would be a great starting point for implementing a shared holographic server and I’d go back to using the regular pieces from the HoloToolkit rather than trying to take this forward.

That said, I learned some things in playing with it and there’s probably some code in here that I’ll re-use in the future so it was worth while.