Forum Discussion
deftware
8 years agoExpert Protege
Rift not displaying my swapchain textures?
I've been hacking together a bare-minimum LibOVR test program to get my bearings with the API and see what works and what doesn't, and so far everything works fine: creating a session, querying the HMD properties, setting up eye texture swapchain, creating FBOs and attaching the swapchain texture(s) to it for rendering, WaitToBeginFrame(), BeginFrame(), EndFrame(), everything works hunky dory, no problems whatsoever: except that I cannot get my eye textures to show in the Rift for the life of me.
I've backed up, ignoring all the tracking and actually drawing anything, and am just trying to get the glClearColor() to show up, by just doing a glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) call when the eye texture is attached to the FBO, and the FBO is bound... I'm checking the result value returned by all the libOVR calls and none of them are returning unsuccessful. It properly waits until the headset is on and status.visible == true, then it actually engages the rest of the API.
Everything looks to be working perfectly, and would be if I could just see a solid green background. I can even see the guardian system boundary popping into my view when I'm on the periphery of my designated play space, so I know the headset's doing its thing and the compositor is (at least partially) working.
I tried to debug the renderpath using RenderDoc, but then the CreateSwapChain fails: I imagine because the OVR runtime doesn't operate on friendly terms with other processes trying to get in on the lower level of operation. So I'm at a total loss here.
I'm compiling with GCC/MinGW, using SDL2 for window creation and GL context creation. I'm creating a context that's SRGB capable, with a 3.3 core profile. I'm directly linking against the LibOVRRT32_1.dll because compiling against the MSVC libs is a nightmare. Everything seems to work fine, no errors anywhere, I just don't see anything I commit and submit via layers+EndFrame showing up in the HMD. There's a chance it's OpenGL state, or something in the context setup that I'm missing, but compiling the examples is not an option with the amount of work required to get it setup for GCC. The SDK docs aren't a help either. I'm doing everything exactly how they indicate.
UPDATE: Made some headway FINALLY. Got some color to show. Had something to do with glViewport, but I still cannot get it to clear to different colors on each side of the swapchain texture, the glViewport is not having it.. also, discovered that the eyepose passed into the layer plays a pretty sizable role in what is actually being shown for a given vantage. Teasing out a solid grasp of all these moving parts is going to take another day..
UPDATE2: The SDK is super finicky, and requires walking a fine line if you're rolling-your-own interface. Still haven't got everything working but at least I'm rendering different images to each eye via the API supplied swapchain texture. Now I'm trying to figure out why it's returning a pre 1.17 data structure for ovr_GetRenderDesc which excludes the Orientation quaternion member values (i.e. Orientation contains the XYZ Position values, and Position is filled with garbage). I'm requesting OVR_VERSION_MINOR, which implies 1.20, but I'm still getting this older behavior from the runtime.
- I posted more details about ovr_GetRenderDesc excluding the quaternion orientation with a v1.22 session here: https://forums.oculusvr.com/developer/discussion/61579/calling-ovr-getrenderdesc-directly-from-1-22-libovr-runttime-incongruous-with-1-17-changes#latest
- Hi @deftware, we version the export names in our runtime dll in order to maintain backward compatibility. We provide the LibOVR.lib shim library which loads the correct symbol versions for you, you can either static-link that into your code or compile OVR_CAPIShim.c into your executable directly (we provide the full shim source code in the SDK).
4 Replies
- deftwareExpert ProtegeI posted more details about ovr_GetRenderDesc excluding the quaternion orientation with a v1.22 session here: https://forums.oculusvr.com/developer/discussion/61579/calling-ovr-getrenderdesc-directly-from-1-22-libovr-runttime-incongruous-with-1-17-changes#latest
- eahProtegeHi @deftware, we version the export names in our runtime dll in order to maintain backward compatibility. We provide the LibOVR.lib shim library which loads the correct symbol versions for you, you can either static-link that into your code or compile OVR_CAPIShim.c into your executable directly (we provide the full shim source code in the SDK).
- deftwareExpert ProtegeThanks. VS apparently doesn't want to produce lib files that play well with GCC, which is why I was directly linking to the DLL. I'm curious as to why the shim isn't built into the runtime itself and just routes execution based on the requested OVR version? If that's not what the version request is for then what does it do?
- eahProtege@deftware The shim is the fixed API that you compile into your code, if we rev an API in a way that requires only a recompile (e.g. adding more fields to a struct) we'd like to avoid having to get every app to change the API calls, so we bump the version number in the export name in our DLL and map the old name to the new DLL entry behind the scenes with the shim. Note we can't change the old name in the DLL since it still has to provide backwards-compatibility for old apps.
Quick Links
- Horizon Developer Support
- Quest User Forums
- Troubleshooting Forum for problems with a game or app
- Quest Support for problems with your device
Other Meta Support
Related Content
- 2 months ago
- 10 months ago
- 9 months ago
- 5 months ago