This article is much longer than I would have liked, yet I wasn’t able to dive into each of the subtopics in as much detail as I would have hoped for. Still, it provides some foundational material for a later examination and proposal for a metaverse implementation. If you are a serious virtual world or metaverse enthusiast, this article is probably for you. The more casual reader may want to skip this article.
If you are involved in a metaverse project, you may find it referenced below. Nothing you read here should be considered a harsh criticism of any one particular approach. In most cases, these implementations are named to illustrate an example or a counter-example. This article doesn’t attempt to perform a complete review of platforms or to call winners.
Previously, we identified seven issues which hold back our current metaverse implementations. Can a metaverse actually break through all of these issues to become a major platform?
What if we build on a distributed services architecture? Should we position the desktop client as a 2D/3D content browser? What if we use open standards, or build upon a proven engine? These and other suggestions may turn out to be very good ideas, but we don’t know. We’re still trying to understand the underlying issues which are holding us back.
SPECIFIC PROBLEMS ILLUSTRATE SYSTEMIC ISSUES
Clearly, there are more problems than the original seven which were provided in the first article, but those seven create a pool from which we can look for more systemic issues. Read More…
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…
There is a story retold in the virtual reality community which emphasizes reaching perfection through a quantity approach over a quality approach. The text originally came from the book Art and Fear, which is about the process of making art. I like Derek Sivers’ shortened version, so I’ll repeat it here.
The ceramics teacher announced he was dividing his class into two groups. All those on the left side of the studio would be graded solely on the quantity of work they produced, all those on the right graded solely on its quality.
His procedure was simple: on the final day of class he would weigh the work of the “quantity” group: 50 pounds of pots rated an A, 40 pounds a B, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an A.
Well, come grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity!
It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
Sure, you have to question the authenticity of the story, but for most people, the lesson rings true. This is the lesson that we should walk away with, right? Quantity trumps a quality approach when trying to reach perfection?
No. Not at all. It is critical to understand the story in its original context. Read More…
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.
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.
- 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…