Oculus Rift SDK 1.3 released

[BrickFarmer]

Awesome! I could not find the OVR_FORMAT_R8G8B8A8_UNORM_SRGB, and I also had a couple other bugs that I probably would have spent a whole day tracking down if it wasnt for your help, big thanks!  We have some code differences that I will investigate after some sleep, but at least my scene renders again

https://github.com/WhiteHexagon/example-lwjgl3-rift/blob/master/src/main/java/com/sunshineapps/rift/experimental/RiftWindow130.java

[spasi]

Reminder: struct setters return the struct instance, so you could change code like this:

OVRTextureSwapChainDesc swapChainDesc = OVRTextureSwapChainDesc.calloc();
swapChainDesc.Type(ovrTexture_2D);
swapChainDesc.ArraySize(1);
swapChainDesc.Format(ovrFORMAT_R8G8B8A8_UNORM_SRGB);
swapChainDesc.Width(textureW);
swapChainDesc.Height(textureH);
swapChainDesc.MipLevels(1);
swapChainDesc.SampleCount(1);
swapChainDesc.StaticImage(false);

to this:

OVRTextureSwapChainDesc swapChainDesc = OVRTextureSwapChainDesc.calloc()
	.Type(ovrTexture_2D)
	.ArraySize(1)
	.Format(ovrFORMAT_R8G8B8A8_UNORM_SRGB)
	.Width(textureW)
	.Height(textureH)
	.MipLevels(1)
	.SampleCount(1)
	.StaticImage(false);

Also, the format tokens have a wrong prefix, e.g. ovrFORMAT_R8G8B8A8_UNORM_SRGB should be OVR_FORMAT_R8G8B8A8_UNORM_SRGB. Will be fixed in the next build.

[BrickFarmer]

thanks, the struct thing is nice, more like a streams/DSL approach I see Java using more and more, although an eclipse reformat messed it up.

I fixed some memory leaks and cleaned up how the app responds to being started with oculus home, ie not visible.  I still have a couple issues, I get a hard VM crash upon exit that I'm trying to track down, and I'm not sure that I have my math correct for looking into the scene.  Looking around is fine, but when I try to look closer at an object by moving my head forwards, I'm not sure that is working, or maybe its just my scene is too far away.  I have to experiment some more, but otherwise LWJGL seems to be working really well with the Rift SDK.  Thanks to you both for your help!

[bluenote10]

Oh yes, that is something I forgot to mention yesterday: I think you have to get rid of this offset. When you compute the eye poses from the main head pose by using ovr_CalcEyePoses, they already incorporate the eye separation offset. In older SDK versions you had to do that manually, now you can just use them directly. Since you add the eye offsets on top of that, you probably end up with twice the IPD, which may cause these scale issues.

If you are (like me) still using DK2, note that the 1.3 no longer has a software configuration for the IPD, so it will by 64mm anyway. If I understand it correctly, the IPD of the CV1 will be reported according to the physical IPD slider on the HMD. That is actually something I still have to change in the above example: The hmdToEyeOffsets should be queried every frame, exactly like you already do.

Regarding the VM crash: I also had problems with this if I shutdown GLFW before destroying the texture swap chain (I somewhere read that it should be like that -- exact inverse of the initialization). I have now switched to shutting down LibOVR first, which seems to work for me.

[BrickFarmer]

Thanks for the tips and explanation.  I'm also on the DK2 so I'm missing the IPD override.

crash was exactly as you mentioned, just the order of shutdown, but I also found a couple of my bugs whilst trying to fix that

I also added some code to check the SessionStatus, and I found that on the first 2 frames IsVisible() returns true, then I get a frame submit error and then isVisible() returns the expected false, until the HSW has been 'clicked'.  What I would expect is that the isVisible call always return false until HSW has been clicked.  Is that the reason you do an early comit (line 129 in your posted code)?

[bluenote10]

@BrickFarmer: I do this early commit because the documentation says that every submitFrame must be preceded by a commit. Actually I think I can just place it at the top of the loop.

One question: Do you think that Asynchronous Timewarp (ATW) is working for you? I had a feeling that my (rare) "application dropped frame" in fact do cause judder, which they should not if ATW would do its thing. I just ran a worst case test and put a Thread.sleep(50) in my rendering loop. Unfortunately, the result is nothing like the native Oculus examples, where even not re-rendering at all is still smooth thanks to re-projection. So it looks like ATW is not yet really working.

@spasi: Do you happen to have any idea what could cause this? ATW requires asynchronous context handling and I'm wondering there is something obvious in the context handling which could prevent this?

[spasi]

Sorry, can't think of anything that would affect ATW.

Have you tried running with ovrInit_Debug? It may produce ovrLogCallback output related to ATW.

[bluenote10]

Thanks for the quick feedback. Now I can confirm: ATW itself definitely works. When I set the sleep to like 5 seconds, I do get reprojection during these 5 seconds (i.e., the world feels stationary while turning the head). The actual problem is that when the frame refreshes, it somehow uses the old view pose. This means that if the view direction has changed in these 5 seconds, the world suddenly "jumps", centering the old view direction in the new view direction. After the next frame update, the new position will be used, so the world jumps back to where it was before. So it looks like ATW simply trails by one frame, which causes the world to jump back and forth each frame. I hope it is just a bug in my wrapper code above or maybe some frame queuing issue.

Update:

Okay, found my mistake. This behavior is caused by having a calling order of ovr_GetTextureSwapChainCurrentIndex --> ovr_SubmitFrame --> ovr_CommitTextureSwapChain. In fact, this is probably a common pitfall when migration from 0.8. In most 0.8 examples, the last step of the rendering loop was incrementing the texture index. Since the migration guide suggests that ovr_CommitTextureSwapChain essentially replaces this texture index increment, I kept it at the end of the loop. However, ovr_CommitTextureSwapChain must be called between the other two calls, so the correct order is ovr_GetTextureSwapChainCurrentIndex --> ovr_CommitTextureSwapChain --> ovr_SubmitFrame.