Shared Holograms Catalogue
I’ve decided to break this post up into separate topics as when I got into this I realised there are a number of natural sections with their own merit. So think of this as a trip through my thought process as I put together a sample app.
The aim of the project is to create an app which allows the user to consume a catalogue of 3D models, view them with a HoloLens and also have other participants view the same hologram. The project will be hosted here https://github.com/peted70/gltf-loading
Dependency Injection
This may not seem absolutely necessary for a sample app but early in my career I learnt the hard way that anticipating change and coding against abstractions was almost always the best way to begin writing *any* software. I would argue that samples benefit the most from this since dependencies can be more easily understood and reconfigured and also the easier a sample is to keep up to date the less likely it is that the sample will become obsolete and potentially counter-productive to the reader. Of course there is a trade-off here between obscuring the main point of the sample with extraneous code and reaping the benefits of DI.
I had previously been in the practice using some kind of dependency injection in my apps but since working with Unity I had fallen out of that practice. This post gives me a chance to revisit and after some short research I found Zenject and decided to give it a try.
For this sample I wanted to have an online model catalogue so the first job for DI was to hide the apps data retrieval behind an interface and have that configured by Zenject. I started with a dummy implementation of the interface:
Note that I’m using a Task-based async interface; enabled by using the experimental .net 4.6 support in Unity.
Then, adding Zenject to the project using the Asset store.
Next a Zenject SceneContext needs to be added to the scene which is facilitated with a menu editor option:
And finally, a Zenject Installer script is needed, again this can be added using an editor extension:
The installer is the script where you can configure the dependencies for the app. I added code to supply an IHologramCollection implemented by the concrete class HologramCatalog with a view to replacing this later on with a real cloud catalogue.
Now I can create a Monobehaviour-derived class to handle data retrieval. It’s necessary to declare a function to inject the interfaces here, amd decorate with the Inject attribute. (Note, I’m also injecting an ILogger interface here).
Now, with the help of async/await we can call the interface and action the data items returned:
I’m very intrigued by the premise of a novice-friendly catalog of Unity assets, because I’m designing one myself. But I can’t tell what the novice user’s experience would be from the description here. I’m not sure how similar our goals are, so I’m not sure whether to try your technique.
For my purpose the assets are not really general-purpose but 3D models that I know how to parse. I guess you could use asset bundles but that doesn’t really fit with what I wanted to do.
Thanks for replying. However, I still don’t know what your intended user experience would be — Would it be a customer editor inside Unity for importing packages? Or would it be a GUI outside of Unity that allows users to select hologram assets, and it scripts a headless Unity to add those assets to an existing or new project?
It is a HoloLens app which imports 3D models from a web server. Intention is to build that over the next few posts.