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…
If you’re reading this article, you’re probably already aware of the Valve/HTC partnership where HTC will manufacture the Vive, a virtual reality head mounted display, powered by Valve’s SteamVR platform.
As part of the reveal, one new piece of technology was introduced to the public: the Lighthouse. This is a brand-new-to-VR technology which will be used as part of a system to track the position and orientation of a user’s head mounted display and controllers throughout an entire room.
With Lighthouse, instead of using VR in a chair or standing in place, its room-scale VR feature allows you to use the space of an entire room as a stage to physically walk around in a virtual environment.
This article is based on publicly available information. Be aware that we are trying to explain a system that is unreleased, subject to change, and has very little publicly available information. Some elements of this article may prove inaccurate at a later date.
With any complex system, there are many rules, details, and exceptions to explore. This first article is just going to cover the tech basics (but will still be plenty meaty for many). We’ll consider more detailed issues in later articles.
A Basic Operational Review
The purpose of this first article is to clear up some of the common misconceptions concerning the Lighthouse technology. It will also serve as a starting place for additional articles on Lighthouse and on the various aspects of the HTC/Valve partnership.
By understanding how this one component works, we can understand much more about what HTC and Vive are trying to deliver to consumers. They’re not just cranking out randomly incremental or independent technological solutions here; Valve is running a very deep and highly integrated game plan.
If you’ve been following some of the posts here on Metaversing, you may have noticed a slant towards planning and design issues. This isn’t by accident. Many issues seem innocent or almost trivial, but need to be carefully considered before jumping into an implementation. A well thought-out design can save countless hours of trouble down the road in the systems development life cycle.
Today, I have an easy prediction: the Metaverse is going to be the stuff of legends for hackers, griefers, trolls, vigilantes, security researchers, and spy agencies. If you’re already familiar with the scene at the top of this article, then you know what we’re looking at: an in-world denial of service attack. Do you see it? Is it the guy in the pool with the antlers on his head? No? To explain, let’s go back to design. Read More…