One thing that’s had me really excited in the social VR space lately is the addition of Eye Tracking and Lip Tracking functionality. In particular, this has been pioneered by Solirax’s NeosVR. Check out some neat videos of that here:
Great example of the hardware in action in the real world
How it looks on a variety of avatars
Foreword
I can’t be the only one who thinks that’s crazy right? In my time being around individuals who are using one or both of these technologies, I’ve noticed just how much more immersive it makes my experience just to observe it. It’s indescribable when you can see this level of expression carried over from the person’s face to their avatar.
But this led me to think- so far, I haven’t seen any guides that explain the full range of blend shapes that can be made for avatars to *fully* support this type of technology. So whether you’re someone who’s just interested in how many shapes it can have or someone who has the hardware themselves and is looking to make the ultimate expressive avatar, this guide is for you!
I’ll be going from shape to shape, and providing references using Neos’ own head model. For shapes that I think distinctly require it, I’ll provide a side shot. However, many shots are just going to be forward facing (unless otherwise requested)! Some of these shapes go unused in the current version of Neos, but are a part of HTC’s Eye and Lip tracking SDK and so are documented (and noted as unused) here in the event Neos integrates that data and enables them.
Note for mobile users: If you don’t see captions under each image, please enable “Request Desktop Website” for this page on your mobile browser!
The Pupil Shapes
While the reference head will be used for the remainder of the shapes in this guide, it doesn’t have blend shapes for pupil dilation. As a result, I’ve created an example in Blender and have amended it to the guide.
Neutral Eyes – This in itself is not a blend shape, but rather what the avatar looks like by default. AKA the Basis.PupilGrowL – Dilation of the left pupil, intended for areas with low light. Note that the size of the iris (the color portion) does not change.PupilGrowR – Dilation of the right pupil, intended for areas with low light. Note that the size of the iris (the colored portion) does not change.
The Eye shapes
Note: None of these blend shapes move the actual eyeballs. These are all for eye expressions using the lids and areas around the eyes. For eyeballs, you want to have your avatar set up with eye bones!
The neutral expression- this in itself is not a blend shape but rather just the model’s “Basis”. All blend shapes are set to 0.
Eye_Left_Blink – Completely closing the left eye.
Eye_Right_Blink – Closure of the right eyelid.
Eye_Left_Wide – The eyebrow raises on the left side to accommodate a wider eyed expression.
Eye_Right_Wide – The eyebrow raises on the right side to accommodate a wider eyed expression.
These next several (the Left/Right/Up/Down blend shapes for both the right and left eye) are not currently natively supported by Neos, but can easily be added to an avatar using LogiX. At some point I may see if we can get a community tool that automatically adds these blend shapes to your eye movements!
Eye_Left_Right – The left eyelid moves slightly to accommodate the eyeball rotating to the right. The eyebrow also raises a bit.
Eye_Left_Left – The left eyelid moves slightly to accommodate the eyeball rotating to the left. The tail end of the eyebrow also raises just a bit.
Eye_Left_Up – The left eyelid raises considerably to accommodate the eyeball moving upward. The arc of the brow raises.
Eye_Left_Down – The left eyelid drops to accommodate the eyeball rotating down. The beginning of the eyebrow lowers.
Eye_Right_Right – The right eyelid moves slightly to accommodate the eyeball rotating to the right. The eyebrow also raises a bit.
Eye_Right_Left – The right eyelid moves slightly to accommodate the eyeball rotating to the left. The tail end of the eyebrow also raises just a bit.
Eye_Right_Up – The right eyelid raises considerably to accommodate the eyeball moving upward. The arc of the brow raises.
Eye_Right_Down – The right eyelid drops to accommodate the eyeball rotating down. The beginning of the eyebrow lowers.
These next three (Frown and Left/Right Squeeze) are not currently usable in Neos, but the data is fed to the app and so can be enabled down the road!
Eye_Frown – Lowering of both eyebrows with a bit of pressure towards the center. Used to create sad expressions.
Eye_Left_Squeeze – Lowering of the left eyebrow/lid.
Eye_Right_Squeeze – Lowering of the right eyebrow/lid.
The mouth shapes
The neutral expression- this in itself is not a blend shape but rather just the model’s “Basis”. All blend shapes are set to 0.
Jaw_Left – A very visible movement of the jaw towards the avatar’s left side.
Jaw_Right – Very much the same shape, but now on the avatar’s right side instead of the left.
Jaw_Forward – Much better illustrated in the side shot, here the law is moved forward creating the appearance of an underbite.
Jaw_Open – a very full jaw opening. Almost reminds me of the movie “Scream”!
Mouth_Ape_Shape – Definitely very primate-like. Involved kind of a flattening of the lower facial features.
Mouth_Upper_Left – A movement of the upper part of the lip over to the left. Almost hard to see in this image due to the shadows but if you compare to the original image it becomes very clear.
Mouth_Upper_Right – A movement of the upper part of the lip over to the right. Effectively a reverse side mirror of Mouth_Upper_Left.
Mouth_Lower_Left – The lower section of the lip is now moved to the avatar’s left.
Mouth_Lower_Right – The lower section of the lip has now been moved to the avatar’s right- a mirror of Mouth_Lower_Left
Mouth_Upper_Overturn – An extension of just the upper lip, where it crosses well over the lower section.
Mouth_Lower_Overturn – Extension of the lower lip, crossing well over the upper section.
Mouth_Pout – Pushing out of both lips into a narrow rounded shape.
Mouth_Smile_Left – A smirk on the left side.
Mouth_Smile_Right – A smirk on the right side!
Mouth_Sad_Left – A half-frown on the left side. (Currently unused)
Mouth_Sad_Right – A half frown on the right side. (Currently unused)
Cheek_Puff_Left – Puff out that left cheek! Make it big!
Cheek_Puff_Right – Now on the other side!
Cheek_Suck – Sucking the cheeks in to create a very sunken in facial expression.
Mouth_Upper_UpLeft – A snarling expression on the upper left side of the lips.
Mouth_Upper_UpRight – A snarling expression on the upper right side of the lips.
Mouth_Lower_DownLeft – Pulling down on the bottom left side of the avatar’s lips.
Mouth_Lower_DownRight – Pulling down on the bottom right side of the avatar’s lips.
Mouth_Upper_Inside – Pulling the upper part of the lips into the mouth.
Mouth_Lower_Inside – Pulling the lower part of the lips into the mouth.
Mouth_Lower_Overlay – Moving the lower lip so that it is entirely covering the upper lip.
The Tongue Shapes
I want to quick put a special note for this section – all of these tongue shapes are done *without* the mouth moving. In order to capture this as well as possible, I’ve actually positioned the camera inside of the mouth. This way, you get a good view of the tongue!
This is the neutral expression of the tongue – not a blend shape in itself, but the tongue when zero blend shapes are applied.
Tongue_Left – Movement of the tongue to the left side.
Tongue_Right – Movement of the tongue to the right side.
Tongue_Up – The tongue moves upward. Notice how it curls a bit over the top of the mouth.
Tongue_Down – The tongue moves lower, in this case actually below the mouth interior mesh and into the area behind the jaw.
Tongue_Roll – A gentle condensing of the tongue into a rolled shape.
The next four blend shapes are currently unused and would typically be designated towards the fluid movement of the tongue. For now, they’re here mostly for reference.
Tongue_UpLeft_Morph – Kind of a strange shape. This one extends out of the mouth.
Tongue_UpRight_Morph – Kind of a strange shape. This one extends out of the mouth.
Tongue_DownLeft_Morph – Kind of a strange shape. This one extends out of the mouth.
Tongue_DownRight_Morph – Kind of a strange shape. This one extends out of the mouth.
And with that, the guide reaches its conclusion. The robustness of the expressions tracked by HTC’s Eye and Lip Tracking SDK give me hope for an incredibly expressive future in which we can convey ourselves more accurately in social VR. In the meantime, we can only hope technologies such as these will become more universal across platforms and headsets.
So we’ve spent a solid three entries in this journal covering the defacto open source desktop OS, Linux. Let’s try something incredibly closed source now, to the point of being able to be called proprietary. Let’s see how VR games and apps work on Apple’s MacOS!
The first thing we need to talk about is the hardware situation. While in a theoretical apocalyptic Windows scenario, I could use a flash drive and put Linux onto my VR computer with minimal effort, MacOS really isn’t the case. There are two ways to get a computer running MacOS, and the easier of those two requires getting an Apple-produced computer.
Anyone who has any experience with Apple products knows that MacOS is proprietary to Mac computers, and so in trying to obtain one someone could wind up paying hella dollars.
Wow.
It’s worth mentioning that only one of the Mac computers currently sold is especially VR compatible as-is, and that’s going to be that crazy expensive iMac Pro. Apple’s solution to this is in the form of Thunderbolt 3, a port that is included on most of the Mac computers released since 2015. This port allows the use of an external GPU, or eGPU. Typically, this involves slipping a desktop graphics card into a device like this one:
Currently, Apple charges $699 for an eGPU enclosure with an AMD RX580 inside, just meeting the specs to use a regular HTC Vive. While there are ways of establishing an eGPU setup for cheaper, it’s fair to say that this route is ideal for those who really like the smell of burning money.
So what options exist for the folks who want the convenience of Apple’s OS but don’t want to pay in kidney donations? Currently, a community online operates a means of running Mac on ordinary PCs called Hackintosh, or OSx86. Its a bit on the technical side to install, but it is getting much easier to do over time and once setup is surprisingly identical to the Mac experience minus the low spec hardware!
Luckily for me, I happen to have a lot of experience installing and using Hackintosh, so why not turn our VR PC into a triple boot Windows/Mac/Linux monster. I run Clover boot loader, install Mac on a separate hard drive, and voila! It’s alive!!
Post install, I configure a few things and then download Steam straight from the website. It immediately prompts me to download and run SteamVR, which I do! Wow, this is straightforward!
But sadly, it didn’t recognize the 2.0 lighthouses. So far, I still haven’t quite found a way around this on the Vive Pro. It’s very possible that Pro support hasn’t been added into MacOS yet. I check under the beta tab and try the official beta which doesn’t change anything, and I also notice that there are two additional beta branches- one titled macos_beta and another called macos_public. Sadly according to SteamDB, neither of these have been updated in quite some time and they didn’t seem to work whatsoever for me. I’d say stick with stable or beta if on a Mac.
But!! I still have this borrowed Vive, right? Correct, my friend! The Vive 1.0 lighthouses are detected and the SteamVR menu works, but… none of my library is compatible with SteamVR on Mac. And as of right now, Proton isn’t supported on Mac either! It appears to used to have been supported in early 2018, but support was dropped as Apple made a number of changes to MacOS that mandate features in Proton to be added. There’s a Github issue to track the progress of those features.
For the time being, I can firmly say this is not a path I would recommend. While Apple can go on stage and say that they support VR through the power of the HTC Vive like they did in 2017, it’s hard to make those claims given the exponentially higher barrier of entry. With that said, I’d still like to see more native Mac ports of VR applications for the folks who do want to use a Mac. I’ll be updating should the situation with Proton change, as well!
As it stands, there’s a lot to be said for VR on other operating systems. Valve is clearly pushing this forward more than anyone else, and I find that very commendable. At this point in time, enthusiasts with a SteamVR headset could get by using one on Linux, and game developers with a Vive can develop their games on Mac if they’d like to! I really look forward to a multi platform future, and down the road I will continue to update this series with new installments as things change!
Thank you guys so so much for following me on this journey, and stay tuned this coming week for a look into full body tracking/tracked devices- where can I use them, and what can I use them for?
It’s time at last to address the elephant in the room. SteamVR is key to enabling a VR experience for Lighthouse HMDs on any platform- and in the case of Mac and Linux, it’s key to enabling Virtual Reality whatsoever. Opinions of its performance in Windows are…
The entire spectrum of human emotion
…well, mixed.
And that definitely brings up the question of how close SteamVR on Linux can come to providing a good experience if the word is still out on whether or not it provides a great experience on the platform it was originally designed for. With that said, I’m here to try to answer this question and more.
SteamVR on Linux is not a perfect port yet, however it does have an amount of feature parity that will make it very usable for most. Let me say most, however. Not all. Valve’s current list of features missing from SteamVR for Linux include the following:
Even with Vulkan applications, performance issues are still being worked on on both the runtime and the game engine side
Desktop view in the dashboard currently doesn’t work (fixed in May 8 Steam client beta)
Power management of base stations is not currently implemented
Headset audio device switching is not currently implemented
The VR status window isn’t currently aware of direct mode being enabled or not, so the “enable direct mode” and “disable direct mode” buttons should not be used; direct mode is automatically enabled where supported
Firmware update of base stations is not supported (both USB and Bluetooth connections)
This actually sounds pretty awesome at face value! You can still use the system audio controls to change your audio devices with ease, many folks on SteamVR for Windows don’t even bother with base station power management, and base station firmware updates are infrequent enough that simply having a random Windows PC elsewhere in the home or dual booting Windows would alleviate that problem in the interim. The only remotely worrying thing here is performance issues, which are largely to be expected with something as developing as Linux VR support.
To use SteamVR for Linux is largely familiar- the same menus, the same icons, everything is effectively the same- but you’ll notice a lot of options and menus that are clearly around for the Windows version and either don’t do anything in Linux yet, or probably never will. A good example of the former is the totally empty audio routing menu where users would normally set the audio outputs for SteamVR to automatically switch to upon starting up. And example of the latter is the options to reset and disable power management on USB devices, and trying to use said options just brings up a window wondering why the hell you’re trying to run a .exe file on Linux.
So here I am, SteamVR is downloaded. Proton is enabled, games are prematurely tested, Vive Pro is now connected. At first, I start up SteamVR and the 2.0 Base Stations aren’t showing up. The headset, controllers… all of that is good. But the positional tracking simply isn’t happening because the base stations don’t appear to exist in SteamVR for Linux.
I wind up posting on the SteamVR for Linux github asking for help and in my own fiddling manage to come up with some kind of bizarre solution. Uninstalling Steam (which I had initially installed from POP! OS’s built in store) and reinstalling from the website seemed to fix it. Sweet! I’m in, right?
Well, it turns out… no. Not unless I’m a regular Vive user. Upon running SteamVR for Linux with a Vive Pro, users are confronted with distorted, glitchy sound and an increased likelihood of a total system freeze past the first minute of use. At first I thought this might be on my end but as I found out, this is a commonly reported issue among users with the Vive Pro hardware both on Steam’s forums and on the Github issues for SteamVR for Linux. Bearing in mind that Vive Pro users on Linux are quite small, I have yet to see a Vive Pro user get SteamVR for Linux working without these two specific issues despite the Pro having been released in early 2018. Oof.
So is this the end? Nope. Borrowed a regular Vive to test it out and voila! Like magic, SteamVR was right there, working great on Linux with barely a caveat. It’s amazing what kind of a difference there is between the issues with the Vive Pro and the ease of use with an original Vive HMD. I’m sure Index will get pretty fast support as well, but given that Valve is hoping to create a cohesive ecosystem, I’d like to see support around the board.
From inside of VR, everything is at once familiar. The dashboard, tracking, audio and desktop view- it’s all very familiar and if I wasn’t aware, I would’ve thought that I was playing Beat Saber on a Windows machine. What an awesome experience. Framerates for me were pretty close to what they are on Windows, and given that Beat Saber is a fully whitelisted title it only makes sense. My brief time in VRChat was also quite pleasant. Altogether, I didn’t notice much in terms of a frame difference, and audio seemed to work well.
So let’s talk about my conclusions now based on my brief time running SteamVR for Linux on a borrowed Vive. Would it be worth trying out SteamVR on Linux exactly as it is now? Yes! …But only if you fit in this exact category:
-Own an original HTC Vive
-Are comfortable with/willing to dual boot a Linux distribution with Windows
-Are willing to do some guessing and testing to see which VR experiences work great and which ones don’t, and perhaps are willing to submit some logs over to Valve to help get your favorite games supported in Proton
Don’t get me wrong, that’s a pretty hefty order. I can say that once the issues with the Vive Pro are fixed, I’ll likely have nights where I try to use VR exclusively under Linux if only to observe the experience and be able to provide feedback where I can. For now Linux VR is best used for the intrepid explorer who wants to make the switch to using Linux for VR more often as the year goes on, but knows the road might be bumpy and has Windows on tap for a smoother experience given current limitations. I do think a select handful of people may find all of their favorite VR titles do work under Linux as is and see a value in switching to it as their daily driver, but that group will stay small for a while longer.
That begs the question though… what if Windows and Linux were to get wiped out in one day, and the only way to use VR was to think different?
Ohhh man, here we go.
Stay tuned for Part 4: Virtual Reality Fruit. There will be Aluminium.
So where we last left off, I’d finished installing Steam onto POP! OS, a Linux distribution created for folks who like a streamlined Linux gaming experience. Key factor in our dilemma however- virutally none of the 70 SteamVR games in my library have native VR ports.
Introducing Valve’s Proton (Also known as Steam Play). This serves as an easy to use compatibility layer between theoretically any Windows game or app available on Steam, and enables them to be run on Linux to some degree. Anyone who’s familiar with WINE (Wine Is Not an Emulator) will be familiar with Proton as Valve has been providing funding to the WINE project and in turn has been devloping their own offshoot in the form of Proton.
Oof… the old days of WINE
In the past, people would have to do quite a bit of messy configuration to get an application or game running under Wine, but in Steam for Linux, the process is delightfully simple. Some games, like Beat Saber, have been whitelisted by Valve as games that have full Proton compatibility. These titles will show up in your library as though they were native ports, just with the Steam Play logo next to them. With the whitelisting comes a nice assurance that the game/experience will run very very well if not entirely comparitive to the Windows counterpart.
For games and apps that don’t have whitelisting however, one can enable Proton for all games by going into the Steam settings and under Steam Play, enabling the feature for non-supported games. As of the writing of this post, the current version of Proton is 4.2, I’d strongly recommend leaving it at the latest version instead of changing the box next to the SteamPlay checkbox.
Instantly, we notice a massive change in the Linux library- all apps, games, and VR titles now allow me to download and install them on the Linux machine as I would a normal Windows Steam title. Sweet! Upon running one of these apps, however, a warning does come up that informs me I’m running this using a compatibility layer and that as a result the experience could be… well, it could be literally anything!
You’re probably now wondering what the Proton experience is currently like for your favorite VR game or app! I’ll be exploring some of my favorites here, but I’m going to link to two sources I’d recommend checking out:
ProtonDB is the first one, it’s made for both VR and non-VR titles. It’s important to note the Proton version reported because every update massively improves Proton’s compatibility. This means that if you see an app that is crashing right away in Proton 2.3 and there are no other reports, it’d be wise to check elsewhere or try running it yourself to see if that’s improved since 4.2. Feel free to tweet me @casuallynoted if there’s a game or app you’d like me to try and report back on as well!
Valve’s own Github repository for Proton is a more up to date location for information, but it’s not quite as nicely organized and sorted. Check the Issues section and search for the game you’d like to see. One thing I also really like about their Github is that if you try a game and it doesn’t work, they easily guide you through posting the logs so they can check it out and try to see what they can do to fix it.
With this all said though, VR support specifically for any titles in Linux is very dependent on one more thing – SteamVR for Linux itself, and this is a whole other category. For the purposes of providing relevant information, we’re going to stick to Proton for VR titles in Desktop mode in this entry and then the next one will talk in depth about SteamVR for Linux. It in itself is an adventure!
For me, the titles that instantly come to mind when I think of VR apps I use the most often are VRChat, High Fidelity, NeosVR, and Altspace. I’m a social VR nut (It’s an addiction, please end my suffering). So for that reason, we’re going to download those four and see how things go running them in Desktop mode. At this point in time, I don’t even have my Vive Pro plugged in as I figure some apps require the headset to be disconnected before they launch into non-VR mode.
Status report time! I’ll also be including information on the possibility of native Linux builds over time.
Penguin Yoga?
Altspace – Wow, this game performs well in Desktop mode. Everything looks good, things load nice and snappy. I’d say it’s not a surprise given that Altspace is available on literally every VR platform out there aside from Mac and Linux, but according to ProtonDB it didn’t use to be this way. Serious props to Altspace for likely being good for whitelisting as is. The two things I haven’t been able to check quite yet are the audio situation with VR headsets and the video players Altspace uses. In regards to a native Linux (or Mac) build, I’ve reached out to Altspace for a comment and will update should I receive any response.
That moment when everything loads! Sweet Linux VRChat home!
VRChat – Pretty solid performance here as well, actually! The one big caveat to VRChat in Proton is that you have to rename the YouTubeDL.exe inside of VRChat’s files to something else (You can find it where VRC is installed under /VRChat_Data/StreamingAssets/). The reason for this is that as of right now Proton doesn’t contain support for the “Media Foundation” framework Windows uses for media playback. This is a known issue on Proton’s Github and hopefully will be addressed soon, but in the meantime going into a world with a video panel without having that YouTubeDL.exe renamed will crash the game under Proton. Aside from this I couldn’t find any other issues. Swell job, VRChat! Second place! When it comes to a native Linux/Mac port of VRChat, there are two canny posts (MacOS / Linux) for feedback but VRChat’s website currently states that there are no plans to port to other platforms at this time.
NeosVR’s amazing content hub – hopefully it’ll come to the Linux experience someday soon!
NeosVR – Neos currently loads the splash screen welcoming you to the metaverse, but then goes totally black and hangs until it’s force closed- this is due to Proton not having .NET framework 4.6, however there is also a Github issue for this, and hopefully resolution should mean Neos loads much further. Wasn’t able to test any more due to this issue. Frooxius, NeosVR’s developer, has stated that he would be interested in porting NeosVR to Linux and MacOS should the demand be there for it, and has created a repository issue for assessing said demand.
Sadly, the Hi-Fi VR experience is exclusive to Windows for now
High Fidelity – High Fidelity is a super weird case. In Proton, it crashes right away- before the client is even loaded. I’ve seen reports of an occasional brief launch before close, but in my testing I was unable to recreate this. As of right now, an issue exists on Proton’s Github but no one has identified the direct cause of the crash as it stands. The weird thing about all this though is that High Fidelity is technically open source- and both MacOS and Linux builds are able to be made by compiling the code located on their Github. These builds however do lack SteamVR support, which was added in by a community member (Christopher Hagg) in the fork located here. To date, High Fidelity have not integrated the fork into the main client or put the native builds up for Steam users so that they don’t have to compile Hi-Fi’s interface. An entry exists on High Fidelity’s Cannyand on their Github requesting that they make these exact changes to provide Linux users with access to High Fidelity in VR.
Wow, that’s a lot to look at. I went a bit in depth here, but you can really see the variety to which these apps respond to Proton. It’s pretty incredible. Many of the issues observed here have to do with Microsoft’s libraries and frameworks, and as they are integrated, the support will get even better. One important thing to take into consideration is that a lot of the frameworks causing trouble are more likely to be present in a social app than perhaps a game, so it’s my theory that VR games may have even better luck here. As I test out more of my library, my plan is to delve into the gaming side of things and find out how Linux handles it.
So what does this mean for me? In a fictional Windows doomsday scenario, I could go onto VRChat (my most used Social VR app at the moment) so long as I don’t plan to watch YouTube videos with friends, and hang out at the events in Altspace. I could manually build a SteamVR version of Hi-Fi each time a new release comes out to enjoy it in VR, but ultimately I would still be losing one important social community, and absolutely none of these experiences would be native. While this can be done, for someone like myself I wouldn’t altogether recommend it until Proton has improved further or until at least one of these experiences has a native build up and available.
For the time being, I’ll be posting two more sections in the immediate future- Part 3: SteamVR is going to discuss the full experience of using SteamVR on Linux, and will address one key thing to take into account when looking at using it, while Part 4 will cover MacOS and the extent to which SteamVR supports VR usage on a Macintosh computer. Lots of fun here! Thank you guys for tuning in, until Part 3!
One aspect of VR that I really appreciate is the increased sensation of user choice. I find that when tasked with making a decision in a Virtual Reality experience it often feels more pressing or weighted than a choice made in, say, a choose your own adventure book or even in a number of desktop oriented games. Add to that experiences that involve other people and the experience grows, leading to even more user choice.
I often wonder why the same user choice isn’t provided when it comes time to use our fancy head monitors on an Operating System outside of Microsoft’s Windows. As anyone with a foot in the gaming community knows, Microsoft’s OS certainly has a lot of relevance when it comes to the gaming community. For the longest time, Windows was the only Operating System that got the latest and greatest video game releases outside of gaming consoles such as Sony’s PlayStation systems and Microsoft’s own Xbox lineup.
Thanks to new technologies like Khronos Group’s Vulkan API and multi platform engines like Unreal and Unity, creating a game for multiple computing platforms is much easier- but why isn’t Virtual Reality gaming/use quite so lucky as its pancake counterpart? And by extension, why is being able to use VR on other operating systems important in the first place if most PC gamers use Windows?
I’m glad you asked, imaginary person!
As it stands, VR headsets for PC come in three major varieties- The Oculus Rift (and upcoming Rift S), Windows Mixed Reality Headsets such as Samsung’s HMD Odyssey, and SteamVR headsets such as the HTC Vive and Valve’s upcoming Index HMD.
At this point in time, Oculus/Facebook have expressed no intention to develop the Oculus software or device drivers for Linux or MacOS, and clearly Windows Mixed Reality will be staying integrated into the Windows platform. Valve does offer an in-development version of SteamVR that allows SteamVR headsets to function under Linux and Mac, albeit with some current limitations.
Looking at the latest Steam Hardware Survey, a very small percentage of Steam users have VR headsets in general- but of them, Oculus is currently in the lead:
Given that both Oculus Rift and Mixed Reality have a nice margin of VR users, the only Steam users that could choose actively to play on Linux or Mac are a small percentage of a small percentage of people- just two of those categories (Vive and Vive Pro). Everyone else simply doesn’t qualify.
One response someone might have to me here is “Ok, so you just answered your own question- barely anyone could even use Linux or Mac if they wanted, so as it stands it’s irrelevant!”. But that, at least to me, isn’t the case.
Don’t get me wrong, I actually like Microsoft. Windows is an OS I use fairly regularly and some things in Windows 10 are very pleasant improvements to the user experience. But as it stands, Microsoft of today doesn’t have a great record of shipping releases that are… the most stable.
Yikes.
As it stands, there is always a possibility that Microsoft could push an update that hits one VR platform or another with a critical bug, and it could hit pretty hard. Am I saying it will happen? Probably not without a fairly quick patch, but as it stands Microsoft has your PC VR experience by the balls… and the lack of user choice in finding a comparative experience in Android-based VR platforms or Sony’s PSVR doesn’t help either. Having the ability to switch to another Operating System and have a similar experience as Windows will absolutely provide a massive benefit to the VR community as a whole.
So I’ve tasked myself with one mission- find out exactly how a user like myself might go about still using VR after an imaginary Windows 10 October Update part 2.
Enter the penguin.
He waddle.
My first step was to install Linux. After doing some research, I settled upon POP! OS, a variation of Ubuntu Linux that maintains the easy user experience and great looking UI, but that comes with quicker updates to enable for a smoother gaming experience.
After prepping a thumb drive and installing POP! onto my VR computer, I started by installing Steam. I’d recommend if you follow in my footsteps that you install Steam directly from the official website as the integrated POP! Shop may not install the necessary USB perm files to enable SteamVR games/apps to work nicely with the hardware.
I also have been one of the majority using an Oculus Rift, so for the purpose of investigation I decided to get ahold of a Vive Pro kit to test everything in VR, although with the recent announcement that the Valve Index will be supporting Linux as well, I imagine this may be most relevant to those who plan on snagging an Index once it’s gone on sale.
I launched Steam and checked out the Linux VR section aaaaaaand…. well, out of my 70 game VR library, none of them natively have a Linux version. So game over, right?
WRONG!
To be continued in Part 2: Proton, where we look at the technology that may just be able to turn our Linux machine into a full VR rig, and talk about which of those 70 apps can benefit from it! Thank you for tuning in so far, and feel free to comment or respond in tweets with any questions.
This is a bit of an experiment to me, but I decided I’d try to make a blog dedicated to talking about VR- especially from the perspective of someone who is very into the social aspect of the technology.
Lately, I’ve been working to try to see what can be done to improve Linux and MacOS support for VR applications as I think enabling VR users to choose their OS is awesome and super beneficial. I may also post some experiences I’ve had in social VR on here with the permission of those I’ve experienced them with.
I hope to use this blog as a way to not only post things I’ve learned and guides I’ve made, but to share thoughts I have going forward about the state of Virtual Reality technology. Thank you for reading this, I invite you to join me should you find my thoughts interesting!
Cas’s VR Rants 