cancel
Showing results for 
Search instead for 
Did you mean: 

My OpenGL OpenVR application is very laggy

Duncan
Protege
Hi All,

I have an OpenGL application that is using OpenVR. (I know Rift is best with Oculus API, but as yet I do not have that option) Using a Vive every thing is fine. But using a Rift the image in the HMD is very very laggy and swimming. I have tried adding glFlush() and glFinish() calls all over the place. I have confirmed this on both nVidia and AMD hardware.

Has anybody else seen this? Any suggestions on how to solve it?

Thanks
4 REPLIES 4

Duncan
Protege
It would be best if you used an Oculus SDK implementation
I totally agree. But for that I have to have a large enough schedule to implement both. Which at present is not the case.

so you get higher perceived latency in head rotation
This is not just high, it is really high. i.e. Move head, watch scene catch up. 

The odd thing is that all my rendering and OpenVR's rendering is laggy, but the Guardian mesh is rock solid. Is that the effect you would expect me to be seeing? 

Is there a way for me to disable TW?


jherico
Adventurer

Duncan said:

the image in the HMD is very very laggy and swimming.

...

I have tried adding glFlush() and glFinish() calls all over the place. 


Can you create a minimal application that you can put somewhere to show the effect?  I've found that OpenGL applications run just fine through OpenVR on the Rift, so I suspect that this is some issue with how you're getting or applying the HMD transforms.  Also, you shouldn't require any explicit flushing unless you're doing things on multiple threads / GL contexts and need to do some form of synchronization.  

Duncan
Protege
Can you create a minimal application that you can put somewhere to show the effect?
Not in the short term. But I'll see what I can knock together, would you want code? Thanks for the offer of help.

Also, you shouldn't require any explicit flushing unless you're doing things on multiple threads / GL contexts and need to do some form of synchronization.
I get the effect with out any threading. But I do have a threaded rendering option, which makes little difference to the issue.

Duncan
Protege
The good news is I have figured out what was causing this issue and manged to fix it.  🙂

The issue is to do with me using the OpenGL texture that was submitted to OpenVR to draw the desktop viewport. This seems to have broken the OpenVR reprojection.

Two fixes:
1) Allow the user to turn off the mirroring.
2) Make a copy of the submitted texture before it is submitted and use the copy for drawing the desktop viewport.

I hope this helps others to avoid this issue. And thanks for the help.