Are you developing on SteamVR? If yes, I would be interested to know which
Iâve rarely had any problems with SteamVR but then again I have an Index and SteamVR beta installed. Itâs probably different for Pimax headsets.
1 Like
I will probably never develop anything on SteamVR. If I do, it will only be temporary, until I can port a graphics engine or such to Pimax SDK.
However, I do talk to some of the overlay developers, I definitely experience issues caused by the architecture, and I have read through some of the SteamVR/OpenVR specifications (which seems ridiculously complicated). The overlay applications that now support curved displays do so by presenting a series of 2D vertical rectangular bar textures. Any reprojection causes overlays to double frame (which would not happen if they could send 2D images directly to the last step in the compositor pipeline). And those are just some of the most obvious problems.
2 Likes
This is not necessarily on SteamVR. As Vive Wands work and it is Index Controllers with issues on Pimax headsets and not on Vive/Index or even using with Dongles on Non SteamVR headsets. This suggests somerhing on Pimax End. As Pimax presumably doesnât update the watchman dongles in the headset is likely related.
As is the fact you canât update LH v2.0 with a pimax headset. This is largely on Valve by switching Lighthouse v2.0 only updatable through bluetooth.
This is truly laughable when one made the claim you donât need to update LH firmware after it was well documented that SteamVR needed to update them after discovering Beatsaber players could move faster than was thought. Firmware updates just donât get released for no reason. It is to fix and improve a device.
Yes it is not Oculus VR. Which while some have paranoid Facebook concerns it is more efficient. Though doesnât use overlays. Overlays which should be optimized to use Multi cores even if game aps donât.
This has to do with most closed code. Since your dependent on a closed code. There devs will code for their direction which may compromise others efforts whom used workarounds to make things work. Maybe OpenXR will help bring things to a more stable console style Dev path for games and such. Only time will tell.
3 Likes
I know for a fact it was on SteamVR. And by your own admission, Valve makes laughably bad decisions, particularly with regard to how their supposedly âOpenVRâ proprietary platform works with third party systems.
Early on, just having tracking work with a 5k+ and Vive wands could be a problemâŚ
Oculus VR does some things better, some things worse. Where are the overlay applications for Oculus? Though I did forget to mention, at least Oculus allows multitasking, which was handy with VirtualDesktop.
Closed code can be a problem because it requires trust of the provider. But forced updates mean that trust is on a continuing basis. SteamVR being one of the worst offenders in the software industry, absolutely has not earned that trust.
1 Like
An even better example is Multi core in gaming. If itâs not a console it has been painfully slow to get pc devs to properly utilize it.
2 Likes
A mentality which is even worse for the simulation oriented, like myself. The size of the traditional gaming industry is almost an incentive to foul things up for us. Weâre the ones with the possibility of developing more professional use cases for VR, and weâre just âalong for a wild rideââŚ
1 Like
MS is the biggest owner if Forced updates that often have broken a wide variety of thingsâŚ
Valve can also say as Microsoft does. You need to update your program to work with new changes in our platform. If you have used a workaround to achieve a desired result you may need to rework things to work later when things changed. Very common to happen outside of Consoles.
MS changed how their Display stack which has caused a wide variety of problems in older programs and even some modern ones. There are compatibility fixes in the OS that may or may not work and may need the Program Dev to revisit.
Not any different than folks expecting DeVs to fix their programs to remove PP needed with Pimax Headsets.
As for Valveâs naming their VR platform âOpenVRâ imho is a misnomer playing on the idea of actual Opensource which it is not.
Oculus and Overlays? Who says they need to adopt this idea? They might have good reasons in their Roadmap why not atm. Including some of your complaints with SteamVRâs handling them.
There are a ton of great things Linux has that Windows doesnât or that MS has been slow to implement.
Welcome to the age of Betas. Where Betas are the Alphas of 15 to 20 years ago.
1 Like
MS ⌠forced updates
Which is actually strange if you consider the sole reason for using the MSW platform at all is compatibility with legacy software. Every other major OS is based on UNIX, and even the worst of these (ie. Android) are much more stable.
Not any different than folks expecting DeVs to fix their programs to remove PP needed with Pimax Headsets.
Bogus. While both those situations are bad, updates are breaking things that used to work.
As for Valveâs naming their VR platform âOpenVRâ imho is a misnomer playing on the idea of actual Opensource which it is not.
Agreed. I see it as a cheap attempt to undermine the perceived value of an actual open source competitor.
Oculus and Overlays? Who says they need to adopt this idea?
The people who have a use case for them?
Including some of your complaints with SteamVRâs handling them.
Itâs not just that what SteamVR does is stupid, it is vastly more complicated than any natural solution. Performance issues that might have been solved in a few revisions very early on were preempted by imposing an extremely complicated codebase that must be difficult to maintain.
Linux
Yes. My sole use for MSW is to run VR interfaces and the occasional application which requires it. Much of the extendedInterface project exists to provide the infrastructure needed for even the most basic use cases built around a single application on the MSW platform.
And at the end of the day, to do anything remotely serious within a VR app, I support it with a Panel VM running Linux.
If these VR programs simply worked under Linux, with a comparably stable software stack, the extendedInterface project would be an order of magnitude less complicated.
Which coincidentally, would make it usable as is by other end users.
MS and Legacy donât work well at all. Otherwise W10 would have better compatibility.
Sure it can be said to be bogus. But it doesnât change reality.
For example had MS fixed the usb Audio broken since was it W7? Nope. You have to use work arounds or if your a hardware dev you either do what MS says or release a product with poor Audio if MS doesnât approve your choice to rely on their Usb audio driver.
You and I may have uses for it as others. Doesnât mean Oculus needs to satisfy this on our preferred schedule or at all. As said Oculus might not have implemented it yet due to some of the issues you mention about Steamâs implementation. Some games or a lot run better without the steam overlay. Due to the overlay maybe interfering with the program in some way.
No different than why hasnât pimax made a simple Pitool Overlay for functions that can be changed without a steamvr restart.
Itâs coming with things like Proton and such. Though with Valveâs whims it could experience setbacks as Valve has dropped Mac VR support.
Proton
I donât see why yet another headset would make a difference. Supposedly SteamVR supports Linux already. That doesnât address the issue of quality - I donât even feel like trying to make a second-tier SteamVR software stack work. Nor do I really want to run that on Linux.
If these VR programs simply worked under Linux, with a comparably stable software stack, the extendedInterface project would be an order of magnitude less complicated.
When I say âsimply worked under Linuxâ, that is at minimum something like VirtualDesktop or DCS World directly interfaced to something like PiTool, with Overlay support, and no need to install middleware like SteamVR.
Well then your looking for something that doesnât exist. It is doubtful that SteamVR stack or Oculus Stack will be scrapped and something new adopted.
Oculus Ditched linux sometime after FB aquisition. SteamVR is likely to be stabilized in Linux as there is more flexibility to do so vs Windows with hidden things in the OS.
Proton is likely one of Valveâs best sponsored projects. As for Pimax and Linux? Our best hope is if the Opensource comes through or the OpenHmd project gets our p2 headsets working like they have with the p4k.
Steamvr does Support Linux and some Devs have native support for their VR aps on linux. Reports show Proton has a variety of Windows VR aps working in linux as well. You can test this if you have a SteamVR headset like Vive and Index.
1 Like
In the same post you suggest thisâŚ
It is doubtful that SteamVR stack or Oculus Stack will be scrapped and something new adopted
⌠you mention thisâŚ
OpenHmd
Which is very easy for new application developers to support.
As for thisâŚ
SteamVR is likely to be stabilized in Linux as there is more flexibility to do so vs Windows with hidden things in the OS.
Not unless Valve themselves somehow acquire a much stronger commercial interest in Linux support than MSW. SteamVR itself breaks things far more often than even MSW, and this is usually through blatant neglect.
OpenHmd is not a new VR stack. It is more like a remix of OpenHmd driver to support use of a wide variety of headsets to work. In a way simlar to OSSVR you could add your headset to their Driver. It is not itâs own platform to run programs. It simply adds supports for headsets to be used in VR.
Correction it seems to be similar to OpenXR in scope. It does help Headsets to be also used in Steam and may if gets enough traction lead to a new stack of itâs own but iffy as was ossvr.
They already have decent support in Linux. With MS, Valve and MS can cladh more often. Where as you can play to have things work easier in a variety of cases.
Ie Legacy games that will not run on W10 will 9/10 run in Linux.
Proton has also added a lot of support to Linux and feeds Wine. With Valve ditching Mac it is likely more resources are being redirected to Linux.
OpenHmd is not a new VR stack.
As much as Oculus is, or PiTool is, it is. It can turn on the headset, manage motion tracking, display framebuffers, and there is already a Unity plugin.
EDIT: To be clear, I am NOT looking for any kind of âmarketplaceâ or âlibraryâ. For that, I have the Debian Package repository, ebuilds, my own Ubiquitous Bash infrastructure, and (seriously!) the filesystem itself.
Pitool more relies on other platforms to work vs trying to get folks to dive into a new platform. OpenHmd will need to have rooting in OpenXR.
Pimax has trouble keeping Oculus support up to date. Were fortunate Steam doesnât break things as often as Oculus updates do for pimax.
PiTool only ârelies on other platformsâ to the extent not many programs are using this.
That will likely change.
Working with OpenXR seems like a lot more trouble than just adding another plugin to a game engine to take motion data and send framebuffers elsewhere. Especially if that elsewhere already supports multiple vendorsâ headsets and operating systems. I am just not sure there is a need for OpenXR.
For that to change Pimax needs to update the SDks which are now at least 2 years since released. It has been discussed multiple times with DeVs requesting pimax support and not getting it.
Often told to just use the OpenVR SDK.
OpenXR removes the need to use Headset specific sdks or platform sdks for tracking.
The Pimax SDK was more for rendering like PP and the possibly unlikely Brainwarp(2.0) frame doubling which seems like it might be scrapped.
True. But my point was to refute this.
1 Like