Sean McBeth on Primrose and WebVR development

WebVR continues to grow and impress me with every week that goes by! One WebVR framework which looks incredibly impressive is Primrose — a WebVR framework which aims to “simplify the process of building VR applications that emphasize interactive, productive work”. Primrose has the most solid live coding capabilities in WebVR I’ve ever seen! Its creator, Sean McBeth, was kind enough to give some incredibly useful tips and insight into getting into VR development.

Sean McBeth and Primrose

What inspired you to put together Primrose?

One of the early WebVR demos was the RiftSketch project by Brian Peiris. It was this really cool live-programming demo, where the code the user typed would execute automatically and make changes to the scene around the user. I had been building my own WebVR project at the time — something called Psychologist.js, which was supposed to be a more general-purpose framework — and Brian commented on it, which was really cool. We started talking about WebVR things in general. RiftSketch was very much a one-time deal and I was hoping to convince Brian to rebuild RiftSketch with Psychologist.js instead of hand-coding all of the VR interactions. To that end, I created this syntax highlighting text editor that I called Primrose as a sort of bait. Alas, by the time I had Primrose working to a reasonable level, Brian had moved on from RiftSketch for a while.

But then I had this really neat thing and it worked pretty well. I started getting more attention for Primrose. I put together my own “RiftSketch”-alike and Primrose was suddenly kind of popular. So I eventually just sunk all of Psychologist.js into the Primrose project, renamed it all just “Primrose”, and went back to working on the WebVR framework idea.

What knowledge and skills did you have prior to working with WebVR and how did these help you when starting out?

Probably everything in my entire life has prepared me to work on this particular project. There is a weird concept floating around that there is such a thing as “useless” knowledge. Some programmers don’t think they need “math”, when programming is really nothing but a field of applied mathematics. A lot of programmers think their liberal arts classes were a waste of time, that history and art were just classes to get through to get their degrees and move on. But the more you learn and the more experiences you have, no matter what it is, the more vital, creative of a person you will be. Creativity and invention is really just making connections between seemingly unrelated ideas that are already in the zeitgeist. Wouldn’t a VR experience that faithfully acted out all of the plays of Shakespeare be a really great thing? How are you going to build that without knowing English literature? Wouldn’t it be great to have a VR training tool for knitting? There’s just so much to learn in the world. None of it is useless, the trick is finding the excitement in it.

I grew up during the big transition from 2D console games to everything being 3D, with the Playstation, N64 and more affordable PCs. I was fascinated with 3D graphics and learned a lot about how optics and human perception worked even before getting to college. But we couldn’t afford most of those things, so I had to make do with books from the library. I’d read programming books with no computer on which to type the examples. There was a brief trend when I was a kid of comic books being drawn in Red-Blue anaglyph technique, and I learned how to replicate it by hand with colored pencils. I gobbled up books on photography and holography. There were stories about Virtual Reality at the time, in books and movies and news stories about arcade games. I thought, if we couldn’t afford it, I’d be able to build all of this stuff on my own some day.

When I first started teaching myself to program, I started with C but eventually switched to this “new” language (at the time) called JavaScript. The potential to be able to write games that ran in any user’s browser, without needing to know anything about their operating system or requiring them to download another program, was immediately obvious. It would still take a decade for computers to get fast enough for many people to bother, but for the early adopters it was obvious where everything was going.

In college, I studied computer science, with a focus on computer graphics, which taught me a lot of math–linear algebra was specifically useful. But I also learned I hated 3D modelling, and so I thought that was the end of my game development career. I went into enterprise software development, where I learned a LOT more about web development and databases and authentication systems and project management and all kinds of useful things. I excelled at a number of my work projects along the way because of my math and graphics background: mapping, simulation, etc. So while I never got into professional game development, I ended up on a better path in terms of breadth of skills and career advancement.

Then about 5 years ago I quit my job and went freelance. The freelance perspective is very interesting. You have to learn very quickly how to motivate your own work. And I’ve always had hobby projects on the side. I had once even built a cardboard box stereo viewer for smartphones three whole years before Google Cardboard was released, but smartphones at that time just weren’t fast enough. It was a pretty constant learning experience of trying to release projects, seeing what I was capable of, and reiterating from there. Trying to roll the boulder a little further up the hill before it rolls back over and crushes you, and then getting back up and doing it again. That’s the most important skill.

What would be your key suggestions for developers looking to get into WebVR?

You will probably want some sort of experience in programming before you move into building your own WebVR experiences. There is a lot to learn and it can be very overwhelming if you’re adding VR on top of that. This is only compounded by the fact that VR in general is still very open-ended and undecided on how certain key issues will work. For example — nobody knows a good way to do text input yet. Some people have trouble typing without being able to see their hands. Hand tracking is extremely expensive and very few people have the hardware available. Mobile VR viewers don’t have keyboards hooked up to them at all. And virtual keyboards are too slow to use for large amounts of text. So be very prepared to talk with people in the WebVR community. It’s still kind of the Wild West out here, and a lot of the documentation is incomplete, or changes daily. But it’s really easy to get involved and the WebVR community is very friendly. Just don’t be surprised if there is no answer to a particular question or the answer changes from one day to the next. We’re all still trying to figure this out.

I’m certain there are plenty of unique challenges in working with emerging tech like WebVR! How do you tackle these challenges?

It all comes back to the project management challenge. Even if you’re just working for yourself, you want to make estimates of how long it will take you to build things, and then try to commit to an end-time when you will decide you’re done with it. I like to say “the best way to get the work done is to get the work done.” That means, there’s no secret trick that will get things done for you. At some point, you just have to decide — “this is what we’re going to get done and we won’t leave this spot until it is.” It’s a self-discipline thing.

And that’s for all kinds of problems. Yes, WebVR is in flux and that flux can cause some occasional setbacks. You can either give up and go do something else or you can choose to dust yourself off and keep plugging on. You feed problems of all types into one end of the machine and you grind it until solutions come out the other end. Show up and do whatever is necessary.

With that said, it can be difficult to get past the upfront hardware cost of VR. You can get really far with a smartphone, a $5 pair of lenses off of Amazon.com, and the cardboard box they get shipped in. That’s how I first started with VR work. A suboptimal solution today is better than a perfect solution on a tomorrow that never comes.

What methods or design choices do you make to avoid causing motion sickness when people use your VR experiences?

Sim-sickness is 100% an interface design problem. People are really worried about the performance specs that Oculus has quoted and the fact that you have to render the image twice. But it’s not graphics quality that causes sim-sickness, it’s loss of agency that is the culprit. Never take control away from the user. I don’t do anything with a cinematic bent to it, so this is not usually a problem for me. But you cannot ever show something to the user that disagrees with how they expect things to move.

That is to say, try to remember “first, do no harm”. As long as you’re hitting the native display refresh rate, you’ve got the vast majority of the population covered. A low-poly experience in VR is more awe-inspiring than max-graphics setting of any of the latest games on a 2D computer display. It’s just no comparison. I’ll take PS1-era graphics in VR over the latest Call of Duty on the best desktop PC, any day of the week. After that, it gets hard to make recommendations. It’s going to largely be up to your specific scenario.

As for how to maintain frame-rate: Profile. Profile. Profile. You will be really surprised to see where you’re code is spending most of its time. I can’t make any specific recommendations because it’s usually something I never expected that takes the most processing time. I’ve been doing this for 20 years now. So don’t think you’ll make really good guesses as to what is or is not a performance-critical feature. Just profile and find out for sure.

Do you have any advice for developers and entrepreneurs considering getting into the VR space overall?

Make sure you’re either A) doing it for yourself, or B) addressing a real need. Primrose largely started out as something for myself, but then other people got interested in it and that proved a need. I don’t recommend counting on that transition. But in general, as long as you’re satisfied with what you’re building, then you’re doing better than most people.

If you want to make this your business, then realize the market is incredibly small right now. And by small, I mean non-existent. It’s only been in the last few months that people could start walking in to a store to buy headsets of any kind, let alone good ones. You will want to stand out. Do something that nobody else is doing. Don’t be yet another social, 360 video viewing app. I see three of these things get released every week. There’s no market, yet the market is already saturated with them.

Build one for fun, if you want. Just not profit.

A 1977 Commodore PET in one of Sean’s Primrose demos!

What is your favourite WebVR app you’ve seen so far?

There was a project called Info Grove by Eric Neuman. I wish I could find it again, but it looks like he’s replaced it with a mobile app. It was basically a way to search Wikipedia in WebVR. But it wasn’t just a browser window hovering in the 3D space. Each article would get “planted” in the ground, and as you linked between and loaded new articles, they would show up around in relation to the original article. It was a really cool way of using space to represent relationships in data that stock Wikipedia doesn’t provide. It gave me the spark of an idea that VR interfaces could eventually be superior to the GUI interfaces we’ve had for the last 50 years.

What was the weirdest bug you’ve experienced when developing with WebVR?

That would most certainly be the six-month long period where nobody–including myself–noticed that Primrose was not actually rendering a stereo view. The code to offset the camera between rendering each eye was not working correctly, so the two eye images were identical.

Nobody noticed because it turns out that image parallax due to binocular vision is one of our least important depth cues. It only accounts for things that are within about arm-reach. For everything past that, we get depth cues from recognizing the relative size of the object and by seeing how the object moves in our field of vision as we move. We are very, very susceptible to optical illusions.

How can people get involved if they’d like to help build Primrose VR with you?

Check out the Primrose documentation site. There is some information there on how to use Primrose. You’ll also be able to find your way to the GitHub repository for Primrose from there and be able to get in contact with me through GitHub or my email. The documentation grows every day. I’m pretty friendly, so don’t be afraid to ask me questions. Get yourself into the WebVR Slack group and you’ll be able to find me there, as well.

Any final thoughts you’d like to leave us with?

There are going to be a lot of people that tell you “don’t”. Don’t use that programming language, it’s no good. Don’t make that thing, you’re “reinventing the wheel”. Personally, I know off the top of my head of at least three times in the twentieth century alone that the literal, actual wheel itself was successfully and usefully reinvented. These people have the time to tell you “don’t” because they are not productive individuals themselves. Ignore them.

If in doubt, try it out. I’ve noticed a lot of beginners these days want to know the “best” way to do things right away. A lot of beginners are fearful of doing the wrong thing. They post to StackOverflow and then wait for an answer, rather than hacking away to see if they can’t come up with an answer. First of all, there is almost never a best way to do things. Second, you’ll learn a lot more from failure than you will from success. Optimize for action. Embrace chaos. And if you’re going to break something, break it as hard as possible, to serve better as a reminder that it needs to be fixed. I think that’s also why there is some hand-wringing going on over the supposedly high number of competing JavaScript tools on the market these days. There is an anxiety over not being able to evaluate which is best, so to be safe we must learn them all. Learn none! Strike your own path!

I’m just a guy. I don’t really have anyone helping me out on the vast majority of this stuff, from coding to marketing. I’ve had to learn it all along the way, over basically the last 20 years. That seems like a long time, but that’s just my particular path, with fits and starts along the way. Regardless, the future always gets here. It doesn’t matter what you know going into a project. Trust yourself to be able to learn and devote the time to ensuring your own success.

A lot of people define failure as not having achieved a certain goal. That’s backwards. If that were the case, we are all failures for the vast majority of our lives. Failure is when you give up and compromise yourself. For me, failure would be to take an office job fulfilling someone else’s entrepreneurial dream and no longer having Primrose to work on. As long as you keep your head above water, you’re not failing.

I’m not sure I can thank Sean enough for taking the time to share his thoughts and experience on developing in VR! Thank you! If you’d like to follow Sean’s VR adventures, you can find him @Sean_McBeth. You can find his WebVR framework, Primrose, over at primrosevr.com. Give it a go, it’s a lot of fun.