cancel
Showing results for 
Search instead for 
Did you mean: 

How to disable Low Peristence Display Mode in Mobile SDK / Native Apps?

cversek
Level 3
I know that this question has been asked before because people don't like the flicker effect of low persistence mode, this is not my main reason for wanting the ability to disable this feature.  After much searching I have found that there has not been a satisfying answer given by Oculus/Samsung nor the community as to why they cannot expose a toggle for this feature in the SDK.   I am researcher trying develop Gear VR apps (starting with the native C++ framework examples)  with precise flickering stimuli in order to induce a particular pattern of brainwave response known as ssVEP (stead-state visually evoked potentials) to be read with EEG instrumentation.  The problem is that the low persistence 60Hz screen blanking pulse modulates the ssVEP stimuli creating a confusing non-linear response (yes, a real observed brain response!) that I don't see when using a full-persistence display. These apps do not use head-tracking, they display a virtual screen that is essentially fixed to the view, so no simulated head motion is present - in other words - I don't care about motion blur.  Unfortunately, after months of effort spent learning the tedious C++ app development cycle, I think that I will have to switch to Google VR (Cardboard, Daydream, or another mobile platform) because of this one issue.  I might even be satisfied if someone has an effective workaround rather than a sanctioned SDK feature.
2 ACCEPTED SOLUTIONS

Accepted Solutions

cversek
Level 3
Despite the surprisingly unhelpful Gear VR community, I managed to find a work-around that works for my application.  In the AndroidManifest.xml change the value attribute from `vr_only` to `vr_dual` (`vr_both` also seems to work - what's the difference?):
<meta-data android:name="com.samsung.android.vr.application.mode" android:value="vr_dual"/>
Also the manifest  `application` tag should contain the intent-filter which was already part of the example code:
            <!-- This filter lets the apk show up as a launchable icon. -->
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>

These settings have the effect of disabling the low-persistence flicker, head-tracking, probably the time-warp and all that jazz (all the better for my app ) -  leaving a stereoscopic, lens pre-distorted, fixed-view.  The app can be started using an icon launcher, but, unfortunately, when you put it in the Gear VR it stupidly launches the Oculus Home application. 

No matter, we just install one of those sketchy package disablers and take out that overbearing nanny the 'Gear VR service`.  However all is not well in VR Land... disabling this service has the - yet again unfortunate - side-effect of changing the lens distortion, at least on the Galaxy S7 giving a narrowed FOV and a slight barrel bulge effect for flat surfaces.  At least this gives me something worth testing.  Maybe the correct distortion parameters can be baked into the app?

At the end of the day, this whole development process leaves me with a bad taste.  As a researcher with special needs, I usually choose to go with platforms that are open and highly configurable, but the Gear VR appeared to be the best choice at the time given previous experience with the Oculus DK2.  In the future I will probably go with Google VR as that company has a better reputation of respecting developer freedoms and encouraging innovation outside the walled-garden that companies like Samsung and Oculus are trying to create.  Should we blame the FaceBook and VC influence? After all, when and why did they drop Linux support (BTW it's very easy but not supported to build Gear VR apps on Linux using the OS X instructions with some tweaks)? Why have they been taking away the ability to configure the HMD capabilities with every new SDK update?  This is a disturbing trend that alienates whole communities of developers and innovators who will create new markets for VR technology, not just flashy game demos.

View solution in original post

cversek
Level 3
UPDATE:
So setting `vr_dual` mode and disabling the Gear VR Service seems to mess with the default settings causing the aforementioned geometry problems.  In particular:
  1.  `vr_dual` seems to create a monoscopic view by overwriting the `ovrHeadModelParms` struct, which can by forced back to the defaults to restore stereoscopicity.
  2.  disabling Gear VR service changes the field of view, shrinking the "viewport" dimensions and changing the FOVdegrees, altering the distortion.  The field of view can be tweaked back to create a reasonable distortion by setting the X and Y angles to something like 100 degrees for the 2016 Gear VR using Galaxy S7.  I have no fix for the smaller viewport boundaries yet, but the concern for me is a minor one.
I've purposely left out the code details to do this, so if anyone is interested in the hacks, please contact me privately. 

View solution in original post

3 REPLIES 3

cversek
Level 3
Despite the surprisingly unhelpful Gear VR community, I managed to find a work-around that works for my application.  In the AndroidManifest.xml change the value attribute from `vr_only` to `vr_dual` (`vr_both` also seems to work - what's the difference?):
<meta-data android:name="com.samsung.android.vr.application.mode" android:value="vr_dual"/>
Also the manifest  `application` tag should contain the intent-filter which was already part of the example code:
            <!-- This filter lets the apk show up as a launchable icon. -->
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>

These settings have the effect of disabling the low-persistence flicker, head-tracking, probably the time-warp and all that jazz (all the better for my app ) -  leaving a stereoscopic, lens pre-distorted, fixed-view.  The app can be started using an icon launcher, but, unfortunately, when you put it in the Gear VR it stupidly launches the Oculus Home application. 

No matter, we just install one of those sketchy package disablers and take out that overbearing nanny the 'Gear VR service`.  However all is not well in VR Land... disabling this service has the - yet again unfortunate - side-effect of changing the lens distortion, at least on the Galaxy S7 giving a narrowed FOV and a slight barrel bulge effect for flat surfaces.  At least this gives me something worth testing.  Maybe the correct distortion parameters can be baked into the app?

At the end of the day, this whole development process leaves me with a bad taste.  As a researcher with special needs, I usually choose to go with platforms that are open and highly configurable, but the Gear VR appeared to be the best choice at the time given previous experience with the Oculus DK2.  In the future I will probably go with Google VR as that company has a better reputation of respecting developer freedoms and encouraging innovation outside the walled-garden that companies like Samsung and Oculus are trying to create.  Should we blame the FaceBook and VC influence? After all, when and why did they drop Linux support (BTW it's very easy but not supported to build Gear VR apps on Linux using the OS X instructions with some tweaks)? Why have they been taking away the ability to configure the HMD capabilities with every new SDK update?  This is a disturbing trend that alienates whole communities of developers and innovators who will create new markets for VR technology, not just flashy game demos.

View solution in original post

cversek
Level 3
UPDATE:
So setting `vr_dual` mode and disabling the Gear VR Service seems to mess with the default settings causing the aforementioned geometry problems.  In particular:
  1.  `vr_dual` seems to create a monoscopic view by overwriting the `ovrHeadModelParms` struct, which can by forced back to the defaults to restore stereoscopicity.
  2.  disabling Gear VR service changes the field of view, shrinking the "viewport" dimensions and changing the FOVdegrees, altering the distortion.  The field of view can be tweaked back to create a reasonable distortion by setting the X and Y angles to something like 100 degrees for the 2016 Gear VR using Galaxy S7.  I have no fix for the smaller viewport boundaries yet, but the concern for me is a minor one.
I've purposely left out the code details to do this, so if anyone is interested in the hacks, please contact me privately. 

View solution in original post

christoph_geske
Level 2
Hallo @cversek and community,
I have a question regarding the Low Peristence Mode.

I would like to enable this mode on Cardboard apps since I noticed the Cardboard experience is improved by enabling this mode.

Cardboard VR is the only mobile VR platform that works on all phones and since GearVR and Daydream are not supported anymore, even very capable phones have to use the crappy Cardboard tracking and display mode.

On the S7 it was possible to enable the 
Low Peristence Display Mode by enabling gearVR developer mode. Enabling developer mode allowed even non GearVR apps to run with this low pers. mode active. This way the standard Cardboard experience could be improved. 
I would like to have this same feature ideally using Unity or Android Studio improving Cardboard on the latest phones.

@cversek since you where able to disable the feature in the manifest I wonder if it is also possible enable it somehow on non GearVR devices. 

Daydream ready phones are able to do this out of the box as was mentioned in this old article: [[www.]]roadtovr.com/google-cardboard-apps-daydream-phone-performance/

Thanks