Hololens will use the Unity Game Engine. Unity allows persistence by saving to disk. This works okay if you’re alone, but doesn’t work if you’re playing a multiplayer game. You can’t simply save to disk and come back the next day as other people sharing the virtual space may have changed it.
The current implementation of persistence and sharing in the Unity Game engine is predicated on a set of “knowns”: The server holds all the maps of virtual space, and these maps only change within predefined limits. There is a predetermined collection of objects in each of these maps that the Unity server must already know about. The server must be running 24/7 to let people connect, engage and disconnect while maintaining the virtual space.
Some questions arise from this:
- How do you map the entire world?
- How do maps get updated?
- How will people add new objects to this world that do not already exist on the server?
- How will a server know what map they are in?
The questions above may not have answers. Asking them helps to illustrate the challenges facing HoloLens, Unity, Microsoft, and Flatventure. For example, when a user enters a room for the first time, the virtual objects that have been placed in that room by other users need to be displayed in the correct location. This is the essence of persistence and sharing.
With the above details in mind, we started investigating the idea of peer-to-peer data sharing and decided it wasn’t a viable way of sharing data. There was a whole raft of considerations that invalidated this approach. For instance, two people see the same object in a room, both users then leave the room. One user returns, deletes the object and leaves. The other user now returns to the room. How will they know the virtual object has been deleted? What if they move the object to a different location? When the first user returns to the room and the two HoloLens synchronize their data what will happen to the object? Will it be deleted? Will it have moved?
We also investigated WIFI triangulation. It is possible to work out where a user is in the world by looking at WIFI access points and comparing it to a known map. The most common approach taken is to record both WIFI access points and GPS coordinates to a lookup database. By looking up WIFI access points you can get GPS coordinates. It sounds great on paper. The reality is that the margin of error can be from 20 meters to 20 kilometers. If the best granularity is 20 meters it makes it pretty hard to place a virtual picture on your wall when the next day it may appear in the middle of your next doors neighbor’s front yard.
We also started creating a database of 3D objects. The internet is full of amazing royalty free objects which would look great in any living room. Unfortunately these objects are not in a form that can readily be used by the Unity game engine. Specifically, they need to be found, downloaded, checked for errors, simplified if they hurt performance, and then be saved in a format that can be read by the Unity game engine. If Flatventure wanted to offer users a database of 5000 3D objects then this would involve a lot of labor. After a few false starts, the entire process was automated. We now have a workflow “pipeline” to look for free 3D models on the internet and produce an object that is verified, validated and ready for the Unity game engine.