How I Learned that I Need to Code My VR Experiences


Last week was a pivotal moment in the evolution of Circuit Rider. I submitted the experience to the Oculus store, however, it came back to me changes that needed to be made before they continued its evaluation. The problem was that the project wasn’t able to maintain 90fps, which is pretty much a deal breaker for them and depending on the graphic fidelity it can be difficult achieve that benchmark.

When I saw the feedback I felt gutted and I instantly panicked because the team that built the experienced had already disbanded.

Rather than stay with those depressed and defeated feels, I became hyper focused on how I could solve these issues quickly as I already started a Patreon campaign in work a new VR experience that I am passionate to make.

I ended up finding a couple freelance developers to work on optimizing the project, but it wasn’t easy to find them and despite paying them a little bit of money I’m not sure how everything will turn out. They tell me it’s a graphics and lighting issue, so I’m going to be taking a risk to trust them and will see where this turns out. It’s hard position to be in a and I absolutely hate that this isn’t in my control. This is the reason that I’m learning to code.

You are probably asking yourself, didn’t you develop the game? No, unfortunately not. I spent a lot of time working on assets but I didn’t touch the engine or the code. As a result, I don’t know what needs to be fixed or how to do it.

The lesson here is that learning to code and how to work in the game engine is absolutely critical to making VR experiences, even if you work with or hire a team. I have mentioned this before and have been criticized by some who believe that not everyone on your teams needs to have coding skills to make a project. I don’t feel like that is true and even further I feel it was sheer luck that I was able to get this far without knowing how to code. However, after this experience of working on Circuit Rider I can’t take anymore chances, and need to roll up my sleeves and touch every part of the creation process. That’s the only way I feel that I can become a better content creator in this medium.

For more updates on our VR projects, sign up for our newsletter here

To back our Patreon campaign to help us make more great VR content click here



The Mistakes We Made While Making Our VR Experience

This is not an easy article to write because as a content creator I constantly try to focus on the positive. However, at a business skills boot camp organized by the TMZ at Ryerson University I was encouraged to write down the top 5 mistakes we made while making Circuit Rider. This was just an exercise, but I turned into an article.

After jotting these down in a rapid brainstorming session, my initial hesitation dissipated as I realized all the things that I would do differently the next time around.

It is important to note that the following mistakes are by no means a reflection of the quality of the team that worked on the project, but rather an opinion of what I feel we could have been done differently to yield a better final result.
  1. Too much time spent on writing the script and not enough time building and testing what works and what doesn’t.

As we had a solid idea for the project, but we spent a lot of time refining the script where we could have used that time building the mechanics and design of the world. Don’t get me wrong, I feel like have the script was incredibly important but we should have spent way less time writing it and more time working out ideas as we built.

2. Working with team members weren’t engaged in the project and rather than letting them go when this went noticed, they ultimately left the project at a crucial time and which compounded the work for the rest of the team.

This is a tough one and firing people is never easy, but my advice here is that if you notice this type of behavior then you need to get rid of those individuals as soon as possible. When people behave like this, it’s because they are not interested in the work enough to give you the dedication that is needed to finish it. It’s therefore better for both parties to separate as soon as you notice this, so you don’t get saddled with a ton more work that you already have on your plate.

3. Everyone on the team didn’t have the necessary skills to build the project.

What happens when 20% of the team have the skills to put together the project, it puts a lot of pressure on those individual to complete it. If something happens and they don’t have time for the project, it can throw the whole thing in disarray. I would argue that everyone should be building assets and everyone should be involved in the programming. If you don’t have this scenario on your team, then the team lead should be responsible for the coding because it will fall on them to finish it if something happens. I say this because I was the team lead on Circuit Rider.

4.Not having everyone on the same page about what the final product would be.

This is a big one as some people wanted it just to be a demo and some wanted it to be a polished experience. It caused a bit of tension between the who quality vs deadline debate when the issue of the deadline came up. On this everyone needs to be on the same page or it simply doesn’t work.

5.Having a bigger team doesn’t necessarily mean more productivity.

On Circuit Rider we had six people, but the bulk of the work was done by a little more than half. I think we could have either done with less people or had people take on more work. If they couldn’t take on more work than get rid of them. It may sound harsh but if you want to produce something amazing, you need to work with only the most dedicated people you can.

In closing, I think whole team of Circuit Rider did an amazing job and I am very proud of the final product. That said, sometimes it is good to reflect on the things you felt went wrong so you can look back and be reminded of all the things that went right.

Circuit Rider will be showcased in Los Angeles at VRLA from April 14th-15th, 2017. It has also been submitted to Kaleidoscope VR Showcase Vol. 3 as well as the Oculus Rift store.



How I Fell In Love With Depthkit

In 2014 I got my first dose of virtual reality courtesy of William McMaster, a local documentary filmmaker based in Toronto. The footage he showed me were just a random array of clips that he had captured while living in Tokyo but the experience of watching it in the Oculus Rift DK1 was utterly exhilarating. After I took off the headset I couldn’t stop the wheels in my head thinking about what I wanted to do in the medium. My only issue was that I wasn’t sure how I would be able to tell a narrative story in 360 video. In the end, I decided to take my own approach and executed this with my film, I Am You. With that film I was able to come to grips with a lot of these feelings I was having about the limitations of storytelling in the medium.

After I completed and released I Am You, I started thinking about my next project. One day I came across the Kickstarter for “Blackout”, a film that was using a technology called Depthkit to capture the actors and place them in a 3D environment. I became really intrigued by this technique by using this seemingly easy and relatively affordable software combined with off the shelf hardware.

Serendipitously, I came across Ben Unsworth of Globacore who had backed the Kickstarter campaign and therefore had access to both the Depthkit software and the custom hardware mount for the Microsoft Kinect sensor. He agreed to lend it to me in exchange for knowledge on how to use it. Happily, I jumped right in the deep end. Despite reading a lot of the documentation and step by step instruction on their site, I had a lot of trouble going through the calibration process of the Kinect, my camera, and the software. Luckily, Depthkit had a Slack channel and were available to help. This was a god send as I wouldn’t have been able to get through the process without them as the learning curve was quite steep. That said, it still took quite a few tries before I was able to get it right and I can only attribute my eventual success to a tedious trial and error process that I just didn’t give up on.

Fast forward a couple weeks and I met filmmaker Pierre Friquet who was about to shoot his latest VR film, Patterns, and was interested in using Depthkit to capture the actors. I immediately put myself forward to help as it was an opportunity to experience the entire workflow from start to finish, and I believe that there is no better a way to learn things when you are on a project with a deadline. Luckily, the shooting portion went off without a hitch but the post of the footage became an issue because we had shot everything on a green screen and I had to figure out the workflow of processing it through the Depthkit software. Again, after lots of trial and with the help of their slack channel we found the answers we were looking for.

Unfortunately, I never saw the final version of Patterns but I did see the takes I worked on in the HTC Vive headset. What I can tell you is that it left me with this confidence that I could see how I could tell stories in Virtual Reality and since August 2016 I have made two more VR projects that have involved Depthkit and I have no plans on slowing down any time soon. I have fallen in love with this idea that I can get the exact performances of my actors into a virtual space, so quickly and easily. I also see endless possibilities of how I can make things and not feel handcuffed by the technology, which is incredibly important to the productivity of an artist.

Based on the conversations I’ve had with Depthkit, it feels like they are very committed to improving the product and sorting out some of the more technically challenging aspects to using it. I’ve also heard rumors that they are going to start supporting different sensors as the Kinect will eventually disappear based on Microsoft’s lackluster support of the product. That said, the future is very bright and I’m more than happy to go along for the ride even if it stays bumpy for a little while longer.