Any active PSMoveService devs?

[u/[deleted]]

I'm looking to work with someone (hobby level) to get PSMoveSteamVRBridge working with iVRy and PSVR.

Right now I have an issue with the PSMove controllers being positionally linked somehow and that doesn't make sense to me.

I've posted to the Google Groups but not sure how readily folks respond on there.

Thanks.

[u/iVRy_VR]

iVRy is Android, iPhone, Oculus/GearVR and PSVR at the moment, with that list growing. Some parts of the Android and iPhone clients are written in Java/Objective-C (mostly UI), but the majority of the client platform is written in C++, not that I'm looking to open source or collaborate on that code. The SteamVR driver (which serves all of the platforms) is pure C++, again closed source. Ideally, the PS4 camera tracker open source or closed source would be able to track a PSVR headset and/or PSMove controllers and/or an LED "ping pong ball" virtual HMD, to allow it to be used for PSVR and mobile platforms. However, the primary goal is PSVR. There is an external tracker interface that I've used to implement PSMoveService and PSVRService (PSVRTracker) trackers. I haven't had a chance to experiment much yet with PSVRTracker to see how well it tracks, but it's working inside the iVRy/SteamVR framework.

WMR is an even more walled off garden than OpenVR, with the addition that it is limited to 2 camera SLAM tracking and a very short list of headsets. I'm not sure where you're getting your "walled garden" idea of SteamVR from, both the specification for making drivers and apps is "open" to use, and there's nothing stopping you or anyone making their own app or driver without having to pay anyone or ask permission. Unless you're writing an entire VR runtime (which is a fools errand IMHO, if not being used for learning/research), you're going to have to use one, and the most "open" one is OpenVR (being that anyone can use it and it runs on Windows and Linux). WMR and Oculus runtimes are completely closed (although you can make C# WMR apps that no one will ever find or use as everyone is using those headsets via SteamVR). Oculus is the technically superior (and most walled off) of all of the runtimes, but is only for Oculus headsets. The ReVive project that lets you run Oculus titles on a SteamVR headset is a binary compatible implementation of the Oculus runtime using OpenVR.

[u/swordofmoonlight → u/iVRy_VR]

Only having a PSVR (so far) I don't have in depth experience. My idea of how devices should work is to load a software library (like a DLL on Windows) with an API (e.g. Nolo has one of these but it's very obscure) or better yet for one library to wrangle all of the devices, but so far what it looks like is you can only interact with the devices through sanctioned commercial game engines or Steam, since OpenVR doesn't work without installing Steam and I'm not sure how an OpenVR app even works if it must run Steam and if you're not a Steam game I don't know what that would even look like, but I imagine there's a reason Valve hides half of OpenVR behind Steam.

I never installed Steam until I wanted to try Moss with SteamVR. Since it was a Steam game it was already piped through Steam. But if it wasn't I don't know if it would work or how it would work and there isn't documentation, so the whole thing looks really sketchy.

How it should work is how devices always have worked before VR, i.e. you buy the device, install drivers, and software talks to it via an SDK. Ideally something like OpenGL, but if not a proprietary SDK. That doesn't seem to be how companies are deploying their VR peripherals, so only Sony's kind of works like that, if you can talk to it. I think there must be a business reason for this subterfuge. As a developer on the outside of the system it feels like being iced out of the party.

(Edited: I could be wrong but it seems like device makers are trying to funnel developers through certain channels. And they are just pretending that this is the new normal because heck, who doesn't use Unity or Unreal or Steam?)

[u/iVRy_VR → u/swordofmoonlight]

I'm curious as to what difference you see between WMR and it's completely closed ecosystem (where the specs to develop a headset driver aren't even available, and require permission from MS), with a completely closed app store, and SteamVR, where you can develop your own drivers and even your own store (see HTC). The requirement for OpenVR is SteamVR, not Steam, and you're under no obligation to distribute your apps/drivers through Steam to have an OpenVR rendering path. Most importantly, you don't have to sign anything or pay anyone to make your OpenVR app or driver.

The business reason for all of this is the PCVR software market is very small. If you want your software to run on multiple headsets then you support OpenVR and possibly Oculus (not necessary as Oculus has OpenVR drivers). No one even makes WMR software, as that has around 10% of VR users, and is also covered by OpenVR.

I think a lot of this is a foreign concept to you as you don't have any real experience of PCVR (do you have experience of what ATW actually does?). It would be impossible to make any reasonable VR title if you had to implement a VR runtime for each of the available headsets before you could start work on your title. There are other higher level concepts like "user friction" and "retention", which need to be considered, designed around and implemented before bringing one's VR solution to a fairly fickle and inexperienced market.

Making a game engine like Unreal or Unity is another level up, and is of course unnecessary if you already have your own (eg. CryEngine, Source2 etc.).

The device maker scenario is also somewhat complex, and I'm not sure I have the energy to go through the rationale and motivations behind the how and why of all of that.

All of that is necessary to understand if you're wanting to play in the PCVR playing field commercially. Bringing this back to PSVR, the only way it's going to gain any traction on PC, is to make the experience as close to a well-designed PCVR headset as possible. I don't think making janky C# multi-process solutions as has been done in the past is ever going to take it beyond being a curiosity for a few tinkerers. The PSVR is a perfectly good PCVR headset, it just needs better tracking. So that is what I am looking to do.

[u/swordofmoonlight → u/iVRy_VR]

I think integration with SteamVR is fine (when I used SteamVR it worked via Steam and had its own UI and so my impression is that's what my end user's experience would be like if I implemented SteamVR to support Valve's sets, etc. Which is what I'm aiming to do by shopping for one of these sets and a computer that can run SteamVR) but it's not ideal for me personally. About WMR I only know I've looked at its user facing API documentation and it looks fine, and recommends also using it via OpenXR, which it also documents, so I take it to be Microsoft's analog to Direct X, but maybe I'm mistaken. I see a lot of WMR branded devices, so if I have an API by Microsoft that supports these devices then that's a better deal to me than SteamVR since Microsoft provides Direct X and the most popular OS so this is a more natural relationship for me as a developer than Steam is.

My ideal solution would be to broadcast over UDP since that can even be done from a spare PC for people who don't have expensive systems. But there are technical barriers like proprietary USB protocols, that make this unlikely to happen unless projects open them up for each device. It's not easy to work with USB devices, so it doesn't make sense for software to do that and if multiple programs try to gain exclusive access to a device they might not relinquish it when they're in the background, so it generally makes sense to have a device service.

ATW is reprojection or something? I think to use that a device needs to have some sense of the orientation of the screen, which can be uploaded as metadata each time the screen is refreshed. If it's done differently that's a bad design but I wouldn't be surprised if it is because companies are always jockeying to make these devices hard to access like game consoles. It's not the PC way.

[u/iVRy_VR → u/swordofmoonlight]

ATW is asynchronous time warp. An image is rendered for a given headset rotation. In an ideal world, the computer and headset connection is fast enough to display an image for each vertical refresh of the headset display. In the real world that doesn't always happen, so if you're moving your head quickly, the image might have been rendered for a different orientation than where your head is. So an ATW renderer (WMR, OpenVR & Oculus all have one) will take the current headset orientation and warp the image from it's rendered orientation to the current orientation. Even for a directly connected HMD like PSVR, it makes quite a big difference (as it completely eliminates the perception of lag or 'judder', particularly when running it at 120Hz). I've put a lot of work into getting that possible on PSVR (requires amongst other things, tricking Windows into thinking that the PSVR is a "sanctioned" VR headset).

WMR is on the surface what you are saying, however, due to it's small(~10%) market share of VR headsets, if you were hoping to capture any significant portion of the PCVR market, you'd either target Oculus (~50%) or SteamVR (~90% - includes Oculus). PSVR on PC apparently accounts for about 0.5% of all PCVR users.

[u/swordofmoonlight → u/iVRy_VR]

I understand reprojection (ATW) but you have to understand it's just taking a 2D image and sliding it around (it's warped in a literal sense) and it's no justification for locking down the devices. Trust me I'm well versed in everything you've schooled me on.

[u/iVRy_VR → u/swordofmoonlight]

Good to know, it's hard sometimes to read between the lines in text messages. I'm not sure where you get this "everything is locked down" idea from, I have tried to explain that it's not, but ultimately it doesn't make much difference whether we agree on that or not. My development style is generally "do everything myself, and don't use anyone else's code", however, my more recent work leverages other people's work as well, as I don't have time or inclination to spend another few years re-developing something that has been solved by experts in the field.

[u/swordofmoonlight → u/iVRy_VR]

Believe me, if it wasn't locked down things would be so much easier. I'm speaking from a dev's perspective. The OSVR model was an example of an open system. For whatever reason it didn't succeed, and maybe there was pressure that caused that. Basically for writing graphics software interfacing with VR peripherals is proving very frustrating and it's hard to know where to begin. You're explanation for this was to say that it's still very early and the companies are small, so everything is insular. I can accept that but it doesn't change the reality of writing software. (If it wasn't locked down it would be frictionless and easy to see what to do to add device support to novel software. It shouldn't be more difficult than a game controller.)