Evolution of a VR Development Framework with Unity + Lessons Learned
tl;dr — skip to ‘Lessons Learned’ at the end of this story.
It all started in 2010 with Unity 3.x.
I had just figured out how to import my first Revit model into Unity, and I couldn’t have known at the time what a decisive moment that was in my career. This amazing application would serve as an integral underpinning to my professional work for a decade or more.
I needed tools, but the Unity Asset Store wasn’t a thing (yet)
Once I had the import process worked out, I wanted interactivity . I wanted to turn lights on and off, to teleport to various waypoints in the scene, to change materials, etc.
I wasn’t a programmer, and in the days before the Unity Asset Store you either had to learn to write C# or Javascript, or you had to hire a programmer to write it for you.
I taught myself the basics of C#, and even managed to write all of the code and publish an Android tablet game in collaboration with my daughter (4 years old then).
The code I wrote was a horrible mess, but I had a blast and in the process I gained an enormous respect for the craft and fine art of programming. I hadn’t previously realized what an enormously creative process it is, and how vitally integral it is to transforming the visual elements of Unity builds into richly interactive experiences.
The Architectural Beginner’s Kit
I put out a call some time in 2010 on the Unity forum (anyone remember the ‘old’ Unity forum?) for developers interested in helping me build a ‘kit of parts’ to aid in development of architectural projects in Unity.
I called it the “Architectural Beginner’s Kit,” and I heard back almost immediately from Tyler Cook. Here’s a snippet from one of my first communications with him in October 2010:
My interest is in making Unity easier for architects and AEC professionals to use. I’ve kept track of my own pain points as an architect trying to use Unity — and created a list of ‘nice to have’ elements that I wish I could have just purchased early on — rather than having to learn a programming language, etc. I’m just an architect! ;-) I can’t script my way out of a wet paper bag, lol. So, what I would like to explore is the possibility of developing a simple prefab toolkit that architects can use to help expedite the process of using Unity for architectural visualization.
It was on. Within a few months, we had 2 different Architectural Beginner’s Kits available for Unity sold through our website. They sold nicely, and we heard a lot of positive feedback.
What was nice about the ARK was that it not only helped architects and designers make better use of Unity, but I was able to recover the cost of developing a code base of prefab functionality I then used to build custom apps for clients. It did require the up-front investment, but it paid off over time. This was a valuable lesson that would guide my thinking on Unity development strategy into the foreseeable future.
Tyler and I worked together on quite a few projects back in the day. He eventually landed a full time gig, and I went on contracting on Unity projects.
Building the ARK
Sometime in December, 2013, a programmer I was collaborating with on a project for Gronstedt Group, Julien Lynge, pinged me to see if I had any freelance contract work he could help with. I shared with him my vision for a new and improved kit that I was now calling the “Architectural Resource Kit.”
Here’s a snippet from an original email to Julien:
“Architectural Resource Kit — it’s a set of tools designed to help create real-time applications specific to architecture, construction and real estate development
As an architect using Unity3D for real world practice, these are tools I found useful and had developed specifically for architectural uses over the past few years. In order to make that process easier for others attempting to do the same, I’ve bundled those resources into a single asset kit that will make it much easier for new users to enjoy using Unity3D to create AEC related applications.”
As you can see, my vision for the ARK hadn’t really changed much in 3 years. Julien built the ARK, and that core framework continues to serve as the basis of what we’re working with today.
Along Came Oculus Rift
Upon receipt of our DK1, the ARK immediately became exclusively about VR, followed by several years of “you know what would be cool..” features being stuffed into it over time. It became a very powerful toolset, but we never manged to bring it to market in its genesis form. We ended up expanding the scope considerably, while simultaneously chasing down one OVR SDK update and Unity release after another- each of which would break everything and keep us scrambling. All the while, we needed to continue developing our applications and shipping deliverables to clients. This is a cycle early VR developers know all too well.
At the same time, we started getting busy with bigger enterprise VR projects. Toward this end, we founded Arch Virtual as a company dedicated to using VR to solve real world problems. Previously, it was mostly just me doing independent consulting work, but our team and capability had grown enough to become a real company.
The ARK was our internal toolset, and every project introduced a variety of new features and functionality to the platform.
RIF
It was bigger than architecture now, as we delved into a wider variety of industries. We needed a new name and eventually came up with the “Realtime Interactivity Framework,” or RIF.
We used RIF to build all kinds of VR projects — an NBA arena, a driving simulation for Suzuki, we even did the Oculus HQ (pre-acquisition) and another HQ for a confidential tech company.
Immerse
My friend Conrad Karliss and I were chatting about the future of VR one day in early 2014. The conversation was centered around the issue that VR services are great, but they’re difficult to scale. We needed a product. Maybe we should package up our RIF platform and start selling it to other developers? We’d sell pickaxes to the miners, but we need a better name for it. I honestly can’t remember who specifically said the word first — I think we tossed around a few variations before coming to the name Immerse Framework ®.
We started quietly distributing our platform as Immerse Framework later in 2014 and more aggressively in 2015, selling directly through our new Immerse Interactive website. We launched our multi-player enterprise platform dubbed Immerse Collaborative — an add-on for the Immerse Framework. We also sold Immerse Assets through the Unity Asset Store.
Pivot
It sold, but I think we were misaligned with our target market, and the market was way too small. We had intended for Immerse Framework to be a tool to help new developers get up to speed quickly, but we underestimated the Unity learning curve they had to pass before they could make use of Immerse. It’s gotten much easier to learn Unity over the years, but most of our target customers had zero experience with Unity, so even if they wanted to take advantage of the tools we were offering, they first had to learn Unity. Plus, there just weren’t as many newbie VR developers as I believed there would be. The market was too small, and we were way too early.
This became major bottleneck, so we made the very difficult decision to pull Immerse off the market. We continued to aggressively support our customer base with free updates for over a year, and they could continue using it in their own projects indefinitely, but we stopped actively marketing and distributing it.
I still think Immerse Framework could have found a larger market over time, and maybe someday we’ll bring something like it to market, but things were moving fast with VR and I didn’t want to wait for the market to arrive. I also didn’t want to compete with Unity. They’d almost certainly be working to build similar tools, as would Oculus, maybe Valve and others too.
Open source plug-ins like VRTK also arrived, which solve some of the same problems we were tackling with Immerse. I think an open source framework is probably healthier for the industry in the long run, but that project is facing a similar lack of support that I believe is exclusively due to the relatively small market size. Over time, I think an open source toolset like VRTK will be vital to the democratization of VR development, and I hope to support it in any way I can.
Bringing it Home
It was an exhilarating breath of fresh air to return to development of Immerse to solve our own problems, and increase the efficiency of our own development pipeline.
As it stands today, Immerse Framework remains our own in-house toolset we use as the basis of every enterprise project we build. It’s a set of functional modules that makes us fast and efficient, serving as a menu of features for the custom project we build for clients.
Immerse Creator
We’ve bundled several of those modules into an app we’re distributing in Early Access on Steam that we call Immerse Creator. It’s multi-user, voice communications, in-world 3D modeling, sketching with lines, importing your own FBX, and utilizing any of the thousands of assets we have in our library. It’s some seriously powerful stuff — we just need to start telling the world about it.
Immerse Creator actually started out as an internal skunkworks r&d project I called ‘Basswood.’ Here we go again — a product originally intended as an architectural tool, where I wanted very basic modeling tools in a multi-player environment to achieve the ultimate in collaboration.
Immerse Framework and Immerse Creator were orders of magnitude more expensive to develop than the ARK, but we’ve managed to build most of the features we now have in Immerse Creator by doing enterprise VR contracts.
Immerse Creator is the most recent incarnation of a vision quest I’ve been on for almost 20 years to instigate multi-user collaborative creativity in any form. Given creativity tools, and the ability to share what they create, and people will build amazing things. We’ve got the pieces and place, and we’re just getting started.
What’s in a Name?
Nowadays, it seems like the name Immerse is everywhere you look. We were never terribly committed to guarding the Immerse Framework name, but I did secure a U.S. trademark. Technically, ‘Immerse’ in our case is just the short-form of the full product name — Immerse Framework, Immerse Collaborative, Immerse Creative, etc.
There’s the awesome ‘Immersed’ conference, which I plan to attend this year, along with another Immerse in the UK, as well as the Immerse headset. FEMA also did a VR experience about flood and resilience they called “Immersed.” Another company called “Immersion” builds augmented and virtual reality for business and entertainment. I’m sure there are many more I’m missing.
Wouldn’t it be fun if we all showed up with booths at the Immersed conference? Immerse, Immerse Creator, Immerse headset and Immersion all at Immersed. Maybe I’m the only one who thinks that’s funny.
I’m sure this is just the beginning.. It’s a vast virtual frontier — plenty of room for lots of Immerses. I wish them all the best of luck.
Lessons Learned
Framework worked
I’m sure it stems from my architectural background and lack of programming experience, but starting with a foundation or framework to build on makes logical sense to me and it has worked well for us. I’m not sure if this is how it’s supposed to be done, but if I had to do it all over again, I’d invest in the framework early to start with.
Everyone on the same page
One of the biggest benefits of Immerse — particularly on a team like ours that integrates independent contractors on a regular basis is that the modular / visual structure of Immerse made it easier for new developers to jump in and efficiently hand off tasks. It helps ensure everyone is speaking the same language.
Artists and Jr. Developers can build interactivity
Since Immerse Framework was originally designed to be easily used by non-programmers, it was possible to have artists complete some of the interactive elements of the project as well. This helps assure the most efficient use of time and gives us a lot more flexibility overall. It’s also possible for junior developers to very quickly get up to speed and start developing interactivity.
Expect an ongoing investment
Something to think about if you do decide to develop a platform or common code base to support your work is that it’s not a one-time expense. It’s a commitment to ongoing investment and maintenance you’ll be making for the duration of the platform’s life cycle. In our case, Unity is constantly changing, as are the Steam and Oculus SDK’s we work with most closely. You have to keep your code base current with these moving targets, which means a perpetual development cycle to maintain it.
Build it, throw it away. Rinse, repeat.
The other interesting thing about developing a code framework is that you’ll almost certainly end up building it then throwing it away and building it all over again. You might even repeat this cycle 2 or 3 times. It’s less of a static artifact, and more like a dynamic, ever-changing thing. If we had latched onto the very first iteration of our framework and resisted the inevitable ebb and flow of shifting priorities, lessons learned and strategic objectives, we would never have gotten off the ground. What doesn’t bend breaks.
Respect the craft
I want to underscore a point I brought up earlier about gaining an understanding of the craft of programming. You don’t necessarily need to be a programmer yourself, but you do need to understand the essential building blocks of it, and the rhythm of development. I’m still on a learning curve, but I’ve come to understand the vital importance of being clear about your expectations up-front — dialing in on as much detail as possible on what you want to achieve, then getting out of the way and letting your team work their magic.
I’ll update this article in the future if/when we come up for air and will let you know how things have progressed.
Thanks for reading, and we’ll see you on the virtual frontier!
