I'm a software developer for Hardlight VR, a virtual reality startup in Seattle, Washington. I work on the developer APIs and backend engine that powers the suit.

A critical aspect of API design is allowing the user to have feedback on their actions. When using the Hardlight API, many haptic effects may be active at once. These effects can take place all across the body, with varying strengths and waveforms. I designed and built an API to propogate this information from the lowest levels of the runtime all the way to the game developer SDKs. Using this interface, my coworker built helpful realtime visualizations.

Here, colors represent different waveform classifications, such as "click" or "bump". The opacity of the color represents the strength of the effect. Since we are a hardware startup, it's essential that we have some form of feedback for our developers when physical devices are not available.

In our runtime, lack of physical devices is not a special case. We can write configuration profiles for new or nonexistent devices, and these devices are treated the same as a real piece of hardware. As far as a game is concerned, there's no difference. At the lowest levels, this involved augmenting our hardware APIs such that all calls could be intercepted and simulated.

The Hardlight API is built on the idea that simple primitives can be combined into complex effects. One of the first abstractions we arrived at were emanations - essentially graph searches over a human body. An emanation may start at a point and move outwards, or move from point to point. Special considerations for proximity of nodes, both logically and physically, had to be taken into account. We also schemed up a few new ways of addressing the body - but that's for another post.

The creation of a haptic effect in the Unity Editor is simple. Under the hood, the data is recursively flattened into one of the Hardlight API's most basic primitives: a timeline. This timeline is then submitted to the system, and dispatched to available hardware. It's easy to get carried away with complex abstractions, but those belong in layers above the core API.

Following the idea that lower levels should be simpler and not depend on upper levels has allowed us to tear out and replace implementations while higher levels observe no differences. In an extreme case, we were able to backport a completely incompatible Hardlight API into a game by simple DLL replacement.

My coworker demonstrates an upper-body tracking prototype here, using Hardlight's tracking API. The data is ferried almost directly from the suit into Unity as fast as Unity can consume it.

When I first faced the challenge of delivering tracking data from our hardware to our game developers, I ran into a few dead-ends. Protocol choice is important here, because we want the lowest latency possible, the ability for multiple clients, and support for variable-rate polling. Finally I settled on a shared-memory solution after much research and prototyping. The Hardlight suit's tracking solves VR's arm problem - with only controllers and a headset providing tracking, kinematic solutions for the upper arms feel weird and get stuck on many edge cases. Now we can accurately display your real movement.

Images are courtesy of my excellent coworker Jonathan Palmer, who is responsible for Hardlight's Haptic Explorer and Unity tools, the subject of these gifs.

Shaders are computer programs that run for every pixel in your screen. If you know the math, you can create anything. I'm not quite sure what I've created, but some of them are interesting (like #4, not sure what's going on there.)

The series of WebGL shaders will load when you press the button below. Don't worry if it takes a few seconds!

Load Shaders