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.

In experimenting with Unity for building out holographic apps for HoloLens I’ve got quite used to going into Unity and making a ‘blank’ project as per this recipe;

Configuring a Unity project for HoloLens

in that what I generally do is to make a new, blank 3D project;

and then I either make use of the HoloToolkit for Unity or if I’m just doing a quick experiment I’ll change some camera settings;

and then I’ll save the scene and change the build settings;

and then quite a few times I’ve forgotten to specify that I’m doing holographic development over here;

and what I find interesting is that if I make this mistake then the app fails to show up as a ‘holographic’ app on the emulator or on the device.

That is, it turns up in a window;

and so my own assumption would be that missing out the important step of selecting the SDK as I should have done (shown below);

causes some code path to be taken through the Unity pieces here that does not involve setting up a HolographicSpace and so my app runs as a flat app. That’s my assumption – I did try and test that out in the debugger but couldn’t quite get the right mix of symbols and breakpoints to 100% prove it to me so apply a pinch of salt.

If I switch on the SDK as I was meant to in the first place then I get the view that I would expect for a holographic app.

The first lesson there is then not to forget to reference the right SDK

The other lesson is the difference between choosing a build a D3D project versus building a XAML project from this dialog;

If I choose D3D here as above then I get a UWP project which feels pretty streamlined – I end up with a custom class (named App) which implements both IFrameworkView and IFrameworkViewSource and which runs to around 100 lines of code which takes whatever steps Unity needs to get itself bootstrapped into the process.

I don’t find it easy to switch the build type between D3D and XAML once I’ve done the first build of a project so there’s something I need to figure out there but if I set up another project the same way and then do a XAML build then I see a bit more code generated than for the D3D build.

However, I don’t know that most of that generated code actually applies when running on the HoloLens emulator/device.

The code is the usual class App derived from the Windows.UI.Xaml.Application class and it seems to split its Unity initialisation across both OnLaunched and the Activated handler and ultimately creates a Frame and navigates it to a MainPage as the Visual Studio blank UWP app template would do.

That MainPage.xaml then includes some more UI hosting a SwapChainPanel and a splash screen and about 250 lines of code-behind but a lot of that code does not seem to apply to a UWP app running on a holographic device. Most of the code would appear to either be compiled out by conditional compilation or taken out by the logic and the main work appears to be done here;

which comes from the MainPage constructor and then seems to bootstrap the same view that I’d see in the D3D exported project.

So…I can use the D3D export if I want to end up with something where there’s no XAML bootstrapped into the process and the XAML export if I want to have ‘XAML’ bootstrapped into the process and it doesn’t feel like there’s a huge amount of difference between the two otherwise which is what I’d hope for.

From a user’s perspective – running the XAML exported project means that you seen a Window for a second or so before the holographic view comes into play and takes over the whole frame so, again, it doesn’t feel dramatically different from running the D3D exported project.