Join ourDiscord

It's time for a spring clean - Unity SDK v0.1.0 update!

Supporting way more different player rig types, and improving stability.

We ended up practically rewriting it, for great profit!

It's been a couple of months since we started distributing our Unity SDK, and we've learned a lot from your workflows. In the interests of making things more flexible whilst not making it more complex, we've actually started over. Let's go over the improvements!

Player rig flexibility

The way we did things before was simple, if you were using the standard SteamVR asset. If you weren't, it was a huge (and unreasonable) task to get things working. Then on top of that, even when the LIV® App wasn't connected, you had extra gubbins in your scene. This was particularly a problem in newer versions of Unity...

The LIV® component in the Unity inspector.

Now, however, we've got a single component that you add to any GameObject in the scene. It doesn't do anything until the LIV® App connects and there's a valid setup to use, so there's no risk of breaking things in your Oculus SDK build, or if someone's not using LIV®. Setup is simple - there's only two required parameters, and you'll get errors in your output log if it's not set up properly! For detailed instructions, check out the included readme. It's pretty comprehensive, but you can always contact us if you need a hand ;)

Hiding things from prying eyes

So your game is multiplayer, and you want to prevent cheating - with the new version of the SDK, it's easy to hide objects and UI that you don't want shown in the output. We're using Unity's handy layers to accomplish this, and you can change the mask that the output uses in realtime, programatically.

On the LIV® component, there's a LayerMask property called "Spectator Layer Mask" - this is the one you want to change!

Example: A multiplayer shooter

A player could use the LIV® App viewfinder to look around corners and anticipate enemies before actually seeing them, which is... cheating. Lame. However this can be easily solved by setting the enemy's layer in Unity to one that's not rendered on the viewfinder. This would prevent all enemies from ever showing in the output. Quick, and dirty. There's a smarter way too:

Using Frustum Culling from the player's eye camera, set the layer of each enemy based on their visibility. You might also want to do an occlusion check too, to make the result even better.

Example: An art application

You might want to hide the UI from the output when your users are using things like reference images or objects, or even their controllers.

Think creatively - there may even be some overlays you want to include only on the output, like the current brush settings. Think about what the spectator is interested in!


Of course, this is a bit of a cop-out feature to list, however we've rewritten the camera acquisition logic so that users with virtual controllers or virtual cameras no longer need to do the Harlem Shake whilst your game is loading. It'll also work directly with the LIV® App to support some of the more exciting features we have on the way, specifically targeted at improving streamer lives and enabling some incredible cinematography in realtime.

The component lifetime has also been greatly reduced - the moment the LIV® app stops compositing, it'll clean up all extra objects created and disable extra rendering. You can also disable the component programmatically and it'll clean up too, allowing you to choose when it's active.


There's a full, in-depth readme with contact info, common problems, and instructions included in the package, so please check that out. Get your sweet SDK sauce here!

Have feedback or bugs to report? Pop into our Discord and make your voice heard!

One discord to rule them all

We're a community of VR & gaming nerds, and there's a lot of us.

Pop in and connect with other VR content creators and developers, while getting early access to our creator tools as they are beta tested and released.

Or just join and share your favorite memes. We love memes.