In Unity 2020.2 (and really all 2020 versions I’ve tested before), there’s a bug with physically rotating the camera (ie: when spinning in place in real life or simply holding the headset and spinning it around) when using SteamVR. Additionally, the headset doesn’t work at all with Unity XR, and UnityXR + SteamVR works in the sense that there’s something showing on the camera, but it doesn’t pose track and the image is frozen.
@PimaxQuorra can you please put me in contact with someone who can provide developer support or at least get this in front of their eyes? Developing with the Pimax is like floating in the ocean with no compass and the skies are so cloudy you can’t tell where the sun is or when stars are out.
what do you mean “physically rotating the camera”? you you can rotate the parent of the tracking space (and get people very sick), but you shouldnt be fighting the tracking by modifying the camera transform
i havent tried to make a pimax project since unity 2020 but that certainly sounds odd. do you have another hmd that you can plug in and try on the same project? im not so sure its a pimax issue
I actually msged my buddy with an Index to try, but it’ll be a few days since hasn’t set up his equipment in his new office yet. I have an old Vive but unfortunately it’s not readily available either. I DO have a 5k+, but that’s the one I originally had the bug on.
im surprised you havent gotten more traction on the steamvr git post, they’ve been pretty responsive for a lot of pimax issues over the years. but unity 2020 is such a mess for vr/xr in general its easy to imagine lots of bugs until the XR stuff is ready
I think it was the same issue you commented on. I’m pretty new to this (only been at it since March) so my original posts were not well explained. I edited this one and the steamVR one after your comment to try to add clarity.
i read it closer now and i recognize the problem in other systems ive made in unity before, usually it’s an issue of setting rotations greater than 180 using euler angles instead of quaternions. being that this is the built in steamvr code that might be tricky to refactor, but it’s a clue.
wouldnt explain why it might happen to pimax and not other hmd’s though, if that is proven the case once your friend gets set up.
Yeah and that’s the crazy part. That’s why I tested on just a blank new project with just SteamVR to make sure I didn’t inadvertantly do something in my code (all of which work fine in 2019). And I see posts on the git re: 2020, which is why i’m suspecting it might be some implementation of Pimax’s being the reason for the bug (unusual and odd as that seems).
For the record, Pimax’s response was to reach out to Valve despite the evidence I posted earlier showing no response from their support on this matter since August.
Look, I can make do and stick to 2019, and the brand new OpenXR plugin seems to work with the Pimax just fine, so I have that option. But unless this bug only affects me, any games developed on Unity 2020+ (which is due to enter LTS - their designation for a formal release - by March of 2021) with SteamVR will not properly function on a Pimax.
@PimaxQuorra I hope you can make this clear to your team so you don’t suddenly find your customers unable to enjoy newer games in the next few years.
The brand new OpenXR plugin works just fine with the Pimax, so this is definitely a Pimax->SteamVR bug that only manifests in 2020+.
Why do you think that?
Just to give more background:
Tracking is done in SteamVR (basically from the lighthouse driver to SteamVR runtime). SteamVR reports the tracking info to the app (in this case Unity plugin). Physically rotating the headset in the playspace works for direct SteamVR API access (and as you claim, apparently for the old plugins as well). Apart from the tracked pose (and the view camera geometry/projections), there is no other info coming from the driver (and consequently from the OpenVR client API).
I cannot see how Pimax headset (its driver) which is basically completely separated from the app, could induce the behavior you describe. There is also no way the app (the plugin) can affect the behavior of the driver.
To me it, looks like a bug in the plugin, which, for some reason incorrectly interprets the tracking info for Pimax headset. I remember there were some questionable things in the Unity plugin for OpenVR (last time I checked) related to the canted rendering and I would not be (too much) surprised if the problem manifested in the native mode.
But in parallel projection mode, I would expect the Pimax headset to behave as expected, because in this mode there is no way for an app to tell Pimax from any other headset geometry wise (at least in “Small” FOV).
“a Pimax->SteamVR bug that only manifests in 2020+.” is absolutely true (at least on my machine), so that’s why I wrote that. In case that’s not clear, what I mean is “something in how Pimax & SteamVR communicate” not necessarily that it’s Pimax’s fault/bug, so definitely in agreement with you…
Again, I just want to get this in front of whoever the right people are. The exact same setup works perfectly fine in 2019. Honestly this whole plugin thing is a mess. As soon as the Index controllers natively work in OpenXR, this’ll be a thing of the past. The question, in the event this isn’t addressed by either party, becomes how many products get created/released on 2020 using SteamVR before that happens?
How Pimax and SteamVR (runtime) communicate is completely opaque to the (SteamVR) app and does not depend on this app. In other words, if there was a problem at this level it will manifest in every app/engine.
Just out of curiosity, does it happen in native or PP mode or both?
Didn’t recently test with PP, but I think I did back when I first documented the bug in August and it was still happening. I’ve uninstalled 2020 for now so I’m disinclined to get another test environment set up. But I’ll be sure to drop an update here next time I take a dive into 2020.
Have your problem been solved?
If not, please submit a ticket through the following link, where our technical support team will provide individualized solutions for you. https://support.pimax.com/a/tickets/new
Hey,
So I finally found someone having the same problem.
I posted a new thread a few days ago about this bug.
Have you found a resolution by any chance ?
So, first of all I’m now using Hurricane/Hexabody plugins, so depending on your SDK the steps/components might differ slightly.
You should have a component on your camera for pose tracking (tracked pose driver in my case) with a field for the Pose Source, which is defaulted to Center Eye - HMD Reference. Switching that to Head works. However, I occasionally have odd performance in-editor Play Mode unless I switch away from/back to Head. Not sure if that happens in a build as I’m knee deep in prototyping these last few months and haven’t bothered.
Would really love a native solution, but every time Pimax comes up, Unity either ignores the question or says it’s not supported.
Ah Thanks
I’m not a developper but I experienced this bug while playing.
I guess I’m out of luck.
I really hope it gets addressed at some point, it really makes games unplayable.