First up, if you're looking for my upcoming Vive unboxing video, this isn't it!
When my Vive arrived earlier this month, I'd decided to let it sit in its box for a while. The most recent communication regarding official support was "We are working on it but it's not ready yet," and I had a lot of other work to focus on.
About a month ago, an OSVR contributor had mentioned in the OpenHMD IRC channel that OSVR had a driver that interfaced with Valve's Vive driver and allowed OSVR to support the Vive under Linux. I didn't have time to look into it, but was glad to know that even if Linux support wasn't being advertised as ready by Valve, that there was something tangible to work with.
The Vive's official launch came and went without advertised Linux support and it seemed that those users who did have Vives hadn't managed to jump through the correct hoops to get it functioning on Linux until last night when Linux user and developer SketchStick nudged me to take a look at some successes he'd had.
TMA (Too Many Acronyms)
Before going any further, we're going to need to work through some terms. Here's a rough glossary!
I'd also like to pop a disclaimer here. The stuff contained within this article will not magically give Vive support to Linux apps that weren't compiled with OpenVR support, and it doesn't make doing that any more accessible to developers. The value here is primarily for Linux based developers who are looking for examples to work with, and for F/OSS driver developers who are looking for working examples to observe and learn from.
Getting Things Working
The OpenVR SDK ships with an application called HelloVR. It renders a matrix of cubes around the HMD's camera and demonstrates how to interact with the OpenVR API. This example program has some Linux specific code in it, but needs additional tweaking before it will compile and behave happily on Linux (looking at the issue list in the OpenVR SDK's GitHub repo, it seems that there may be hurdles for other platforms as well).
Last year, in an effort to simplify maintenance of his OpenVR AUR package, Christoph Haag forked the Valve OpenVR repo and attempted to keep Linux support for the example applications behaving by testing with the Oculus Rift DK2 he had at the time. After selling his DK2 (more on that a bit later), Christoph continued to keep his fork in sync with Valve's repo, but didn't have any real opportunity to continue testing it to ensure functionality.
These steps have been adapted from instructions originally written by SketchStick as we were working through this stuff last night. Nice work!
To download Christoph's OpenVR SDK fork and build the HelloVR application, run the following commands (note, that you'll need CMake 3.1.0 or greater, as well as SDL2 and GLEW development packages):
Next, you'll want to plug in all those lovely Vive cables and make sure that the device has appropriate permissions. You can either run chmod like so:
Or set up udev rules for usb devices using the vendor codes 0bb4 and 28de as suggested in the OpenHMD readme (this is persistent and probably not a good idea given how early things are right now):
The next step is to make sure that the hellovr app and OpenVR commands have access to the environment and libraries they expect. If you don't already have it installed, you'll need to install SteamVR. This is done by either installing SteamVR from the VR or Tools category in your Steam library, or by using this URL steam://install/250820. Note that at the time of writing, the SteamVR beta branch does not work.
SketchStick has put together the following shell script which assumes that Christoph's OpenVR fork has been cloned into ~/openvr, that Steam has been installed to ~/.local/share/Steam and that the SteamVR depots have installed to ~/.local/share/Steam/steam/SteamApps/common/OpenVR (this stuff varies! Right click on SteamVR in your Steam library, select Properties, switch to the Local Files tab and click on the Browse Local Files button to see where SteamVR/OpenVR has installed to):
To use this script to set up the environment, run the following command in a terminal (it will allow $steam, $openvr and $steamvr to be used as variables in that terminal until it is closed):
It's not essential to use this script, but for the rest of the document, I will assume that you are (expand out the paths as necessary).
From here, we'll need to verify that the Vive is correctly detected by OpenVR.
This will output information on any detected OpenVR devices. You may see a large number of "ioctl (GFEATURE): Broken pipe" lines being output. For now, these are safe to ignore.
The output we care about should look something like this:
If you see a device and driver line that indicate that a Vive is present, we're ready to move forward with starting up the vrserver process and running the HelloVR app.
Start the vrserver process as a background task.
Open a new terminal and set up the SteamVR environment as we did before.
And finally, run the HelloVR app via a launch script that Christoph has provided.
At this point, we should have a working HelloVR app and be able should see something like this:
On the right is the vrcompositor window, which draws what you'll see through the Vive. The image is duplicated and offset for each eye. On the left is a normal monitor with a preview window that runs at a significantly lower frame rate and resolution that allows you to see what's going on without putting the device on.
Interestingly, the preview window shows significant lens compensation distortion while what's displayed through the device doesn't. This seems to indicate that the compositor isn't quite doing everything that it's meant to be doing.
HelloVR is also meant to use the OpenVR API to retrieve 3D models of the controllers and Lighthouse base stations, which are positioned in 3D space, although at the time of writing, I haven't been able to get this aspect to behave correctly.
Anybody who goes through this is likely to notice that there's a significant amount of latency (my gut says it's input latency, but it's difficult to discern the difference between that and render latency). At this point in time, I'm uncertain whether it's introduced by the HelloVR app, the OpenVR abstraction layer, the Vive driver, or even just launch options for vrserver, but it does suggest to me that there's still a little work left to do before the Vive can be considered "Linux ready".
A Little More Background
As soon as I had a stereoscopic image and headtracking working, I sent an email to Christoph to invite him to offer some comments on his work.
Without a device to test with himself and with the dominant understanding being that the Vive can't run on Linux, Christoph was surprised to learn that his efforts to get an OpenVR sample application allowed myself and SketchStick to demonstrate our Vives running on Linux with the existing OpenVR drivers. Equally surprised at his perseverance with maintaining his fork without a device, I asked Christoph about his interests and motivations with regard to VR.
Looking Forward
Christoph's History of Openness chronicles some details of Oculus' history that I wasn't previously aware of and reflects a level of disappointment that I think we all feel - not only over Oculus' apparent indefinite postponement of Linux support, but also for Valve and HTC's decision to launch the Vive without advertised Linux support.
Oculus dropped Linux support at the time that they shifted towards direct rendering mode. Assuming that there weren't any external factors involved in discouraging Linux support (something I'd rather not entertain in this article), it seems fair to assume that there were hurdles with regards to getting that performant and stable that were large enough to justify shelving Linux support in favour of focusing on a single platform.
The HelloVR app doesn't use direct rendering mode either, and it could be easy to assume that Vive's Linux support is a victim of the same prioritisation that lead to Oculus stepping back from Linux. In this case at least, we can see evidence of continued Linux related updates to OpenVR listed on SteamDB, with the most recent changes to OpenVR and Vive/Lighthouse related drivers happening within the past three weeks (change #1920962).
Looking even farther back, we can see that the Linux OpenVR libaries and binaries have continued to be updated alongside other platforms for the past two years (all the way back to change #395316 when vrserver_linux as added).
I want to sorely and strongly stress again that even though this article is about how to get the Vive to run, and that it highlights continued work on Linux support for the Vive, that now is not the time to run out and order a device or to hassle developers who aren't already shipping OpenVR support in their Linux builds. Both of those are important steps, but can't happen until either official vendor support for the Vive on Linux is announced and promoted as ready and stable, or until there is a feature-complete F/OSS driver available.
In the coming weeks, I'm sure that we'll dig around and discover Linux/Vive compatible apps, better identify the cause of (and possibly resolutions for) the latency issue I mentioned previously, and of course, we'll see progress on OpenHMD's Vive branch as well. Hopefully the proper release of Vive's Linux support is also on the near horizon.
Exciting times are ahead! Article taken from GamingOnLinux.com.
When my Vive arrived earlier this month, I'd decided to let it sit in its box for a while. The most recent communication regarding official support was "We are working on it but it's not ready yet," and I had a lot of other work to focus on.
About a month ago, an OSVR contributor had mentioned in the OpenHMD IRC channel that OSVR had a driver that interfaced with Valve's Vive driver and allowed OSVR to support the Vive under Linux. I didn't have time to look into it, but was glad to know that even if Linux support wasn't being advertised as ready by Valve, that there was something tangible to work with.
The Vive's official launch came and went without advertised Linux support and it seemed that those users who did have Vives hadn't managed to jump through the correct hoops to get it functioning on Linux until last night when Linux user and developer SketchStick nudged me to take a look at some successes he'd had.
TMA (Too Many Acronyms)
Before going any further, we're going to need to work through some terms. Here's a rough glossary!
- API: Application programming interface, a documented way of interacting with a program or library (to allow interaction without necessarily having access to the library or program's source code)
- SDK: Software development kit, a set of tools for creating applications (typically containing a set of libraries, API headers and examples)
- VR: Virtual reality \o/
- HMD: Head mounted display (typically with positional and/or rotational tracking)
- Positional tracking: The detection and capture of real world movement for use in software
- Rotational tracking: The detection and capture of real world rotation for use in software
- Vive: The HTC Vive, a HTC manufactured VR system created in collaboration with Valve
- Lighthouse: The infrared base station system used by the Vive to provide positional tracking, has also been used as a name for the entire Vive system
- Extended mode: Mapping a HMD display as a traditional monitor (derived from "extended desktop")
- Direct mode: A method for drawing graphics directly to a HMD rather than via the window manager
- SteamVR: Valve's collection of Steam and OpenVR libraries, drivers and demos
- Steam VR mode: A VR friendly version of Steam's "Big Picture Mode"
- OpenVR: A proprietary VR driver abstraction layer which supports the HTC Vive, the Oculus Rift, Razr Hydra, typically by interfacing with vendor provided drivers
- OSVR: An open source VR driver abstraction layer by Razer, Sensics and other partners, which supports the HTC Vive, Oculus Rift, Leap Motion and other devices, typically by interfacing with vendor provided drivers
- OpenHMD: A Free/Open Source Software VR input driver which supports the Oculus Rift DK1 and 2 and other devices
- vrcmd: An OpenVR binary providing command line access to information on OpenVR devices (and maybe other things)
- vrserver: An OpenVR binary that can be run as a service to provide access to OpenVR devices
- vrcompositor: An OpenVR binary that is used to render to OpenVR devices and take care of a bunch of VR specific concerns (distortion, etc.)
I'd also like to pop a disclaimer here. The stuff contained within this article will not magically give Vive support to Linux apps that weren't compiled with OpenVR support, and it doesn't make doing that any more accessible to developers. The value here is primarily for Linux based developers who are looking for examples to work with, and for F/OSS driver developers who are looking for working examples to observe and learn from.
Getting Things Working
The OpenVR SDK ships with an application called HelloVR. It renders a matrix of cubes around the HMD's camera and demonstrates how to interact with the OpenVR API. This example program has some Linux specific code in it, but needs additional tweaking before it will compile and behave happily on Linux (looking at the issue list in the OpenVR SDK's GitHub repo, it seems that there may be hurdles for other platforms as well).
Last year, in an effort to simplify maintenance of his OpenVR AUR package, Christoph Haag forked the Valve OpenVR repo and attempted to keep Linux support for the example applications behaving by testing with the Oculus Rift DK2 he had at the time. After selling his DK2 (more on that a bit later), Christoph continued to keep his fork in sync with Valve's repo, but didn't have any real opportunity to continue testing it to ensure functionality.
These steps have been adapted from instructions originally written by SketchStick as we were working through this stuff last night. Nice work!
To download Christoph's OpenVR SDK fork and build the HelloVR application, run the following commands (note, that you'll need CMake 3.1.0 or greater, as well as SDL2 and GLEW development packages):
git clone https://github.com/ChristophHaag/openvr.git
cd openvr
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ../
makeNext, you'll want to plug in all those lovely Vive cables and make sure that the device has appropriate permissions. You can either run chmod like so:
sudo chmod a+rw /dev/hidraw*Or set up udev rules for usb devices using the vendor codes 0bb4 and 28de as suggested in the OpenHMD readme (this is persistent and probably not a good idea given how early things are right now):
echo KERNEL=="hidraw*", ATTRS{idVendor}=="0bb4", MODE="0666"
echo KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"
udevadm control --reload-rulesThe next step is to make sure that the hellovr app and OpenVR commands have access to the environment and libraries they expect. If you don't already have it installed, you'll need to install SteamVR. This is done by either installing SteamVR from the VR or Tools category in your Steam library, or by using this URL steam://install/250820. Note that at the time of writing, the SteamVR beta branch does not work.
SketchStick has put together the following shell script which assumes that Christoph's OpenVR fork has been cloned into ~/openvr, that Steam has been installed to ~/.local/share/Steam and that the SteamVR depots have installed to ~/.local/share/Steam/steam/SteamApps/common/OpenVR (this stuff varies! Right click on SteamVR in your Steam library, select Properties, switch to the Local Files tab and click on the Browse Local Files button to see where SteamVR/OpenVR has installed to):
#!/bin/bash
export openvr=~/openvr
export steam=~/.local/share/Steam
export steamvr=$steam/SteamApps/common/OpenVR
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:\
/usr/lib/:\
/usr/lib32/:\
$openvr/lib/linux32/:\
$openvr/lib/linux64/:\
$steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/:\
$steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/:\
$steamvr/bin/linux32/:\
$steamvr/bin/linux64/:\
$steamvr/drivers/lighthouse/bin/linux32/:\
$steamvr/drivers/lighthouse/bin/linux64/To use this script to set up the environment, run the following command in a terminal (it will allow $steam, $openvr and $steamvr to be used as variables in that terminal until it is closed):
source ./steamvr.shIt's not essential to use this script, but for the rest of the document, I will assume that you are (expand out the paths as necessary).
From here, we'll need to verify that the Vive is correctly detected by OpenVR.
$steamvr/bin/linux64/vrcmdThis will output information on any detected OpenVR devices. You may see a large number of "ioctl (GFEATURE): Broken pipe" lines being output. For now, these are safe to ignore.
The output we care about should look something like this:
QuoteDevice 0 - lighthouse.LHR-1F0D0FBC - Vive MV by HTC - HMD - generic_hmd
Left Projection: left=-1.396245, right=1.242144, top=-1.467562, bottom=1.464816
Right Projection: left=-1.251338, right=1.392499, top=-1.474031, bottom=1.464144
Lens Center: (0.546726, 0.499251), (0.457286, 0.497308)
Driver lighthouse : 1 displays
Vive MV (Serial number LHR-1F0D0FBC)
Driver oculus : 0 displays
Driver oculus_legacy : 0 displays
Driver null : 0 displays
If you see a device and driver line that indicate that a Vive is present, we're ready to move forward with starting up the vrserver process and running the HelloVR app.
Start the vrserver process as a background task.
$steamvr/bin/linux64/vrserver --keepaliveOpen a new terminal and set up the SteamVR environment as we did before.
source ./steamvr.shAnd finally, run the HelloVR app via a launch script that Christoph has provided.
$openvr/build/samples/hellovr_opengl/run_hellovr.shAt this point, we should have a working HelloVR app and be able should see something like this:
On the right is the vrcompositor window, which draws what you'll see through the Vive. The image is duplicated and offset for each eye. On the left is a normal monitor with a preview window that runs at a significantly lower frame rate and resolution that allows you to see what's going on without putting the device on.
Interestingly, the preview window shows significant lens compensation distortion while what's displayed through the device doesn't. This seems to indicate that the compositor isn't quite doing everything that it's meant to be doing.
HelloVR is also meant to use the OpenVR API to retrieve 3D models of the controllers and Lighthouse base stations, which are positioned in 3D space, although at the time of writing, I haven't been able to get this aspect to behave correctly.
Anybody who goes through this is likely to notice that there's a significant amount of latency (my gut says it's input latency, but it's difficult to discern the difference between that and render latency). At this point in time, I'm uncertain whether it's introduced by the HelloVR app, the OpenVR abstraction layer, the Vive driver, or even just launch options for vrserver, but it does suggest to me that there's still a little work left to do before the Vive can be considered "Linux ready".
A Little More Background
As soon as I had a stereoscopic image and headtracking working, I sent an email to Christoph to invite him to offer some comments on his work.
Quote"My changes are actually quite small. Valve definitely started porting the sample to linux (some #ifdef __linux__ etc.) but it seems halfway through apparently they stopped. It's weird because this is basically what makes it build and run.
Well, and they have no build system for linux so I threw some cmake stuff together."
Without a device to test with himself and with the dominant understanding being that the Vive can't run on Linux, Christoph was surprised to learn that his efforts to get an OpenVR sample application allowed myself and SketchStick to demonstrate our Vives running on Linux with the existing OpenVR drivers. Equally surprised at his perseverance with maintaining his fork without a device, I asked Christoph about his interests and motivations with regard to VR.
Quote"I personally had preordered an Oculus Rift DK2 because they sorta had linux support and were bought by Facebook so I thought they'd surely deliver and I could play with unity or unreal. Well, they didn't deliver and I sold my DK2 and wrote History of Openness to express my disappointment with oculus. The SteamVR oculus plugin worked more or less, but all of SteamVR's engine integration is only for windows too, so there is that.
As long as all of the interesting stuff is confined to proprietary platforms that are tied to windows I don't really care that much about VR right now.
I am hoping for the next OSVR HDK to have a display that is on par with Vive and Rift though, then I would likely buy one.
Still the trouble remains that while Oculus and Valve only support VR on windows, almost all VR applications will be windows-only too, so stuff like LibreVR/Revive and a cross platform SteamVR would remain pretty useless, at least until wine can really support low latency translation.
My experience with oculus-wine-wrapper was that it works for some unity applications, but not all and that the latency is a bit off...
Well, back when I bought the DK2 I made this subreddit, but there is not a lot of content.
Since I don't like oculus anymore I thought I'd rather have a subreddit name like this, but.. yea, I need to look for some content."
Looking Forward
Christoph's History of Openness chronicles some details of Oculus' history that I wasn't previously aware of and reflects a level of disappointment that I think we all feel - not only over Oculus' apparent indefinite postponement of Linux support, but also for Valve and HTC's decision to launch the Vive without advertised Linux support.
Oculus dropped Linux support at the time that they shifted towards direct rendering mode. Assuming that there weren't any external factors involved in discouraging Linux support (something I'd rather not entertain in this article), it seems fair to assume that there were hurdles with regards to getting that performant and stable that were large enough to justify shelving Linux support in favour of focusing on a single platform.
The HelloVR app doesn't use direct rendering mode either, and it could be easy to assume that Vive's Linux support is a victim of the same prioritisation that lead to Oculus stepping back from Linux. In this case at least, we can see evidence of continued Linux related updates to OpenVR listed on SteamDB, with the most recent changes to OpenVR and Vive/Lighthouse related drivers happening within the past three weeks (change #1920962).
Looking even farther back, we can see that the Linux OpenVR libaries and binaries have continued to be updated alongside other platforms for the past two years (all the way back to change #395316 when vrserver_linux as added).
I want to sorely and strongly stress again that even though this article is about how to get the Vive to run, and that it highlights continued work on Linux support for the Vive, that now is not the time to run out and order a device or to hassle developers who aren't already shipping OpenVR support in their Linux builds. Both of those are important steps, but can't happen until either official vendor support for the Vive on Linux is announced and promoted as ready and stable, or until there is a feature-complete F/OSS driver available.
In the coming weeks, I'm sure that we'll dig around and discover Linux/Vive compatible apps, better identify the cause of (and possibly resolutions for) the latency issue I mentioned previously, and of course, we'll see progress on OpenHMD's Vive branch as well. Hopefully the proper release of Vive's Linux support is also on the near horizon.
Exciting times are ahead! Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: sarmadQuoting: Mountain ManI'm still of the opinion that this whole VR craze is going to be another short-lived novelty like 3D televisions and motion controls (other than the Nintendo Wii) once people realize that it doesn't meaningfully enhance their gaming experience. Professional applications, yes, but entertainment? I don't see it.
I agree. VR will boom once headsets become as small and light as sunglasses, not with this bulky headsets.
That would defeat the entire purpose.
This comes down to a factor mentioned by ObsidianBlk earlier: "VR most definitely DOES add a "meaningful enhancement" to the gaming experience. With the environment all around you, and (visually) nothing to distract you, you most definitely feel like part of the world in which you play."
VR headsets need to completely block out the outside world, therefore they can't be as small as sunglasses. Something as small as sunglasses wouldn't be a VR headset.
1 Likes, Who?
Quoting: WorMzyQuoting: EikeQuoting: Mountain ManI'm still of the opinion that this whole VR craze is going to be another short-lived novelty like 3D televisions and motion controls (other than the Nintendo Wii) once people realize that it doesn't meaningfully enhance their gaming experience. Professional applications, yes, but entertainment? I don't see it.
I'm still to hear this opinion by someone who tried a real VR device. Did you?
For the record, I have tried a couple of VR demos (not including "cardboard" ), and I share the same opinion as Mountain Man. It's an interesting experience, and very immersive, but it isn't something I would pay X hundred pounds for, and I can't see that many games a) supporting it, or b) being particularly enjoyable while using it for more than say 20 minutes.
Sorry to burst your imaginary bubble, but try tell this to people who have been using VR to play Elite: Dangerous for more than 2 years for hundreds of hours.
Already many games and engines do support it or plan to support it. And it is enjoyable. So you are wrong. It is ok to admit that it sucks that there's no official support for Linux yet, but let's no go full sour grapes here.
0 Likes
Quoting: KristianQuoting: sarmadQuoting: Mountain ManI'm still of the opinion that this whole VR craze is going to be another short-lived novelty like 3D televisions and motion controls (other than the Nintendo Wii) once people realize that it doesn't meaningfully enhance their gaming experience. Professional applications, yes, but entertainment? I don't see it.
I agree. VR will boom once headsets become as small and light as sunglasses, not with this bulky headsets.
That would defeat the entire purpose.
This comes down to a factor mentioned by ObsidianBlk earlier: "VR most definitely DOES add a "meaningful enhancement" to the gaming experience. With the environment all around you, and (visually) nothing to distract you, you most definitely feel like part of the world in which you play."
VR headsets need to completely block out the outside world, therefore they can't be as small as sunglasses. Something as small as sunglasses wouldn't be a VR headset.
Swimming goggles are as small as sunglasses, yet they block your eyes completely from the outside world. So, yes, VR headsets can be as small as sunglasses and still block out the outside world.
0 Likes
I have HTC vive, and right now i will try run it on my fedora box.
Btw, in just 30 seconds using it you know its the future. I was waiting it for almost all my life, i preordered it and i had to wait few months to arrive to my home. My hype was really high. I was really scared it was going to dissapoint me. It will be immersive? i will see the distance between me and objects... and all that stuff. When i put that on my head i saw my expectations were ridicolous, it's just much more than what you can expect. All who tested my HMD said the same, it's the future. We had 2D and 3D atm, now we have 2D, 3D and VR.
Btw, in just 30 seconds using it you know its the future. I was waiting it for almost all my life, i preordered it and i had to wait few months to arrive to my home. My hype was really high. I was really scared it was going to dissapoint me. It will be immersive? i will see the distance between me and objects... and all that stuff. When i put that on my head i saw my expectations were ridicolous, it's just much more than what you can expect. All who tested my HMD said the same, it's the future. We had 2D and 3D atm, now we have 2D, 3D and VR.
1 Likes, Who?
Quoting: bubexelI have HTC vive, and right now i will try run it on my fedora box.
Btw, in just 30 seconds using it you know its the future. I was waiting it for almost all my life, i preordered it and i had to wait few months to arrive to my home. My hype was really high. I was really scared it was going to dissapoint me. It will be immersive? i will see the distance between me and objects... and all that stuff. When i put that on my head i saw my expectations were ridicolous, it's just much more than what you can expect. All who tested my HMD said the same, it's the future. We had 2D and 3D atm, now we have 2D, 3D and VR.
Everyone that I demo my Vive to says basically the same. I'm going to demo it at the office this Friday and I can't wait to see what the people will think about it!
Biggest problem right now are the games, but only a bigger market and time can fix that, hopefully we will see tons of great releases this year!
0 Likes
~/compilar/openvr/samples/hellovr_opengl/hellovr_opengl_main.cpp:459:47: error: invalid conversion from ‘void (*)(GLenum, GLenum, GLuint, GLenum, GLsizei, const char*, const void*) {aka void (*)(unsigned int, unsigned int, unsigned int, unsigned int, int, const char*, const void*)}’ to ‘GLDEBUGPROC {aka void (*)(unsigned int, unsigned int, unsigned int, unsigned int, int, const char*, void*)}’ [-fpermissive]
glDebugMessageCallback(DebugCallback, nullptr);
I can't compile it and i don't understand the error
glDebugMessageCallback(DebugCallback, nullptr);
I can't compile it and i don't understand the error
0 Likes
ElectricPrism May 17, 2016
Quoting: EikeQuoting: Mountain ManI'm still of the opinion that this whole VR craze is going to be another short-lived novelty like 3D televisions and motion controls (other than the Nintendo Wii) once people realize that it doesn't meaningfully enhance their gaming experience. Professional applications, yes, but entertainment? I don't see it.
I'm still to hear this opinion by someone who tried a real VR device. Did you?
I demoed a Samsung VR unit at Verizon and it was underwhelming. Now maybe the make makes a big difference? But I find the technology itself not that interesting and few use case scenarios in which I would prefer strapping blackout headgear to my head over playing on the big screen with the lights dimmed or off.
$600-$800 is a lot to buy into this niche for me.
Now I will wait for others to do the programming, and technological improvements that may at some future date change my mind, but right now my reaction to VR is simply:
Last edited by ElectricPrism on 17 May 2016 at 9:00 pm UTC
0 Likes
Cheeseness May 17, 2016
Quoting: bubexel~/compilar/openvr/samples/hellovr_opengl/hellovr_opengl_main.cpp:459:47: error: invalid conversion from ‘void (*)(GLenum, GLenum, GLuint, GLenum, GLsizei, const char*, const void*) {aka void (*)(unsigned int, unsigned int, unsigned int, unsigned int, int, const char*, const void*)}’ to ‘GLDEBUGPROC {aka void (*)(unsigned int, unsigned int, unsigned int, unsigned int, int, const char*, void*)}’ [-fpermissive]
glDebugMessageCallback(DebugCallback, nullptr);
I can't compile it and i don't understand the error
It's probably quickest to just comment out that line. Others have made tweaks to get it to compile, but I didn't bother spending any time on it - it's to do with changes in glxext.h from what I understand. There's a relevant GitHub issue here.
Quoting: Hyperdrive"but can't happen until either official vendor support for the Vive on Linux is announced" => There are severe disagreement on whether or not there were official vendor support.If the word from Valve is that it wasn't ready, then there's no disagreement about official support. The article demonstrates that there's a level of functionality exists (and has probably existed since day one), but without that support being advertised as stable and ready for use, it's not.
Last edited by Cheeseness on 17 May 2016 at 11:23 pm UTC
0 Likes
TheRiddick May 18, 2016
WarThunder supports VR, give that a go (only really viable in simulations mode, which is like 15 out of 10 on the hardometer)...
0 Likes
slaapliedje May 18, 2016
I have an HTC Vive and it's the reason I've actually spent time in Windows in the last 5 years for more than the weekend game. It's simply amazing, and anyone who says 'it's just a fad, it'll pass like 3D movies' hey, I like 3D movies, but what I want to see now is 360 degree movies!
While the GearVR is mostly a non-interactive experience, they do have a few games for it, but they're just no way as cool as being able to hook up your HOTAS and play Elite, or a steering wheel to play Project Cars. Even a game as simple as Crystal Rift has an extra amazing thing about being able to reach out to your right to hit a skeleton when normally you would have to completely turn to face it without VR.
Also, Vanishing Realms... having to dodge arrows and fireballs certainly works up a sweat.
These are all early games, mostly sort of demos of the tech though. Imagine if you will GTA 6 or Elder Scrolls 6. There are already some hacks to get it working with 5 of each game. Maybe SteamVR is waiting for some work to be done and for the 1070 GTX versions of Steam Machines to be released.
This kind of reminds me of when 3Dfx cards were first coming out. 3D acceleration used to be laughed off as a niche, and that no one would support it, and initially there were so many different APIs for it, and you only hoped that you had ended up with a card that most games would support.
I recall specifically that a friend of mine was all about graphics in games, and yet he HATED Unreal because it looked SO much better on my system with a 3Dfx card. He eventually got one himself of course. This is the exact same thing.
As I've told people, it is a completely different experience to seeing it in a video. Hell, I brought mine into work and people mostly just played Fantastic Contraptions for hours, and I don't even think that game is all that fun. On the other hand, playing Cloudlands Mini Golf with my family was a blast.
It's pretty inevitable that more games will have native VR support, and hopefully a lot of them end up being ones with more meat in them. As stated, if they can get the right mods and support to make Skyrim perfect, along with something like the Virtuix Omni, it could be a game you could see some people die in. Okay, maybe that's not a good thing, but it seems to happen to some with MMORPGs. speaking, there is seriously nothing more awesome than being immersed in a world with other individuals and roaming around and doing RPG things! I do need to spend more time in AltspaceVR...
While the GearVR is mostly a non-interactive experience, they do have a few games for it, but they're just no way as cool as being able to hook up your HOTAS and play Elite, or a steering wheel to play Project Cars. Even a game as simple as Crystal Rift has an extra amazing thing about being able to reach out to your right to hit a skeleton when normally you would have to completely turn to face it without VR.
Also, Vanishing Realms... having to dodge arrows and fireballs certainly works up a sweat.
These are all early games, mostly sort of demos of the tech though. Imagine if you will GTA 6 or Elder Scrolls 6. There are already some hacks to get it working with 5 of each game. Maybe SteamVR is waiting for some work to be done and for the 1070 GTX versions of Steam Machines to be released.
This kind of reminds me of when 3Dfx cards were first coming out. 3D acceleration used to be laughed off as a niche, and that no one would support it, and initially there were so many different APIs for it, and you only hoped that you had ended up with a card that most games would support.
I recall specifically that a friend of mine was all about graphics in games, and yet he HATED Unreal because it looked SO much better on my system with a 3Dfx card. He eventually got one himself of course. This is the exact same thing.
As I've told people, it is a completely different experience to seeing it in a video. Hell, I brought mine into work and people mostly just played Fantastic Contraptions for hours, and I don't even think that game is all that fun. On the other hand, playing Cloudlands Mini Golf with my family was a blast.
It's pretty inevitable that more games will have native VR support, and hopefully a lot of them end up being ones with more meat in them. As stated, if they can get the right mods and support to make Skyrim perfect, along with something like the Virtuix Omni, it could be a game you could see some people die in. Okay, maybe that's not a good thing, but it seems to happen to some with MMORPGs. speaking, there is seriously nothing more awesome than being immersed in a world with other individuals and roaming around and doing RPG things! I do need to spend more time in AltspaceVR...
0 Likes
Patreon
PayPal
Currently working on Winter's Wake, a first person text adventure thing and its engine Icicle. Also making a little bee themed base builder called Hive Time :)
I do more stuff than could ever fit into a bio.
See more from me