It has been over a year since my last review of a vintage virtual reality book. I’ve recently come across a good one that I’d like to share.

In 1978, Richard Bartle co-authored MUD, the very first virtual world. In 2003, he shared his twenty-five years of virtual world and MMORPG experience in the book Designing Virtual Worlds. Here are some excerpts from the preface:

Too much virtual world design is derivative. Designers take one or more existing systems as foundations on which to build, sparing little thought as to why these earlier worlds were constructed the way they were.

Are designers even aware that there are decisions they can unmake? Although a good deal of design is evolutionary, that does not mean designers can’t be revolutionary, too.

The key is in recognizing the face that what seems eminently logical to you from your usual perspective might turn out to be disastrous when viewed from another angle — and then realizing that the worlds you’re drawing inspiration from almost certainly contain elements designed by people who didn’t recognize that fact until it was too late.

Obviously, the preface resonated with me on the topic of metaverse design.

The book is an incredible seven hundred and fourty-one pages, filled with decades of experiences and observations in virtual worlds. According to Wikipedia, it has been called “the bible of MMORPG design”. Read More…

BACKGROUND

A year ago, we started to look at how we might travel from one virtual world (anything from a simple program launcher to a more complex program like JanusVR) into a completely unrelated virtual environment.

As I searched for some consensus on how portal should look and operate, I wasn’t able to find any good guides which cover the topic. (The extensive use of the word portal by web-based companies has made it a particularly difficult topic to search.) This article is a (non-exhaustive) review of portals as a popular method used in virtual worlds today to transport the user to entirely different regions.

What are portals? Portals are typically objects or areas in the environment which advertise the ability for a user to approach and engage them in order to be teleported to a new location. Traditionally, they are placed vertically along a wall (and walked into), but they can be placed horizontally along the floor (and stepped onto). An additional action may be required, before or after moving an avatar into the aperture, to actually engage the portal.

Portals won’t be the exclusive means of long-distance travel within and between virtual worlds. What portals have going for them is that they’re already commonplace in virtual worlds, they can be visually integrated into many themes, and they’re easily understood by players.

In JanusVR, portals take center stage as the method used to connect otherwise unrelated virtual worlds.

UPDATE: The speculation didn’t last long. Valve has just released their OpenVR SDK which includes documentation for the Compositor. The actual implementation differs in some interesting ways, but the Use and Features section, below, is still a good summary of what Valve and Oculus are trying to achieve here. More details are at the end of this article.

INTRODUCTION

In March, Valve released a new concept into SteamVR called the VR Compositor. Like everything else at this point, the specification is not yet public. (So insert the standard speculative disclaimers here. If I flubbed something, please be forgiving, but let me know.) It shouldn’t be too hard for us to tease together what its function and purpose might be.

VR Compositor:

This is a new component of SteamVR that simplifies the process of adding VR support to an application.

Continues to draw an environment even if the application hangs.

Simplifies handing off from one application to another without full screen context changes by owning the window on the headset.

-Programmer Joe (Valve)

Let’s break that down a bit. The compositor grabs the VR display, owns it, and continues running. When a compositor-aware application wants to use the HMD, it goes to the compositor to request access to the HMD. The compositor hands a buffer to the application and tells the application to render into that buffer. Read More…

This article contains a listing of some metaverse observations and beliefs.

There do not appear to be any similar lists to compare this to, so your feedback on this list (and what is missing) is appreciated. I know that many of you can be tough critics, but constructive criticism is welcome. On the other hand, if this list strikes you as boring and unchallenging, that’s welcome news for me.

Observations

VR hardware and software is evolving rapidly.

Hardware and software solutions are not stable

Large investments can quickly become irrelevant

Poor solutions are quickly replaced by better ones

Continued investment is needed to stay current

There are limited rules for deciding what a metaverse is or how it should behave.

Many definitions exist

Fundamental definition is the ability to experience and perform actions with others in shared virtual spaces

Guided by previous attempts at metaverse implementation

Guided by current metaverse implementations

Guided by existing virtual worlds

Guided by science fiction

It is difficult to create a metaverse.

Barrier to entry is high

Expectations are high

Investment period is long

Significant investment required in money, people, and resources

VR ecosystem is rapidly evolving, adding to risk

Return on investment is unproven and uncertain

Competition already exists. There will more than one metaverse.

Stranded content

Fragmented userbase

Increased innovation

Increases risk for metaverse providers, developers, investors

Increased choice for users, developers, advertisers, investors

There will be many different possible sources of revenue for a metaverse provider to choose from.

Beliefs

For most companies, the metaverse will be used as an opportunity to extend their existing business models.

In the short term, major metaverse platforms which intend to use surveillance or data mining of their clients are less likely to fully disclose that information for fear of backlash and reduced adoption rates.

In the long term, major companies which are currently engaging surveillance and data mining of their clients are expected to continue that practice on a metaverse platform.

A metaverse does not need to limit itself to real-world constraints just for the sake of closely simulating reality.

The more complex and integrated a platform is, the slower that innovation becomes.

Users and developers are dependent on platform providers for technological innovation.

While competition can result in waste, it still remains a net positive for metaverse development. A competitive market is good.

The choices made in the initial design of a metaverse are critical to its character and its success.

A general-purpose metaverse cannot succeed inside of a self-contained bubble. It must interface with the real world to be successful. (Novelty will bring the users in, but utility will keep them.)

A metaverse could be embodied in different forms which have yet to be demonstrated.

A metaverse is most likely to be created and maintained by a small team effort, web-based company, or gaming company (rather than the telco or an organzied non-profit model as given in science fiction).

This is the third and final article (in a series) on the issues that face the virtual reality community as it finally enters a period of rapid and sustained growth. If you need additional context, please begin with the first article in the series, “Before the Eternal September of Virtual Reality“.

Developers

You are a developer, right?

That’s the impression that many of you gave Oculus when you agreed that you were purchasing a product that was intended for developers. If that is actually not the case, we’d like for you to stick around.

Given the amount of time that the development kits have been available, and the introduction of other “innovator” products (like Cardboard and Gear VR), I think that it is a safe bet that software developers are already a small minority in the VR community.

This time around, nobody is holding your order hostage until you click the checkbox with the correct answer. Do you mind giving this unscientific poll a quick response?

Only a year ago, we were using the original Oculus Rift Developer’s Kit (DK1). The community could be an unfriendly place for non-developers. Do you know how we tended to respond to those who were having problems finding good games and getting them to work? Repeat the mantra from the caption below.

“The Oculus Rift is Intended for Developers Only”

The image above is clearly a fake, as is the quote, but the sentiment was (and to some degree, still is) true. Even today, the Oculus Rift is intended for developers, and it works well for Oculus not to be sandbagged with end-user support at this time. Read More…

It was a short piece, mostly referencing an email from Fabian Giesen, a demoscene coder (and more) who was doing some VR work at Valve as a contractor. I’ll be honest, his message was a real downer for me, and I had my own Notch moment. Why was I working towards something that, if successful, would ultimately be used just to provide value to Facebook?

Over the past nine months, a surprising number of you have told me how those early Metaverse articles had actually been very helpful to you. A few of you said that you had a Metaverse effort going, but most of you were creating multiplayer virtual environments. Thank you all for your feedback and support!

I think the moment that it all crystallized and brought me back to Metaversing was seeing the return of Valve with the HTC Vive. Suddenly, it seemed like there were possibilities once again. Thanks, Gabe. I’m looking forward to learning more about your shared entertainment universe… perhaps a non-traditional Metaverse? Read More…

This is the second article (in a series) on issues that face the virtual reality community as it enters a period of rapid and sustained growth. If you need additional context, please begin with the first article in the series, “Before the Eternal September of Virtual Reality“.

Image Source: Wolf Quest (3D wildlife simulation)

The Wolves

Along with a massive influx of new users, how much thought have we given to malicious actors entering the fold?

Griefers aren’t anything new to virtual worlds. In last year’s article, Griefing and the Metaverse, we explored some of the problems that persistent virtual worlds have faced. In recent history, our new virtual reality applications have had precious little exposure to malicious actors. We can expect our isolation to end as more people begin to own VR hardware.

Developers, are you validating inputs on the client side and the server side? Are you hardening your multiuser code against those who would intercept and change their own network packets in-flight, or modify variables inside of application memory? Are you even creating an audit trail of anomalous events? Probably not. Very quickly, we’re going to attract the sort of crowd which will exploit such opportunities. Read More…

I watched a worldwide community die. Not just one. Hundreds of them.Thousands of them. As the National Science Foundation Network transitioned into the public Internet, everything changed.

Up until the mid-1990s, Usenet Newsgroups were the place to go for lively conversations and well reasoned debate on any number of topics. Social issues, technology, cooking, auto repair, you name it. The topic was already there, and people were ready to talk about it.

What we may not have realized at the time was that there was a secret sauce which made it all come together. It wasn’t the servers or the NNTP protocol which transported the messages across the globe. First and foremost, it was the people: the informed participants who were passionate and well-informed about whatever topic they had come to discuss. Read More…

Introduction

A famous quote from Gabe Newell is about a lesson that Valve learned early-on when dealing with the Internet. You can find it in Episode 306 of the Nerdist Podcast at 00:12:14.

Don’t ever, ever try to lie to the Internet because they will catch you. They will deconstruct your spin. The will remember everything you ever say for eternity. -Gabe Newell

At this year’s Game Developers Conference where Valve announced their Virtual Reality partnership with HTC, and at that time, Gabe made an incredible claim about the Lighthouse tracking technology:

So we’re gonna just give that away. What we want is for that to be like USB. It’s not some special secret sauce. It’s like everybody in the PC community will benefit if there’s this useful technology out there. -Gabe Newell (Valve)

The story which accompanies the interview describes Lighthouse as a way of providing infinite input solutions into Virtual Reality. “As long as tracking is there, anything can be brought into VR, like how USB ports enable you to plug (virtually) anything into your computer.”

What the Technology Brings

In the previous two articles, we’ve dug into the technology itself, and it supports what we’ve been told. Spend perhaps $100-150 for two of Valve’s Lighthouse units and mount them in opposite corners of the room. At that point, you can almost forget about them. But any enabled device that you bring into the room can take advantage of:

Rock-solid positional data with high precision and resolution

Rock-solid orientation data with high precision and resolution

Very low additional power use (passive sensors, undemanding electronics)

This is the second article in a series on the Valve/HTC Vive Ecosystem. If you have not already done so, please begin with the first article in the series.

Introduction

Today’s article will provide additional information on the Lighthouse units, explain the Lighthouse sensor system, and take a brief look at the sensor processing which is used to return the absolute position of a tracked device.

Strong Disclaimer

This particular article will try to tread carefully. There’s no way around it, folks. This article is going to contain facts, rumors, innuendos, and outright lies about the operation of Valve’s Lighthouse sensor system.

Why?

We’re working with publicly available information, which is scarce.

There is no documentation.

It is still in development and very subject to change.

There is no need for regular users to understand the underlying details.

Software developers can expect to be given an API that reports position without knowing any of the underlying hardware details.

Finally, for the time being, Valve employees are busy getting this stuff ready, and their time is better spent working on the product than answering all the outside questions. See page #9 of the Valve Handbook for New Employees for more details on how that process works.

We’ll have to assume that we’re on our own, for now.

Back to the Lighthouse for a Moment

I’m going to use the earlier research and development model for a reference.

An earlier model of the Lighthouse. Image source: UploadVR

Towards the middle upper left of the enclosure is a panel that has been mounted with LEDs. The apparent purpose of these LEDs is to widely emit a flash of infrared light which could have something close to the same perspective and range as the laser beams. Read More…