In the beginning of his presentation, Joe Ludwig first took some time to explain the differences between SteamVR and OpenVR. After that, he talked about the SteamVR plugin for Unity, and how some of its features will be supported natively in Unity 5.4 and beyond.



SteamVR is considered to be the work that Valve is doing in VR. That includes the technology they've developed that's shipping with the HTC Vive, the APIs that are provided to application and hardware developers, and Steam itself running in VR.

SteamVR provides an in-application VR dashboard. Steam itself is included in this dashboard, and the Steam client uses public APIs to provide its overlay in the dashboard. The set of operations that Steam provides are what you would expect: launch games, browse the store, buy games, chat with friends, etc.. The dashboard also provides the user with access to VR settings from inside of the VR experience. It also provides access to controls of the whole system, such as turning off controllers, or exiting the VR system. SteamVR also provides the render-model API that gives access to high-quality models of whatever device the user is holding in their hand at the moment - this includes animation data for the device, and renders an animation depending on the current state of the controller, i.e. a button is pressed, or a finger is touching a point on the track pad. All of this mesh and texture data is provided to the application so that it can recolor or light the controller model in an appropriate way.

SteamVR also provides a system to allow the user to define the boundary of obstacles that exist around the them in their room - this is part of the chaparone system. If a user gets too close to the boundary, the outline will appear in their HMD to warn them that they're about to collide with the real world. For headsets that have a forward-facing camera, such as the HTC Vive, chaparone includes the camera view of what the user is about the run into. Inset into the chaparone bounds system is the safe-play area that provides applications with a guide of where to place objects for the user to interact with. If your application puts something inside of that blue rectangle, the user will be able to reach it. This all scales from a seated experience up to a full-room experience.

Another API that the application interface allows is the notifications API. Right now Valve is using it for Steam toast alerts, but VR applications can use this API for whatever they want. These notifications can appear wherever the user is and they can interact with these notifications however the developer wants them to. There's also support for a VR keyboard that allows the user to enter text with the controllers.


In addition to these user-facing tools, SteamVR also provides performance timing tools to developers. The graph below shows how much CPU and GPU time is being spent by each component of the system, and this helps the developers determine where the bottlenecks are.

This is all available inside of every OpenVR application with no effort from the developer.


OpenVR is the pair of APIs that Valve provides for interacting with the VR system.

The first API is the API that's used for developing VR applications. This includes providing object transforms, an interface to the compositor to send textures to display on the HMD, up-to-date input state of the controllers, access to device models at runtime, access to the user Chaperone system configuration, and more. Supporting this API through an application allows developers the flexibility of not only accessing current VR hardware in an abstract way, but also hardware to come from new and existing manufactures.

The other OpenVR API is for devices - the driver API. Hardware developers use this API to add new devices to the set of things that work with OpenVR. When hardware developers use this API, existing applications have immediate access to these new devices. So, for example, as Joe Ludwig said, if 100 OpenVR applications ship this year, and next year a hardware vendor releases a new OpenVR driver for their hardware, that hardware will immediately gain access to all 100 of those applications. And this happens without application developers having to update their titles.

What makes OpenVR "Open" is the lack of barriers between application & hardware developers and their customers. There's no requirement to ship on Steam. There's no restrictions on the type of content that can be made. The only people involved in deciding what's good enough are the developers and customers.

So in conclusion, where OpenVR is the API, SteamVR is the customer-facing name that users actually install as part of a larger system.


While many of the games being developed for VR are using the OpenVR standard, they're also using the Unity game engine through the SteamVR plugin. Noticing the large number of developers using Unity, Valve wanted to gain some experience with it firsthand...

Valve used the plugin firsthand to develop the Secret Shop VR demo that debuted at The International 2015. Secret Shop uses characters from Dota 2 and pulls them into a 5-minute interactive story. Those Dota 2 assets were pulled in straight from Dota 2, and the demo was built-up from there.

Unity is also used for tools that are shipped as part of SteamVR, such as:

• The Room Setup tool that the user runs to tell the system where the physical obstacles are in their environment.
• Demo-transition content.

But why choose Unity? Joe says that the main reason why Valve is using Unity is the same reasons other developers are using Unity: it's fast to get up and running, and allows developers to focus a lot more on content. Valve recognized the popularity of the engine among developers, so they wanted to get firsthand experience for themselves. But this is not to say that Valve has abandoned their own in-house engine (obviously not), but Valve thinks that solving everyone's problems also solves their own problems.

Valve has some challenges with the SteamVR Unity plugin, and both have to do with performance.

For one thing, traversing the game scene is slow. Because SteamVR is supported through a plugin, it doesn't have access to the VR-specific optimizations that Unity has added to the engine. Rendering the scene from two independent cameras is what you have to do with a plugin, and so the scene is traversed twice, effectively doubling the width of necessary optimizations for performance. To fix this problem, Valve has a few things they'd like to do.

First, OpenVR is being added to the native VR API in Unity 5.4. Valve has been working with Unity on this, and it should be in the 5.4 beta in a few weeks. This will be a free integration for all Unity developers. This means that the SteamVR plugin is going to change. Some of the work that the plugin does in Unity 5.3 will be moved over to the native Unity VR API in 5.4 - specifically rendering and tracking. Features that are not supported by the Unity VR API will continue to be supported by the plugin, and that includes controller input, overlays, and render models.

When you write application to the Unity VR API, it selects the Oculus SDK, OpenVR, or mobile or console VR SDKs. But if you are writing your application for a platform that is not yet supported, you will continue to go through the SteamVR plugin.

A new feature coming to Unity 5.4, either in the SteamVR plugin or a new, separate plugin, is Enhanced Rendering. VR applications on the PC need to render at 90 frames-per-second, and that's the native framerate for the HTC Vive and Oculus Rift. It's important to hit that target so that the user is as comfortable as possible. It's hard to do, but that's where Enhanced Rendering comes in. Valve's Alex Vlachos gave a presentation at GDC 2015, and he described many advanced rendering techniques for VR, some of which will be pulled into the SteamVR plugin for Unity. The techniques are comprised of shaders and scripts that improve rendering performance for VR applications.

Lighting, specifically dynamic lighting, is a big part of the Enhanced Rendering plugin. Level designers and artists want to include as many dynamic lights as possible because it increases the richness of a scene. But having many dynamic lights has a cost, and so that's where deferred rendering will come in. Unfortunately, deferred rendering does not support MSAA, which is very important for VR experiences. So with Valve's Enhanced Rendering plugin, they're taking a different path. Dynamic lighting is the goal, but instead of deferred rendering, they're going to specific provide better support for dynamic lights in Unity. The plugin supports up to 10 shadow-casting lights per one draw call, which is an upgrade from current Unity specs which only supports 4 per draw call. So because the plugin will still use the forward renderer, MSAA will be available.

The Enhanced Rendering plugin itself is easy to use. It adds a camera component to the camera properties, and this allows you to control shadows and also hides the faster materials to make it easy to find the ones that haven't yet been switched over to the new model. There's also a new realtime light component to set lighting parameters. Finally, there's a new materials shader. This Enhanced Rendering plugin should arrive in the Unity Asset Store for free sometime around the GDC 2016 timeframe of early March.

For anyone who is going to start delving into the SteamVR Performance Test files for themselves - it’s worth noting much of the unused and assets are actually taken directly from Half-Life 2 and Portal 2, so don't get too excited at the sight of "Half-Life".


Numerous Half-Life 2 assets, including models for Dog, Antlions, and more, can be found throughout several maps, with the code, animations, and models being used simply as test assets, removing the need to create everything from scratch.

As with most modern Valve leaks, these builds of Aperture Robot Repair also feature numerous code strings directly referencing “HL3”, “RPG”, “L4D3”, and more. Unfortunately, most of the code strings found in these particular leaks are similar, if not identical, to those previously discussed, so we won’t waste any time covering them again here, as most of these references are very out of date, and are not nearly as exciting as they sound. Here are a few examples…
That is far from all, however, as we have also come across a number of juicy pieces of evidence for characters set to feature in future Valve games. Some of you may remember seeing a high quality model of Dog from Half-Life 2 posted to 4chan a while back, which has once again shown up in this build. The model is identical to the one previously shown, allowing us to identify that the mysterious, unnamed 4chan leaker also has access to the same Aperture Robot Repair builds that we do. Here’s a preview, along with where to find the model!


As you can see, this new Dog model is far higher quality than the one used throughout the Half-Life 2 saga of games, and features numerous new components spread across his body, including wheels, gears, wiring, armour plates, and bolts. Despite also having an updated City Scanner head complete with texturing, it’s not clear if this Dog model was or is intended to feature in Half-Life 3 or any future Valve product, but we also wouldn’t be surprise if it were the case.

Considering this model was developed by Tristan Reidford, it’s also possible this model was created to be used as a 3D reference for a toy statue of Dog hinted at by Instagram user ashleywoodart back in March of 2015. Although the model was never released, it may still be in production as Tristan previously worked on the full-scale replica of the Gravity Gun released back in 2013.


Half-Life 3 isn’t the only game to get a small preview with these leaked files, however, as textures for a playable character known as the “Retired Engineer” can also be found, with his directory referencing “L4D3” - aka Left 4 Dead 3. Here are all of his completed, high quality textures in all their glory.


Aside from Dog, the Engineer, and the obviously-included characters such as GLaDOS, Atlas, and P-Body, we have also come across numerous other files for unrevealed characters with unknown origins, known as “biped_male”, and “adult_01”. Here’s “biped_male”.


...and here's "adult_01"...

There are also references to "nocturnal", an NPC which could very well be related to the Left 4 Dead series' infamous Special Infected creatures. Unfortunately, these builds don't feature any textures or models for the creature, so there's no way to prove this theory or to find out what it looks like.

The non-specific file directory of “vr\models\characters\npc\materials” gives us little extra means to identify exactly how these characters were or will be used, or what their exact origin is. It is possible one or all of these characters are linked to sequels of Valve games, but we’re not going to jump the gun by flat-out stating what simply cannot be confirmed. For now - just enjoy staring into their cold, dead eyes!

We’ve decided to clump the Dota 2 “Secret Shop” and the “Longbow” archery demos together in one category. It’s not because their projects are in anyway related - but because they both share a similar history of starting out as smaller projects within Source 2 before being ported and finished in Unity. This version of the Secret Shop features a vastly different layout and design than the final Unity version, with a larger room and a far more basic exterior. The Shopkeeper’s voice line is the only audible sound featured in this version.
As the video below shows, neither project got particularly far along before being restarted and ported into Unity, with various versions of the Secret Shop existing with no textures, few animations, and no real focus on interactivity of any kind.

Although a brief appearance, the Left 4 Dead series is also featured in these lost files in one singular map. The map, shown below, takes place exclusively in a rundown barn and features numerous themed props, such as barrels, tables, and weapons / equipment taken straight from Left 4 Dead / Left 4 Dead 2. We believe this map was also designed to show off the new Retired Engineer character previously mentioned.


As you can see, the map’s intention was to show off Left 4 Dead characters and props in a virtual reality setting, possibly allowing the player to walk around in a small space and view Bill, Zoey, Louis, or Francis and their equipment from various angles. Unfortunately, the version of the map included with Aperture Robot Repair doesn’t feature any their character models, leaving the experience rather empty and pointless. It’s worth pointing out this map’s inclusion does not reflect Valve’s potential plans for VR games - it’s just a test bed to find out what looks good!

A previously unreleased model is also featured in the map, as shown during our video. The C4 model featured on the top of a barrel was previously only seen in the Counter-Strike: Global Offensive launch trailer, but is actually accessible from within the files of Aperture Robot Repair. Take a closer look!

Considering this branch of Source 2 is largely focused on showing off virtual reality within Aperture Robot Repair, the majority of the included maps feature mechanical or animation tests for various components planned to appear in the final demo. One of the largest examples of such maps is a test for how Source 2 is able to load in massive prefabs worth of assets, with this particular map loading in the exterior of the Aperture labs featured in the final few minutes of the completed demo.


As shown, pressing the Green button will load in the external sections of Aperture Science, while pressing the Red button will then remove them again, showing how Source 2, like many modern engines, can dynamically load large amounts of data using prefabs. It’s worth pointing out this technique is not actually used in the final version of the demo, with Valve instead extending the draw distance to reveal the world beyond without sacrificing frame rate earlier on.

Although just another of the many Aperture Robot Repair related maps included with various builds, we decided to include this particular example to better show off the “Bendy” animation featured when the player opens the drawer in the early stages of the demo.


It’s not exactly important, but damn is it cute!

Despite being one of the simplest and least interesting maps in the whole build, we thought we’d briefly show off this small timer built by Ken Birdwell, one of Valve’s longest standing software engineers.


The basic map featured a rather nice looking clock and a functioning timer used throughout multiple other maps to check the timing of animations, game mechanics or other systems. One such map includes the aforementioned “drawer_anim_testmap”, where the functional part of the timer can be seen working away in the background.

One of the personal projects featured in the files, known as “vr_valve” appears as a partial reconstruction of Valve’s offices in Bellevue, Washington. The unfinished map is built largely from blank brushes covered in developer textures. As a player, you are able to walk around the offices, exploring Valve’s various cabals and rooms, some of which feature temporary, featureless workstations.


Although Valve’s real office is spread throughout various floors, the “vr_valve” map unfortunately only features one of them, which is then copy and pasted to create a second identical to the first.

The most abstract and unusual demo’s featured alongside Aperture Robot Repair are tests based around “cockpits”. Designed as basic virtual reality experiences, the player would have been allowed to walk around a small room within a large spaceship or space station before stepping onto a platform which opens up to reveal a details cockpit rising from the floor. With the player stood in place, the cockpit closes and begins to lower back into the floor and out into space, where the player can see the detailed interior of the ship, a large starfield, and a few nebulae.


Although it’s easy to see how some may jump to conclusions and claim this content is clearly related to Valve’s long-cancelled Stars of Blood project, this is most definitely not the case once we examine the portfolio of Tristan Reidford, a concept artist at Valve. As shown below, the portfolio shows numerous high quality screenshots of assets featured in the demo, and even a few of those not used at all. The portfolio also allows us to identify that the assets featured in the demo are, at the very least, older than January 2015.

Definitely one of the most unusual, abstract, and empty maps featured with the build, this level features little more than a grey platform hovering in space, the large starfield previously shown off in the cockpit demo, and a gigantic version of Dota 2’s Shopkeeper.

Keeping with the unusual and bizarre theme from “Room Extender”, a test room created by Valve’s Emily Ridgway, who is known to be working on experimental audio for virtual reality. Although clearly a basic map comprised of the same basic room layout many of the other levels,


If you want to know more about Emily’s work, stay tuned for her upcoming conference at GDC 2016, where she’ll speak to developers about her virtual reality-related audio findings.

One of the most visually pleasing maps accessible in the demo is known as “vr_platform_shooter”, and was at one stage set to feature as a gameplay-focused experience which challenges a player stood atop a tower to shoot 150 headcrabs as they roam around on the ground below. While missing many assets, including foliage and clutter, the map still features ground textures, a skybox, basic lighting, and some telephone pole cables, with a road and a small river visible below.


Given we’re examining these maps outside of SteamVR, we’re able to easily jump out of the tower’s invisible walls and explore the map more thoroughly, although the lack of assets makes it pretty difficult to enjoy as is.

As one of the weirdest, but most functional demo’s available, “defend_castle” challenges the player to guard a single, featureless block tower from advancing blue and green cubes. Green cubes must reach the tower to attack it at melee range, while blue cubes are ranged and fire small projectiles. As the tower is attacked, a health bar above it is reduced to 0%, where it continues to fall into negative figures. Although there’s no interaction in the version included, we imagine the map was to, at one stage, have the player swat away the advancing invaders with their Vive controllers while walking around the area in room-scale.


The red splashing X’s shown in the video are a result of missing particle effects used when a blue block’s projectile hits the target.

While not "test" assets of any kind, the Aperture Robot Repair files contain models representing the layout, scale, and structuring of stage featured at KeyArena during The International 2015. These were likely used by Valve during the planning stages to ensure their design was accurate and to-scale before signing off on the construction. Take a look!


Also included in the files are numerous high resolution models for a collection of Dota 2 heroes, including Queen of Pain, Mirana, Tiny, Disruptor, Tidehunter, and Dragon Knight. It seems likely these models were used to create Source Filmmaker shorts, but exactly which trailers or shorts they were specifically used for is unknown. Credit goes to SteamDB for these images, and those from KeyArena.

Similar to the Dota 2 assets we just highlighted, a number of SteamVR related models can also be found, which appear as various apartments set to be inhabited by the Portal series' "Bendy" character. The original models are incredibly small and appear very similar to those featured in promotional material and setup guides for SteamVR, although with some key differences (such as room layouts, etc). Increasing the model scale by a factor of 10 and loading them into a map yields impressive results, as shown below!


Thanks to SteamDB for preparing these models for us!