Forum Discussion
OpenGL, direct mode, plugin -- possible?
I thought this would be relatively easy, but the more I read (here in the forums, elsewhere in the web) the more it looks like what I need to do is not possible.
tl;dr:
Is there any way for an OVR-based library loaded at run-time within an existing app to share OpenGL resources with the app in direct mode?
Long version:
I develop plugins for Max/MSP/Jitter, which is a widely-used visual creative coding platform in media art. (The same issue will apply to other platforms too). It is cross-platform and OpenGL-based. Plugins are loaded as dynamic libraries. I developed a plugin to support the oculus (http://github.com/grrrwaaa/max_oculus) which works great in extended mode/client-based rendering on a powerful enough rig. I'm sure performance would be better in direct mode, so I'd like to use this app to render GL content into a texture, and send that texture to the plugin to forward to the (direct mode) rift, for SDK rendering.
But the more I read, the more it seems like this won't be possible because of weird stuff that the SDK does to the OpenGL driver in ovr_Initialize(). Because it is a plugin, the exe has already loaded and started doing things like wglext stuff and creating windows/contexts before the library can call ovr_Initialize(). I can't force the app to link to libovr. Is what I want to do even possible? Is there e.g. a way using shared contexts to bridge between app-rendered texture and libovr SDK rendering?
It seems pretty drastic not to be able to use the SDK from a loaded library...
tl;dr:
Is there any way for an OVR-based library loaded at run-time within an existing app to share OpenGL resources with the app in direct mode?
Long version:
I develop plugins for Max/MSP/Jitter, which is a widely-used visual creative coding platform in media art. (The same issue will apply to other platforms too). It is cross-platform and OpenGL-based. Plugins are loaded as dynamic libraries. I developed a plugin to support the oculus (http://github.com/grrrwaaa/max_oculus) which works great in extended mode/client-based rendering on a powerful enough rig. I'm sure performance would be better in direct mode, so I'd like to use this app to render GL content into a texture, and send that texture to the plugin to forward to the (direct mode) rift, for SDK rendering.
But the more I read, the more it seems like this won't be possible because of weird stuff that the SDK does to the OpenGL driver in ovr_Initialize(). Because it is a plugin, the exe has already loaded and started doing things like wglext stuff and creating windows/contexts before the library can call ovr_Initialize(). I can't force the app to link to libovr. Is what I want to do even possible? Is there e.g. a way using shared contexts to bridge between app-rendered texture and libovr SDK rendering?
It seems pretty drastic not to be able to use the SDK from a loaded library...
6 Replies
- For OpenGL, it's especially important to load our shims before the graphics driver because we change the behavior of the color buffer, re-mapping it to a D3D11 texture. You could write a proxy executable for the host program that initializes the shims and then exec's the regular program. Then the usual resource sharing should work. But I'm not sure this will make things any faster. And the shims may interfere with other contexts in the host app.
- vrdaveb: Could you please take a look at my code here:
viewtopic.php?f=20&t=19937
Ive been trying to make a plugin interface for OVR for a number of weeks and have not been very successful. And i even create a specific context just for the plugin. Its news to me that you are bringing in a D3D texture in to the mix... Why would you need to remap the color buffer? Why dont you draw to your own buffer and leave the application alone? Could you please explain In greater detail what the driver is up to? - Thanks for the speedy reply!
A proxy executable isn't feasible -- this is an app used by a large community, and used for many different purposes; a proxy exe just feels wrong. Is there any plan to find an OpenGL implementation in the SDK that does not require the shim?
"But I'm not sure this will make things any faster." -- do you mean OpenGL direct mode/SDK rendering is no faster than extended desktop/client rendering?
"the shims may interfere with other contexts in the host app" -- what exactly can the possible interferences be? This could be a deal-breaker. - I would recommend using extended mode SDK rendering in your use case.
"grrrwaaa" wrote:
Is there any plan to find an OpenGL implementation in the SDK that does not require the shim?
We are investigating better ways of interfacing with OpenGL (and D3D) that would support use cases such as yours. It shouldn't be too long before we have more information about that."grrrwaaa" wrote:
do you mean OpenGL direct mode/SDK rendering is no faster than extended desktop/client rendering?
SDK rendering is likely to be faster than client rendering, but direct mode is not necessarily faster than extended mode, especially with OpenGL."grrrwaaa" wrote:
what exactly can the possible interferences be?
No shimming occurs in extended mode. In direct mode, we do things like disable MSAA and sRGB. It could break the app's assumptions or result in an invalid OpenGL state. I would not recommend using direct mode with apps that maintain non-VR contexts and viewports. - Gotcha. It would be great if a future SDK update removed the need for the shim.
In the meantime I'll see what I can do with SDK rendering (and multi-threading...)
Thanks! - Well so far having no luck with SDK rendering -- just a blank screen. I know the textures are valid, but nothing seems to happen in ovrHmd_EndFrame(). Will keep on struggling...
