So, we began working our way through the Unity training material to quickly absorb terminology, processes, and requirements for developing different kinds of Unity applications. They focused on areas that relate to the application we need to develop. This opened a can of worms.
We launched a conversation about how to provide a service to synchronize the HoloLens virtual space of multiple users who share the same physical space. This is interesting because we have no idea what HoloLens will do, what hardware it will contain, or how it will communicate with Unity. So, a refresher of the basics was in order:
- HoloLens can map the surrounding environment and create a tessellated mesh of it.
- HoloLens can apply movement and physics to objects without a user specifically coding for these things.
How HoloLens achieves the interaction between virtual objects and the physical environment matters. The approach used by HoloLens may help or hinder the development of a solution that provides persistence and sharing capability. If an application can access a map of the surrounding environment and the placement of objects then that information can be saved. If a map cannot be accessed, then the function of persistence may be impossible to deliver.
This lead us to the next topic of discussion: Creating a universal script for positioning objects. When an object is in a Unity Scene running on HoloLens, can the user automatically move, rotate and scale the object using functions provided by the HoloLens SKD, or is a developer supplied script still required? At this point we just don’t know. In this case, we made the decision that a “universal” script should be developed that will be assigned to every object in Unity. This way we can guarantee that users will have these abilities.
So grows the list of functions the application must provide.