Problem with CalcEyePoses

[vpenades]

I'm trying to update a project I have that was using the old wrapper by MortInfinite with your new wrapper, after some tinkering I got it working!, but I realized something was odd... the depth sensation was lost.

After some testing and data analysis, I've found out what I think is the problem.

EDIT: Initially, I thought the problem was OVR.CalcEyePoses, but I've confirmed the problem is located in OVR.GetRenderDesc

The structure returned by GetRenderDesc gives EyeRenderDesc.HmdToEyePose.Position always as Vector3(0,0,0), resulting in no separation between the eyes, so when we pass two (0,0,0) vectors to CalcEyePoses, it result in the same transformation.

I've faked the values returned by GetRenderDesc and suddenly the depth sensation is back!, but it's a hack, so I guess this needs to be fixed

I guess this was affected by the removal of HmdToEyeOffset from EyeRenderDesc structure.

[bamyazi]

I've just encountered the same problem...

Strangely the correct value appears to be contained in eyeTexture.RenderDescription.HmdToEyePose.Orientation.X
use this
eyeTexture.HmdToEyeViewOffset = new Vector3f(eyeTexture.RenderDescription.HmdToEyePose.Orientation.X,0,0);
and everything works..

[ab4d]

The problem is that the GetRenderDesc is returning the EyeRenderDescTest in the old format (SDK v1.16).

I have opened the issue on the Oculus forum:
https://forums.oculus.com/developer/discussion/58426/ovr-getrenderdesc-is-returning-old-ovreyerenderdesc-struct-sdk-v1-16-instead-of-v1-17/p1?new=1

A workaround is to change the GetRenderDesc method in OvrWrap32.Common.cs and OvrWrap64.Common.cs to:

        public override EyeRenderDesc GetRenderDesc(IntPtr sessionPtr, EyeType eyeType, FovPort fov)
        {
            var eyeRenderDesc = SafeNativeMethods.ovr_GetRenderDesc(sessionPtr, eyeType, fov);

            // Workaround for invalid EyeRenderDesc layout (ovr_GetRenderDesc is returning struct in a v1.16 version of EyeRenderDesc)
            // ReSharper disable once CompareOfFloatsByEqualityOperator
            if (eyeRenderDesc.HmdToEyePose.Position.X == 0)
            {
                eyeRenderDesc.HmdToEyePose.Position.X = eyeRenderDesc.HmdToEyePose.Orientation.X;
                eyeRenderDesc.HmdToEyePose.Position.Y = eyeRenderDesc.HmdToEyePose.Orientation.Y;
                eyeRenderDesc.HmdToEyePose.Position.Z = eyeRenderDesc.HmdToEyePose.Orientation.Z;

                eyeRenderDesc.HmdToEyePose.Orientation.X = 0;
                eyeRenderDesc.HmdToEyePose.Orientation.Y = 0;
                eyeRenderDesc.HmdToEyePose.Orientation.Z = 0;
                eyeRenderDesc.HmdToEyePose.Orientation.W = 1;
            }

            return eyeRenderDesc;
        }

I hope that there will be a solution soon. If not, then I will publish a workaround into the library.

[bamyazi]

Ahh thats a much nicer solution in the meantime and cleaner to fixup when/if oculus sort the core issue rather than having hacks in code outside the wrapper. On a different topic (i couldn't see a way to pm you) i've started wrapping the avatar api - following the same code pattern as you have for the core wrapper and am making fairly good progress - i can now initialize the avatar system and pump the message queue to get the avatar specification which is the heart of it, but have only implemented just enough to do that so far - although the rest is really just legwork reading header files and documentation to wrap the full api - is this something you'd be interested in adding to this project or perhaps even just give me some pointers on things if i get stuck until i get things up to a level where you could merge it in ?

[ab4d]

It does not look like there will be a solution from Oculus soon - hopefully with the next SDK release.
Therefore I have just pushed a workaround to the master. There is also a test to check if the eye position is correct.

I saw that there was also a problem in the sample code - the RenderDescription in the eyeTexture was not set. I have also fixed that.

It would be GREAT to get support for avatars!
I will contact you privately and discuss what is the best way to add that to this project.

[vpenades]

@ab4d Good to know, let's hope Oculus begins showing more interest on the issue, there's life beyond Unity and Unreal.

Btw, I've checked the minor.18 SDK and it seems there's no changes in the API, so, it is safe to run the wrapper passing minor.18 instead of minor.17?

On a side note: have you been able to explore the possibility of doing HTC Vive too?

[ab4d]

Hi Vincente, The Oculus team has provided a solution that I have put into the project. Now it works well without a workaround. I have also checked the SDK 1.18 and there are no changes so you can use either 17 or 18 as minor version. I have just seen that there is a c# wrapper for OpenVR - https://github.com/ValveSoftware/openvr/blob/master/headers/openvr_api.cs Currently I an very busy with some other things, but hopefully I will find some time and try to find a way to use OpenVR - it should also work with Oculus. Do you have HTC Vive? I do not plan to purchase it in the near future. So I would be good to know somebody that could try the OpenVR implementation on Vive. Best regards, Andrej Benedik PS: The other user that have written on the OculusWrap issue (bamyezi) is going to privide support for Oculus Avatars in the future.

…

On Thu, Oct 19, 2017 at 12:07 PM, Vicente Penades ***@***.***> wrote: @ab4d <https://github.com/ab4d> Good to know, let's hope Oculus begins showing more interest on the issue, there's life beyond Unity and Unreal. Btw, I've checked the minor.18 SDK and it seems there's no changes in the API, so, it is safe to run the wrapper passing minor.18 instead of minor.17? On a side note: have you been able to explore the possibility of doing HTC Vive too? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXw4ZXGtDT6UMeeKQlRXXteRNIJgJ_6nks5stx9rgaJpZM4P2JuR> .

[vpenades]

Hi, great to know oculus finally responded, I'll check the patch next weekend.

I only own a DK2, not even with the touch controllers, with I've been told are not compatible with the DK2, and don't know anybody with a Vice.

The whole point of trying another headset is to try to understand the common aspects of what's required for VR, to try, at same point, to make same kind of common abstraction.

I don't plan to get a Vive, if anything, I might consider getting one of those cheaper windows mixed reality headsets

[bamyazi]

Might be worth waiting a few months to see what happens with the Pimax kickstarter before shelling out on the Windows headsets - they raised 2 million as of yesterday and their 5k version looks to be similarly priced (although without the inside out tracking) - if they start to deliver on schedule could be worth the wait esp given the price they're suggesting on the kickstarter for the 8k and with controller support via lighthouse - i haven't seen a bad review yet (that i consider relevant)

The DK2 is actually pretty good tbh - the touch controllers are a huge jump in immersion but in terms of visual quality the DK2 stands up well compared to the CV1 imho (i have all 3 rifts)

[bamyazi]

OpenVR may be the way to go for a common abstraction - if/when it gains traction - i haven't looked at it much yet, but we need a common API ala OpenGL etc for VR, I'm working toward developing things more geared to industrial applications so it's more acceptable to force a platform, but i suspect Google & MS aren't going to converge on the Oculus API

[vpenades]

I think 4k and 8k headsets just solve half of the problem... it's about having a computer powerful enough to deliver 4k/8k renders at 90/120fps , the bandwidth is gargantuan.

In the long run, I suspect we will get 4k and 8k headsets anyway, but with some sort of inbuilt post processing to enhance 2k to 8k, so average graphics cards should be able to deliver renders, maybe even throught wifi.

Btw, what I'm trying to do is to try integrate oculus with MonoGame, but it's going to be extremely difficult... MonoGame doesn't expose enough internals to do the job well

[bamyazi]

Have a look at Wave Engine https://waveengine.net/ they have some code that's pretty close to Monogame (i think it's also a fork of the same code here). Problem with Monogame is that it wraps the raw DX stuff in a way that doesn't easily allow you to access the underlying DirectX things