Building an API for VR and 360

In the last article, we looked into what you need to build a 360 player. and what is required for the same. This week, let’s look at what we need to build an API for VR and 360 content.

API for VR and 360 content

360 images and 360 videos are currently being used to tell a story, showcase a property, share the surrounding and so on. In these scenarios, there is often more than one 360 image or 360 videos being used. In these cases, managing 360 content becomes a concern.

When dealing with a lot of images, you’re not sure how to store them, how to retrieve them and how to serve them. This one of the reasons for building this as an API. And think of the possibilities with 360 content. You can make virtual tours of all shapes and sizes, galleries, 360 guides and so on.

Current solutions

Let’s look at the current solutions that are tried out by people without the API to solve the problems with 360 content.

Viewer only solutions

Krpano and pano2VR provides tools to display and create 360 virtual tours and galleries. The workflow with them usually looks something likes this:

1. Run the script to generate the required code. For example, in KRpano, you can drag and drop the pano to the script make pano and you would get the html code for the item.
2. Upload the code to your server, along with the generated images and tiles.
3. Embed the page to the actual page you’re using

The advantage of something like Krpano is that you don’t have to worry about the frontend code to display 360 content. You don’t need to learn WebGL or its complexities.

But it also has its problems. You need to handle rest of the workflow manually. You need to upload the code and images after generation manually. This is fine for couple of images, but when the amount of content increases, this quickly becomes a pain.

Another problem with this solution is that it only provides solution for using on the web. If you need to use it on other platforms, you need to find a way to build them on your own.

Unity solution

Another method is to use Unity. Unity is a popular option for building VR applications on platforms such as Gear VR, Vive and Rift. Unity provides some solutions for displaying 360 content.

But it doesn’t do anything regarding optimizing the content or managing the content since the backend needs to be built by the user. And even though Unity claims WebVR compatibility, it is not solid on that front.

Youtube and Facebook for 360 videos

Another option with hosting is to use Youtube or Facebook. With this option, you can upload 360 videos (360 photos also in Facebook). With this solution, the media is hosted by the platform and optimized for viewing.

But it doesn’t give you any customization options on how the content is displayed. It also doesn’t give much options in cross platform viewing of the 360 content. The content you upload to those platforms are locked to those platforms and vendors.

Custom setup

With this solution, you can build a custom solution from ground up. You can build backend with image optimizations, custom workflows, servers that processes and stores the images. You also have to build frontend applications that can display them on the different VR platforms.

Apart from all the development costs that this method will give you, you also need to be on top of latest development in VR tech, so that you can update your platform SDKs based on the changes. Anyone can see why this is not an ideal solution for any business to build a custom solution.

1. It takes a lot resources and time
2. It is expensive
3. Have to invest in multiple technologies
4. Keep up with latest changes in VR

With this in mind, let’s see what we can do better.

API for VR

Making the API available allows anyone to create applications on any platform that manages the 360 content. SDKs available in the platforms can be used to create the application on the client side. If some custom functionality is needed, that can also be created by the user. This flexibility removes the boundaries set by a fixed platform.

I was initially hesitant to make this an open API. But the benefits of API became apparent when I was working with a real estate company.

For their use case, multiple 360 photos needed to be stored for each property they had. Photographers who created the 360 content also needed a way to upload the photos to the right property.

Since the content management was available via API, it was easy for the real estate company to integrate 360 photos to their listings. It also worked well when I created a frontend application for the photographers to upload the photos. Managing all the content without an API would have been a nightmare.

Making an open API for 360 and VR content will enable all the developers to create applications that utilize such content quickly.

Hosted 360 content

360 images and 360 videos are usually of much higher size. Uploading them to your own individual services can cost a lot more. This is why we decided to host the 360 content for you. When you build your applications, you only need to store the ids of the content. This is a huge money saver.

We need more VR applications

One of the pressing problems in VR today is the lack of quality content and applications. Apart from gaming, there is only so much a user can do with their VR headset today. This situation needs to change.

This can be changed when VR content producers and VR developers work together. One of the major motivations to making this API public is to encourage more developers to get into VR and 360. The SDKs along with the API makes it much easier to get started in VR.

As VR becomes more popular and the API can grow along with it providing more functionality. Currently, I’m planning to mainly support 360 content. This focus is required since VR is a huge industry and one can be quickly overwhelmed with what is possible with VR.

Focus on developers and scalability

With the focus on API and SDKs, it is also apparent that the focus is more towards the developers. This enables the developer to create experiences and interfaces for creating 360 experiences as they want.

The API will be build over cloud services to offer nearly unlimited capabilities in storage. Currently, I’m using AWS to store the content. This also gives the room to scale the capacity when needed.

Scalability is one of the issues that we have talked in the past. But now let’s get into detail.

CDN

A worldwide CDN will be made available to all the content used with the API. This ensures fast delivery of the content.

What info will API provide

The API will be designed in such a way that it doesn’t make any assumptions about the rest of your stack. The sole job of the API is to serve VR content. Each of the content uploaded to the service will be given a unique ID. This ID can be used to retrieve and display the VR content.

For example, if its a single 360 image, the image can be uploaded via API. The contentId can be used along with the SDK on the platform you want to display the content. Another example would be, image gallery where the galleryId would provide contentIds of the items in it. The possibilities of such an approach is endless.

In the upcoming weeks, we’ll see what kind of content and experiences will be supported initially by the API and SDKs. We’ll also look more into what powers the SDKs.