Thanks for the detailed explanation. Maybe I could reference your repo as an example for Gun Club VR devs to try to adjust culling for canted projection? Although I doubt they would include the math unless they have HMD themselves…
Frustrating situation wrt support, but the only way that will change is if Pimax gets more significant marketshare, maybe that will happen one day 
Kind of off topic but for a game developer on Unreal Engine what needs to be done to solve this object culling issue so PP isnt needed?
Does it happen with UE4? Games I’ve tried never had this problem. Games that require PP most likely aren’t Unity or Unreal based.
Thanks for the detailed explanation. Maybe I could reference your repo as an example for Gun Club VR devs to try to adjust culling for canted projection?
Yes of course, the source code is licensed as public domain, free to use by anyone for anything.
I suggest to keep pestering Unity about it until you find someone at the company who will take this seriously or they’ll be annoyed enough to do it lol.
Maybe we should start a petition to show them how much interest there is in this.
A well respected former pimax employee works for Unity.
Pimax has an outdated SDK that might help with optimizing Unity for Pimax. Unfortunately outdated is the keyword. Pimax is currently behind on keeping Unreal and Unity sdk plugins up-to-date. Hopefully they can get things focused enough to release new ones that work with latest engines as there old ones are just over 2 years old.
A petition may help; but pimax either needs to gain a favorable market share or more companies need to release consumer wide FoV headsets to really drive the need.
If Oculus has sdk for Unity it might even work easier than the OpenVR one as many titles ran in Oculus mode don’t require pp, that do in SteamVR.
I am not a Unity expert, but as far as I understand what typically a Unity plugin does, it is interfacing the Unity engine with a native headset API (whatever it in Pimax case is). The problem @koochy_rat fixes is however the problem in engine itself. I.e. it gets the correct data from the headset and makes a wrong calculation. So I still cannot imagine how to fix it differently than just by applying the fix @koochy_rat proposes to the engine directly. The problem is not tied to Pimax in particular, but to any headset with canted panels (camera views) in general.
If you use a native SDK, you have way more freedom and control over the rendering instead of being constrained by the built-in OpenVR rendering. In fact Unity has proper stereo camera support (even for canted), and dual viewport culling, which would allow for > 180 degrees FOV. However, this is mutually exclusive to OpenVR, enabling this will totally disable VR.
Of course there is absolutely no way a game dev would want to use a native sdk just to support one particular headset.
OpenVR does not limit the app (the engine in this case) to use parallel cameras. It is actually completely transparent to the view geometry. The problem is then in OpenVR “support” in Unity. Anyway, my point was, the data provided by the headset (and subsequently advertised by OpenVR to the app) are correct, so there is no way to “fix” them, or make them “more correct”.
The problem is then in OpenVR “support” in Unity
Yeah, that’s exactly what I meant. They could very well have integrated their stereo camera code with OpenVR but chose not to. Probably went with a simpler model for performance reasons.
The headset SDK in just improves engine when running a particular headset and would not interfer with other headsets or VR use.
Much like optimized for Nvidia or Amd doesn’t mean it cannot be used on the other gpu vendor. Just uses gpu specific features when paired with the appropriate brand.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.