Forum Discussion
OpenGL context management VS Oculus
Hi
I'm having some issues with writing a Oculus plugin for a platform layer i have.
To explain my issue i need to explain a bit about my plugin interface. The platform layer opens a window and creates a openGL context, then once this is done it will look for plugins. Plugins can do all sorts of things but in this example all that matters is rendering. When a plugin gets initialized, if can tell the API that it wants to intercept the applications rendering. When this call is made the Platform layer will create an additional OpenGL context and use wglShareLists to link it to the openglContext linked to the window. Then the once the plugin is activated, the plugin will take over the main rendering look, and can trigger the applications main render loop as many times as it likes and then present the result to the screen. The API intercepts FrameBufferBinds so that the application actually draws to a texture when it binds FBO 0, (Kind of nifty right? :-))
I have written a fair bunch of plugs for this to do color correction, and DK1 pluging among other things, but i cant get it to work with the new API. The issue I'm having is that it works on screen but it doesn't show up in the HMD. I assume that the rendering is working since it is warping and tracking correctly, but is unable to capture the image for some reason.
Right now the order of things are like this:
-OpenWindow.
-Create a GL Context /* WONT BE USED BY OCULUS! */
-ovr_Initialize()
-ovrHmd_Create();
-Create the GL Context the oculus renderer will use.
-ovrHmd_AttachToWindow();
-ovrHmd_ConfigureRendering
-create my textures in the oculus context.
Is this wrong, and if so how can it be wrong? I do create the window before i run ovr_Initialize, but I'm not giving ovr access to it until later and i am creating the context that will be used later. ovr shouldnt be able to care if i have an other open gl context. I'm assuming that ovr needs to create its own context and use wglShareLists, so it would matter that it gets access to the render context before the textures are created. I'm a bit lost here. If you like i can send you source code. I would be very interested to know how the capturing of the image has been implemented.
Cheers
E
Side note: the 64bit service exe crashes, the 32 bit works, im running 64 bit windows, a 64 bit app and all demos work fine.
I'm having some issues with writing a Oculus plugin for a platform layer i have.
To explain my issue i need to explain a bit about my plugin interface. The platform layer opens a window and creates a openGL context, then once this is done it will look for plugins. Plugins can do all sorts of things but in this example all that matters is rendering. When a plugin gets initialized, if can tell the API that it wants to intercept the applications rendering. When this call is made the Platform layer will create an additional OpenGL context and use wglShareLists to link it to the openglContext linked to the window. Then the once the plugin is activated, the plugin will take over the main rendering look, and can trigger the applications main render loop as many times as it likes and then present the result to the screen. The API intercepts FrameBufferBinds so that the application actually draws to a texture when it binds FBO 0, (Kind of nifty right? :-))
I have written a fair bunch of plugs for this to do color correction, and DK1 pluging among other things, but i cant get it to work with the new API. The issue I'm having is that it works on screen but it doesn't show up in the HMD. I assume that the rendering is working since it is warping and tracking correctly, but is unable to capture the image for some reason.
Right now the order of things are like this:
-OpenWindow.
-Create a GL Context /* WONT BE USED BY OCULUS! */
-ovr_Initialize()
-ovrHmd_Create();
-Create the GL Context the oculus renderer will use.
-ovrHmd_AttachToWindow();
-ovrHmd_ConfigureRendering
-create my textures in the oculus context.
Is this wrong, and if so how can it be wrong? I do create the window before i run ovr_Initialize, but I'm not giving ovr access to it until later and i am creating the context that will be used later. ovr shouldnt be able to care if i have an other open gl context. I'm assuming that ovr needs to create its own context and use wglShareLists, so it would matter that it gets access to the render context before the textures are created. I'm a bit lost here. If you like i can send you source code. I would be very interested to know how the capturing of the image has been implemented.
Cheers
E
Side note: the 64bit service exe crashes, the 32 bit works, im running 64 bit windows, a 64 bit app and all demos work fine.
22 Replies
- The Ouclus runtime actually integrates with the OpenGL driver, most likely overriding some functions. Because of this, it's going to be virtually impossible to get a stable application where some OpenGL contexts are created before ovr_Initialize and some are created after.
In order to do what you're trying to do you'll need to iterate over the plugins so that they can trigger the call to ovr_Initialize before creating the first GL context. - Can somebody in detail explain how Oculus integrates with windows and OpenGL? What is it actually doing?
Cheers
E "eskil" wrote:
Can somebody in detail explain how Oculus integrates with windows and OpenGL? What is it actually doing?
Most of the lower level details aren't known, since that's in the binary only driver they won't let us look at.
However what does happen is the oculus sdk intercepts the following win32 functions: LoadLibraryA, LoadLibraryW, LoadLibraryExA, LoadLibraryExW, GetModuleHandleExA, GetModuleHandleExW.
It then monitors any call to them for the following system libraries: dxgi.dll, d3d9.dll, d3d11.dll, dxgidebug.dll, d3d10core.dll, d3d10.dll, opengl32.dll. If one of them is being loaded, it gets replaced with an oculus library that takes over certain functions to allow stuff like direct mode.
This is why order can matter in initialising, if opengl is loaded before oculus takes over the loadlibrary calls, then you have the normal opengl instead of the oculus opengl.- Shouldn't someone form oculus be here and be able to answer this?
- Sorry for the delay.
First, make sure that you call the following function before you set up any of the other stuff you're doing.ovr_InitializeRenderingShim();
Also, watch out because framebuffer 0 isn't the backbuffer when the Oculus shims are loaded. - I tried to use the ovr_InitializeRenderingShim(); but it still doesn't work. Ive done loads of testing and I think I have some clues. I tried initializing OVR in the main application, before i do anything else, and then start the window and activate the plugin. But then the plugin refuses to give me anything and trows out an error telling me i haven't initialized OVR. Apparently the initialization in the application does not carry over to the DLL. So i try to do it the other way and move the context creation to the DLL (In the past the DLL would ask the main app to create a context for it), and it still doesn't work. Maybe it cant find the window that is being created in the EXE, but hey, I'm giving it the handle! So for as far as i can tell ALL context creation, window opening and OVR setup has to be done in the same EXE and you cant do anything in a DLL. Well possibly you can do it in a DLL but then EVERYTHING has to happen in that DLL.
This makes the OVR API utterly broken for anyone trying to support Oculus using some sort of plugin interface. I really dislike the design of an API that is trying to be "smart" and do things under the table, padding me on the head with a "Don't you worry". Well I want to know what the API is doing! I don't mind if i have to jump through hoops to make it work, just give me a API that gives me the hoops i need!
Can you please tell me what the API does under the hood?
You can download my source, my EXE and my DLL here: http://www.quelsolaar.com/oculus_test.zip
Cheers
E - I'll try to take a look at the code later today and see if I find anything.
- Thanks!
- Can you provide me with the VS solution file, or some way I can build on my Windows machine?
Just taking a quick look at the code, I see you call "ovr_InitializeRenderingShim" directly before "ovr_Initialize". However, you may want to call "ovr_InitializeRenderingShim" earlier in the code before you start initializing OpenGL.
If I could build the app, I could probably look into it further. - There's no need to call them individually if there's no gap between them. ovr_initialize includes the same functionality as ovr_initializerenderingshim (all ovr_initializerenderingshim does is call OVR::System::DirectDisplayInitialize(), which ovr_initialize also calls).
The purpose of calling ovr_initializerenderingshim manually is to set up the render shim (must be done before any opengl use by the program) without creating all the other oculus stuff too, then call ovr_initialize later to finish the start up.
