Real Time in Real Time - Ready, Set, Data

Now that the AR/VR industries are in full swing with second and third generation HMD development in as many flavors as they can muster, and content developers around the globe are working to come up with the latest and great game, or tool, or 3d sculptural drawing app, it’s time to understand where the weak links exist.

Many people would say that there are no weak links at this early stage, however, one stands out to me that is somewhat significant to the average developer, and without proper handling, could delay, and in many cases derail efforts of some otherwise amazing content developers. 

Data and it’s management is the weakest link in the chain between content developers and the delivery systems that would be content rides upon. That is to say that, there are no easy or standardized methods to getting dynamic data into and out of applications at runtime. While there are many ways to stream data from the web, take movies or html for example, as well as customized solutions to view specific 3D content at runtime, such as SketchFab, which allows users to view Sketchfab 3D objects at runtime via their proprietary api. From data management to file formats, this is emerging as a hairball for content developers, and everyone is forced to “roll their own” solution. This will lead to a literal ton of pitfalls, and non-standard solutions that will inevitably be forced out of existence as standards do emerge. VHS vs Betamax, Blu-ray vs DVD, while these are simple in terms of just 2 to choose from, with only one emerging victorious, the idea is that with software development, there will be so many custom solutions for data IO, that none of them will be compatible except in their own implementation. And heaven forbid any of the underlying technology changes beneath these solutions.

Dynamic data, in whatever form it takes, is not a small problem for developers, especially on a platform that requires dynamic content to remain viable. All of the concept art and demos in the world will never be as good as having the “rubber meet the road”. That is to say, a methodology that is secure, and as ubiquitous as HMDs and smart devices. Getting dynamic data out of and into AR is at best, and cobbled together custom solution no matter who is developing it, which means it is significant point of inefficiency and redundancy in the AR/VR development cycle. As a ridiculous example, it would be like every automaker figuring out what it takes to make a rubber tire from scratch to put on their model of auto. HTML was revolutionary, and it’s implementation at first was all over the place. The World Wide Web Consortium, while not perfect, is based in the idea of standardization. The concepts, and processes they set forth guide the development of the Web in an organized and consistent manner that ultimately benefits everyone from developers to end users. It would be a good time to begin standardizing methodologies and API processes to facilitate all content developers in the AR/VR space as well, and to make it an easier task for developers to create, instead of re-inventing the wheel at every studio.

There are many smart minds in these industries solving this same problem internally, when actually, this is a much larger issue for the moment, that the entire ecosystem of AR and ultimately VR will depend upon as the markets emerge and wide spread adoption becomes a reality. I am sure that Apple, Google, Epic, and Unity can all see the benefit of working together to help developers create what they envision running on all of their delivery and development systems.