A guide to virtual reality content management systems (VR CMS)

There's little reason to use a CMS for a VR project when you're just starting to create an app. There are many other things to worry about, and the content is not really important at the rough prototype stage. However, when there's more assets to manage, you might want to get them out of the codebase (de-hardcode, so to speak), and use a CMS so that someone else — not you — can take care of this part.

In contrast to apps and sites where (almost) everything is (almost) always flat, VR is three-dimensional — just as R itself. For this reason regular bitmap images won't do anymore. Let's see what these nice realistic objects consist of in technical terms.

Models

First, there's a 3D model, or simply a model, which defines the shape of the horse. There's no colors, no textures, nothing — just lots of points and lines. The models are created in 3D modeling software (like Autodesk 3DS Max) by incredibly skillful people who call themselves 3D artists or 3D modelers; the models are stored in .OBJ (non-binary), .FBX, .DXF (binary), and a variety of other formats produced by different software.

Textures

To make the horse look realistic, you would need to apply some life-looking materials to it: hair here, skin there. The technique used here is called texture mapping; in short, it's a way to put a flat bitmap image, like a close-up photo of horse skin, on a 3D model. These images that capture the photorealistic details are therefore called textures, and they play an important part in forming the overall look and feel.

Let's see the developer's perspective. There's nothing particularly wrong about having all the models and textures hardcoded when you're the only one working on a project. That's often not the case though, and once collaboration begins — problems arise.

Say you're working with a 3D artist, and she wants to put her work directly in the project and test it live. She'd ask you to add new files every time there's some change, and while it's okay to send/receive and copy/paste files once or twice, it can quickly become very irritating to constantly work like that.

The reason to move assets management out of the project is to give both you and the person who's creating the assets more independence and more autonomy, therefore optimizing the workflow.

With "all hardcoded" workflow everything is clear: the files are saved in some folders, and you simply import them in your IDE. Assuming that the files with models and textures are already in some CMS (which hopefully has a decent web interface for file management), how do you get them into the project?

It seems that the most intuitive and abstract way is to fetch them by making an API call. For you, as a developer, the place with assets should be like a black box: you don't know what exactly is there (and you don't really need to), but you can be sure that whatever comes out of it makes sense (someone else will take care of that).

So if your API call that reads "give me all the models" returns all the files with the models, then all is good: the earlier mentioned 3D artist can add and change files as she likes without bugging the developer(s), and the workflow ensures that the VR app would always contain up-to-date file versions.

The best thing about this story is that such a CMS already exists. It's called Contentful; it's an API-first content management platform which is all about helping both editors and developers find their ideal workflows.

This is how managing models would look like, for example:

All in all, VR content management is not that different

That's an important — and maybe even surprising — observation: although the VR apps are very different in their nature from website and apps, the content management workflows effectively remain the same.