Forum Discussion
Lag on OVRInput for PrimaryIndexTrigger on Touch Controllers
I've been working on a Oculus Rift game for Unity for a while now, and I noticed something today that I haven't noticed before. When I poll for the current state of the PrimaryIndexTrigger for Update(), there seems to be a noticeable lag for what gets reported back to Unity.
For example, if I rapidly pull the trigger all the way down, it takes a good 200-300 milliseconds (maybe more?) for it to return 1 from OVRInput.Get(). If I do several trigger pulls in rapid succession, ensuring I pull the trigger all the way down (hearing the physical plastic click on the controller), I've found that OVRInput never reports "1" only reporting a random range of about 0.87-0.94, and even then, lagging a bit behind when the trigger pull actually occurred.
In my game, I want to play a sound when the trigger is fully depressed, and only fully depressed, not ~50% like you get from OVRInput.GetDown(). My workaround has been to simply lower the threshold for what "fully down" means from 1 to about 0.9, which works fine for most cases, but I've found it tends to be finicky if you do a series of rapid trigger pulls.
Either way, it's not a deal breaker, and my workaround is fine, but I wanted to know whether I was maybe doing something wrong about the way I call OVRInput or whether anyone else had noticed the laggy way it reports back the current trigger state? This could just be a limitation of the way triggers report, and if so, that's fine, just wanted some clarity.
Thanks for any help you can offer!
For reference, my code looks more or less like this:
2018.1.4f (like I said, I've been developing for a while...)
Current Version of Oculus SDK:
3.4.1 (again, I'm in the "if aint broke, don't upgrade it" phase)
For example, if I rapidly pull the trigger all the way down, it takes a good 200-300 milliseconds (maybe more?) for it to return 1 from OVRInput.Get(). If I do several trigger pulls in rapid succession, ensuring I pull the trigger all the way down (hearing the physical plastic click on the controller), I've found that OVRInput never reports "1" only reporting a random range of about 0.87-0.94, and even then, lagging a bit behind when the trigger pull actually occurred.
In my game, I want to play a sound when the trigger is fully depressed, and only fully depressed, not ~50% like you get from OVRInput.GetDown(). My workaround has been to simply lower the threshold for what "fully down" means from 1 to about 0.9, which works fine for most cases, but I've found it tends to be finicky if you do a series of rapid trigger pulls.
Either way, it's not a deal breaker, and my workaround is fine, but I wanted to know whether I was maybe doing something wrong about the way I call OVRInput or whether anyone else had noticed the laggy way it reports back the current trigger state? This could just be a limitation of the way triggers report, and if so, that's fine, just wanted some clarity.
Thanks for any help you can offer!
For reference, my code looks more or less like this:
void Update()
{
if (OVRInput.Get(OVRInput.Axis1D.PrimaryIndexTrigger, current_controller) >= .85f)
PlaySound();
}2018.1.4f (like I said, I've been developing for a while...)
Current Version of Oculus SDK:
3.4.1 (again, I'm in the "if aint broke, don't upgrade it" phase)