2018-10-09 at 15:50 #5514
I would like clarification as to whether your intention is to support PsMoveService Controller positional tracking via PS3 Eye Cameras without the PsMoveSteamVRBridge installed within your application once fully implemented?
Currently driver4vr fixes the issue most of us are plagued with – where button mapping is not functioning at SteamVR Home, and where the wand pointer is not visible within menus; due to the newly implemented input system.
Most mention opting in to ‘openvr- inputemulator-temporary’ branch in steam as a working solution. Just atleast for me, it does not work. Whether HMD not found or some IPC error alongside steamvr component not running or compositor crashed – prevents functional operation.
Now I understand PS Move Service as a Hand Controller is not finished and completely implemented within your application. Just I want to know how you intend on tracking them. Will you be relying on Kinect tracking your skeleton or Kinect tracking the psmove coloured orb, or – is your idea to interface with PsMoveService to obtain controller positional coordinates/data provided by PS3 Eye cameras how it was traditionally but without the SteamVRBridge? I’m just concerned your phasing out the PS3 Eye Cameras.
As, at the moment, without SteamVrBridge installed and whilst PsMove is selected and assigned as a Hand Controller; the controllers are stuck to the floor in the center of the Steam chaperone, not obtaining positional tracking but only responding to orientation tracking but with good and working button support. It made me think, and then worry, that you might be intending on fixing the controller’s to your Kinect tracked Skeleton, and ridding support for the
PS3 Eye Camerass altogether.
Driver4Vr currently is our best chance at keeping good support for button mapping and retaining wand pointer in a single app, at the moment. It would be a shame to have to find another alternate if Kinect Tracking is the focus now.
Stickman892018-11-14 at 00:05 #5611
I’m also really interested in the answer to this question.
In general, it would be helpful to understand the ‘relationship’ between PSMS and Driver4VR. I had thought that Driver4VR took positional/rotation data from PSMS (as PSMoveFreePieBridge does, for example) and, combining it with other input data if necessary, sends it to SteamVR. But the above post suggests that it takes position/rotation data from SteamVR (supplied by SteamVRBridge) before then feeding it back.
Which is correct?
PSMoveService is great but it no longer works with recent versions of SteamVR. I appreciate this is nothing to do with you but if it were possible to take position/rotation data straight from PSMoveService it would solve this problem for a lot of people.
What do you think?
Jim.2019-10-24 at 22:41 #12031
PSMoveFreepieBridge translates and serves positional data captured by PSMoveService into FreePie. Driver4VR relays that information into SteamVR. Extending the bridge if you will – which is weird, now that I think about it.
Sorry, I’ve only just got around to re-reading my post, and I do come across confusing. (Whoops, sorry!)
I think I actually meant PSMoveFreepieBridge, yet I wrote SteamVrBridge.
…At this rate we’ll need a bridge intercepting and translating every mention of ‘SteamVrBridge’ in my calls, so I can get my message across.
When I wrote the above, Driver4VR was in the midst of a code rewrite, and as a result; previously working features, like FreePieBridge positional tracking – were not fully implemented/functional. Since all the talk shifted to Kinect tracking at the time; I was concerned that FreePieBridge and PSMoveService support was slowly being phased out as interest peaked in other means of input/tracking.
* Sorry I unearthed an old thread. I wanted to be a bit more clear. In reality, this thread now no longer serves any purpose. Everything is working rather well now as it stands *
You must be logged in to reply to this topic.