While recording, somewhere along the way, the dimensions of the OBS SteamVR mirror capture stuff was broken, and the recorder was stopped. Results - bad footage, lost footage.
At least one person has ‘spent over 1K€ trying to get a good frame-rate’ … ‘you SteamVR’ …
WOW! SteamVR now ignores/mixes chaperone files. This has been thoroughly confirmed.
This means I cannot switch between room layouts (to use different rooms as my playspace), and all my OVRDrop overlay positions are messed up, probably permanently this time.
@PimaxUSA@SweViver
At this point, OpenHMD is now a necessity. There is no way SteamVR will ever be workable.
Maybe you don’t do any simulation stuff, where having rapidly set overlay positions actually matters. Maybe you don’t even actually use OVRDrop like I do. You keep touting stupid OpenXR like it is a magic solution. No. We need framebuffers and positions. Direct access to hardware. Not frameworks.
Having the rug pulled out from under us is the problem. We absolutely cannot have SteamVR or anything else like it, between us and the hardware.
This is a freaking nightmare people, and it is why VR is not taken seriously outside of gaming, where only a single, simple, application is to be run.
And you seem to keep ignoring the obvious. Steam has a mass advantage -> Adoption.
OSVR could do VR without steam or Oculus (dead)
AntVR had steam and it’s own platform (dead)
Now you have Windows Store platform for VR.
OpenHMD may one day have enough traction. I have only pointed out the obvious. Pimax Supporting OpenHmd is only going to help in a minor point.
Have you even looked into True OpenVR? Another vr project for Opensource hmd and controllers.
As pimax needs to implement there own chaperone overlay you might still get some benefit for your Room swap issues introduced into SteamVR update. However to truly get away from Steam likely going to need a custom tracking solution that does not rely on Valve tech that works really well.
Fact is VRgineers and StarVR conceded the need to support Steam ecosystem by adding SteamVR compatibility which in there former products had none. MS knew they needed to have a Steamvr driver to help push there headsets. Like it or not everyone is supporting Valve.
Standalone pc vr platforms have very limited support from DeVs.
OpenXR will help remove blocks that make it hard for crossplatform compatibility in VR platforms that is it’s purpose to help Developers.
What good is direct access to a niche products hardware in the bigger picture of things?
Nobody but a very select few will incorporate code specific to Pimax headsets as it’s just not worth it…
There’s a reason that lots of developers are not even supporting canted displays even though the fix, in most cases, seem fairly simple…
Frameworks are what enables Pimax, not what hinders them…
Get real man and stop saying such silly things because it fits into Your world…!
EDIT: If You’re saying You’d like direct access besides what’s already there I can follow You, but if not it’s not Helio who’s “touting stupid” things as it would be the final nail in the coffins for Pimax to drop support for what’s already established and widespread… Seriously, why would Pimax do that? XTAL or similar, maybe, but not Pimax…
Xtal already had that in there 2 previous headsets Hero and Hero2. What we have seen is Vrgineers had to submit and support Steam for greater adoption. There original headsets only supported there own platform like og StarVR.
I think this is just Mirage venting to blow off Steam(pun intended) with his frustrations. If he doesn’t need the new options in the update it is not very user friendly but one can roll back steamvr.
Yawn. I am just really tired of messing with SteamVR.
Realistically, we need OpenHMD to support all headsets, or at the very least to start treating SteamVR as just a display. No overlays, no controllers, no smart smoothing, no hand tracking, no eye tracking. All tracking and other VR peripherials need to be managed by an Interprocess Communication Bus that does NOT go through SteamVR.
Even if that means a VR app is sold with dedicated hardware controllers just to get away from SteamVR.
As long as it has taken Pimax to push out the sword controllers, that might seem a bit fantastic right now, but as more of the relevant components and designs become publicly available, the hassle of dealing with SteamVR is going to be much worse relatively.
I am actively working on these problems, but I though I would take a break to test hand tracking with DCS World. I thought my biggest problem would be remembering the controls and aircraft procedures. No, my biggest problem is freaking SteamVR. I have wasted most of a day already, again. It’s awful.
When Steam breaks that method, then forces an update? As they have broken other things in this thread?
When, not if, because Steam will break this. We know they really don’t want us running anything but the latest version.
The huge problem with using SteamVR, or Oculus, or any of these solutions, is for monetary reasons, they push the cloud so hard, it breaks important use cases.
Yes it is. So if you can save the relevant files you can help delay that end(save in an archive and reflash the older version). Consoles love to push updates for new content releases to help prevent jailbreaking.
As I mentioned it is not a user friendly way. But in the meantime @mmorselli’s method seems to work and has instructions to block Steamvr updates. If it Valve breaks this method(quite possible and likely) he can likely help with finding away to unbreak it.
May need to create a backup of Steam itself and block the core from updating. Forced updates are indeed annoying.
However you know why Servers don’t use Rolling releases.
A friend long ago hated Steam as at one time everytime he wanted to play a game he had to wait on average 30m. Steam updating itself and then the game updating.
So yes I can appreciate your agitation. For example my Xbox and Steamcontroller worked perfectly for navigating SteamVR menus. Then they changed the input control structure and neglected to have a default profile in place to maintain non vr controller support. Requiring to manually remap controls. 🤦
Anyway, workaround I seem to be going with for the short term is to do ‘room setup’ seated mode for anything remote flight sim like, including Elite Dangerous.
Long term, I am working on alternative software paths that do not involve SteamVR. If I have to, I will just give up VR flight sim stuff altogether until I have my own VR applications to use…
I am sure we will get there. Just unfortunately adoption at times creates road blocks of it’s own. It is how we got Windows instead of the better option at the time Os/2. MS marketed the hell out of it and used patches to make faulty memory modules work.
After getting most of my background programs working again (disabling some stuff SteamVR broke), now it turns out both Elite Dangerous and DCS World have unusable performance right at the menu screens.
SteamVR changelogs indicate this is due to … recent versions of SteamVR causing frame drops with any NVIDIA drivers newer than … ridiculously old version.
At this point, I am not sure I will ever get my software toolchains working again, short of developing OpenHMD and my own flight sim.
Sorry to hear. Sounds like need a program to help keep SteamVR like an LTS server distro.
Did you ever look at Flightgear? It was opensource so if you are going to work on a Sim it might have an okayish starting point. I tried it out years and years ago as it had nice visuals at the time.
But now the remaining development effort is less than the trouble of making the bad Lighthouse work. Moreover, there is a real need for more optical tracking of joystick-like devices, a problem Lighthouse will never be relevant to.
I have been doing the theoretical work for a few years now. Laser speckle, white light interferometry, cameras, modulating one emitter at a time for identification… I know how to do this.
That’s what it would be, if I were not actually prepared to put up.
Agreed. I have to prioritize though. My hope was ‘it works’ would at least be better than nothing.