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.