Small Rift Example in Scala on GitHub
I eventually found the time to clean up my example code. As a result, I have published a small Rift example project on GitHub. It's written in Scala and uses JOVR. I tried not to use a lot of fancy Scala stuff, but rather trying to make it look a bit like pseudo code (okay, there are still things to clean up on my todo list, but it should do). The actual Rift code is just a few hundred lines of code. So hopefully it is useful for programmers in other languages as well. BTW: You do not even have to have Scala installed to run it. If you just want to run the demo out of curiosity, I have written a small HowTo on the GitHub README.
Unfortunately, I still have one big issue: Judder. I'm currently experimenting with two approaches: Timewarp on + vsync on (running at a steady 75 fps, so it looks like the SDK syncs w.r.t. the correct display), and timewarp off + vsync off (via hmdCaps...). In the latter case, my demo runs at about 500 fps, so it takes about 2 ms to render a frame (which I can verify from the frameTiming.Delta value). But with both approaches I have a very strong judder.
At first I though it was a problem with Linux (although the OculusWorldDemo runs smooth), maybe due to issues with LWJGL buffer flipping. But then I tested the demo under Windows, and it is the same: Both approaches have judder. My next test was to run the JOVR example demos (also under Windows), and to my surprise they also have the exact same judder. Has anyone else this problem with the JOVR examples? Judging from @jherico's Youtube videos, I would say that they are running perfectly smooth...
And what really confuses me: How is it possible to have a strong judder with 500 fps in the first place? The sensor readings are just 2 ms old. Even without prediction this should give a somewhat (laggy but) smooth appearance. So my next guess was that GetEyePoses simply over- or under-predicts (that's also how the judder actually feels -- a constant shivering do to a wrong prediction vs the actual sensor reading). My idea was to replace GetEyePoses by querying the tracking state manually at specific time point. I tried to specify different time points, e.g., thisFrameTime or in the past (to disable any predicting), thisFrameTime + 2 ms, midScanoutTime... But no matter what prediction time point I use, the judder just feels the same. I would even claim that the specified time point might be ignored, since without prediction there should be a feeling of a smooth lag.
So currently I simply cannot explain why this is happening. Any ideas what else could cause this? Am I doing something wrong?
Unfortunately, I still have one big issue: Judder. I'm currently experimenting with two approaches: Timewarp on + vsync on (running at a steady 75 fps, so it looks like the SDK syncs w.r.t. the correct display), and timewarp off + vsync off (via hmdCaps...). In the latter case, my demo runs at about 500 fps, so it takes about 2 ms to render a frame (which I can verify from the frameTiming.Delta value). But with both approaches I have a very strong judder.
At first I though it was a problem with Linux (although the OculusWorldDemo runs smooth), maybe due to issues with LWJGL buffer flipping. But then I tested the demo under Windows, and it is the same: Both approaches have judder. My next test was to run the JOVR example demos (also under Windows), and to my surprise they also have the exact same judder. Has anyone else this problem with the JOVR examples? Judging from @jherico's Youtube videos, I would say that they are running perfectly smooth...
And what really confuses me: How is it possible to have a strong judder with 500 fps in the first place? The sensor readings are just 2 ms old. Even without prediction this should give a somewhat (laggy but) smooth appearance. So my next guess was that GetEyePoses simply over- or under-predicts (that's also how the judder actually feels -- a constant shivering do to a wrong prediction vs the actual sensor reading). My idea was to replace GetEyePoses by querying the tracking state manually at specific time point. I tried to specify different time points, e.g., thisFrameTime or in the past (to disable any predicting), thisFrameTime + 2 ms, midScanoutTime... But no matter what prediction time point I use, the judder just feels the same. I would even claim that the specified time point might be ignored, since without prediction there should be a feeling of a smooth lag.
So currently I simply cannot explain why this is happening. Any ideas what else could cause this? Am I doing something wrong?