SRGB and SDK 0.6.0.0

I'm not sure I understand what you are trying to do or what the actual problem is.

As far as I know, it's not possible to have a single app that works with both 0.6 and 0.8 SDKs. You should, ideally, just get it working on 0.8. Users will eventually upgrade and no one will be able to provide support or bug fixes for deprecated versions of the SDK. Hope that makes sense.

I must contradict, it is perfectly possible to have one App working with Runtime 0.6 and 0.8 (not 0.7 but just because it is horribly buggy)

I know it because our App already works great this way! The only problem is the misinterpretation of Gamma when a App compiled to SDK 0.6.0.1beta is run on a Runtime 0.8beta (gamma is correct with the very same App and Runtime 0.6 installed). The solution would be to fix the Gamma for the Runtimes false auto-detection (yeah we developers really need a non working autodetection and having explicit flags taken away) to remain with a single binary. The other way would be to have different binarys - one for Runtime 0.6 with correct Gamma, and one compiled to SDK 0.8 for Runtime 0.8 just because the SwapTexture gracefully "autodetect" the gamma in a wrong way when compiled against SDK 0.6 and you can not set the needed flag in SDK 0.6 to force Runtime 0.8 not to do shit.

Why do you think this is not possible? It was possible with any other Runtime to execute Apps compiled against lower SDKs - the only break came with Runtime 0.7 from were compatibility just remains back to SDK 0.6?! There are even corresponding DLLs with each Runtime for some lower Runtime compatibility. Having just Runtime 0.8 and no SDK at all on a Windows 10 machine for example, will come with 0.6 compatibility DLLs, and they work perfectly beside broken Gamma "Autodetection".

BTW: An App compiles with an SDK, but will run only with the Runtimes, not the SDKs... one has to keep clean with wording here, because the topic is perplexing enough even without mixing up SDK and Runtime.

And the reason why we don't want to compile against SDK 0.8 is it is big PITA. This would force our users to take Runtime 0.8 - but with 0.8 you loose all the backwards compatibility from Runtime 0.6.0.1beta, resulting in constant Runtime deinstallation and installation f.e. you need to run something different that was compiled with SDK 0.5, 0.4.3... or needs extended Mode. Being a developer Nanny and constantly taking away capability's with each new Runtime/SDK will slow down update proccess to later SDKs instead of accelerating it. If Runtime 0.8 would have kept compatibility for older SDKs, there would be no reason for us to have the big wish for capability of still running on Runtime 0.6. We have implemented DirectMode support, so for our App it is no problem - but as developers we know the PITA of constantly rebooting and installing different Runtimes for compatibility reasons. The possibility to run on Runtime 0.6 that can remain backwards compatible solved this until this Gamma problem.

Our Problem? We are doing things correct as with Runtime 0.6 and SDK 0.6 we had correct Gamma were others doing it wrong came up with a picture to light. But when you run with Runtime 0.8 and SDK 0.6 the Runtime falls back to the errors of Runtime/SDK 0.5 were the picture from others making failures looked correct (the one that looked to light with 0.6 then). Now that Runtime 0.8 running on SDK 0.6 behaves as Runtime 0.5 on SDK 0.5, we need to force the error leading to too bright pictures (in other projects) to have a workaround for a correct picture. This is so sick!

Good news:

Having compiled with SDK 0.8beta shows the Textures with correct Gamma and except small SDK changes the absolute same code.

Bad news:
Next heavy Bug in the Runtime/SDK

We are currently using two SwapTextureSets (one for the left and one for the right eye) because we have two fullscreen eye textures rendered, and creating multiple SwapTextureSets seems to be the only way to have multiple TextureSources for dedicated Eye-Textures.

Now to the Error in the SDK: The creation of the second SwapTextureSet fails with DXGI_FORMAT_R8G8B8A8_UNORM_SRGB as requested by the documentation. The exact same thing worked on SDK 0.6.0.1beta (even with Runtime 0.8), and works for the first SwapTextureSet requested. Creation of two SwapTextureSets still works when requesting with DXGI_FORMAT_R32G32B32A32_FLOAT, or when using OpenGL.

Sidenote: Strangely the SDK reports I should call with ovrSwapTextureSetD3D11_Typeless weather I call it with or without, but that is not the correct hint, since it worked for the first texture. The second call failing also works when called first, but then the second (former first) SwapTextureSet creation fails.

Guess it is time for the next workaround to blit them both into just one SwapTextureSet. But then again it might be better to blit both buffers to a Single oversized texture all the way, because the header states:
"Multiple calls to ovr_CreateSwapTextureSetD3D11 for the same ovrHmd are supported, but applications cannot rely on switching between ovrSwapTextureSets at runtime without a performance penalty."

But what is the sense of using multiple SwapTextureSets and having different ColorTextures in the Layer for each eye, If rendering may not perform this way?

However, this is the next Workaround for heavy bugs in the SDK and it would be rather more fun to actually develop the product instead of finding out about major bugs in the SDK and then developing workarounds.

PS: The header for ovr_CreateSwapTextureSetGL is talking about "Multiple calls to ovr_CreateSwapTextureSetD3D11..." also, and there is no

// Query the HMD for the current tracking state.
ovrTrackingState ts  = ovr_GetTrackingState(session, ovr_GetTimeInSeconds());

as stated here:
https://developer.oculus.com/documentation/pcsdk/latest/concepts/dg-sensor/
There is a final bool parameter missing!

Also there is no:

// Get both eye poses simultaneously, with IPD offset already included.
double displayMidpointSeconds = GetPredictedDisplayTime(session, 0);

as stated here:
https://developer.oculus.com/documentation/pcsdk/latest/concepts/dg-render/#dg_multi_thread_engine_update_render
There is a leading "ovr_" missing, but this are only the small pitfalls I accidentally crossed beside those heavy bugs...

Let me have someone take a look at that.

We'll get that fixed.

Thanks,
Bruce

"brucegoculus" wrote:
We'll get that fixed.

Thanks,
Bruce

What exactly? The big bug that you can not request two SwapTextureSets with DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, or the minor flaws in the documentation?

I think brucegoculus was referring to the docs, but I will see if anyone knows about your other issue.

@thewhiteambit: Can you share a simple repro project that I can send to the engineering team? From what I understand, Oculus World Demo uses a different SwapTextureSet per eye, so there is a way to make it work. You can also toggle sRGB with the F5 key. Maybe take a look at that code for help.

"cybereality" wrote:
@thewhiteambit: Can you share a simple repro project that I can send to the engineering team? From what I understand, Oculus World Demo uses a different SwapTextureSet per eye, so there is a way to make it work. You can also toggle sRGB with the F5 key. Maybe take a look at that code for help.

I might make a simple sample once I have made the workaround. The Oculus World Demo does not look as if it were using different SwapTextureSets for each eye, from this it looks very much as if they share one texture for each eye:

        
        EyeLayer.Header.Type    = ovrLayerType_Direct;
        EyeLayer.Header.Flags   = (TextureOriginAtBottomLeft ? ovrLayerFlag_TextureOriginAtBottomLeft : 0);
        EyeLayer.Direct.ColorTexture[0] = DrawEyeTargets[Rendertarget_BothEyes]->pColorTex->Get_ovrTextureSet();
        EyeLayer.Direct.ColorTexture[1] = DrawEyeTargets[Rendertarget_BothEyes]->pColorTex->Get_ovrTextureSet();
        EyeLayer.Direct.Viewport[0].Pos.x  = 0;
        EyeLayer.Direct.Viewport[0].Pos.y  = 0;
        EyeLayer.Direct.Viewport[0].Size.w = HmdDesc.Resolution.w / 2;
        EyeLayer.Direct.Viewport[0].Size.h = HmdDesc.Resolution.h;
        EyeLayer.Direct.Viewport[1].Pos.x  = HmdDesc.Resolution.w / 2;
        EyeLayer.Direct.Viewport[1].Pos.y  = 0;
        EyeLayer.Direct.Viewport[1].Size.w = HmdDesc.Resolution.w / 2;
        EyeLayer.Direct.Viewport[1].Size.h = HmdDesc.Resolution.h;

Thought I could easyly change the demo to request two textures of the problematic format.