Integrating Preexistent OpenGL into GVRf Application

[adobodi]

I have an existing application whose drawing functionality has already been implemented in OpenGL. I am looking to ‘port’ this existing application to an Android app that makes use of the GearVR Framework. I would much prefer to not have to rewrite the existing OpenGL code, as it is useful elsewhere, and I would also like to ideally share this existent OpenGL code, as is, across platforms so that a change to my code is automatically adopted in many places. 

In essence, I would like to use GearVR Framework primarily as an abstraction layer that encapsulates the Oculus Mobile SDK and the Daydream SDK, which also manages any related device-specific idiosyncrasies. I would rather not make use of the GVRf SDK at the component / scene / etc layer, in preference to using my above-described, already-existing OpenGL code.

I have read the GVRf documentation, I have looked at the GVRf examples/tutorials, and I have grep’d around in the GVRf source code, and I can’t find a good way to achieve my goals. Is there any way that I am able to do so? Perhaps by mostly interfacing with the GearVR Native Library?

Thanks in advance!

[liaxim]

@adobodi Hi. Unfortunately what you are looking for is not supported. While internally GVRf has an abstraction layer for Oculus&Daydream, it is highly specific to GVRf. There is no standalone native library either.

[thomasflynn]

let me expand on this a bit.

What you're really looking for is OpenXR (https://www.khronos.org/openxr). However, the 1.0 spec is still not yet finished and there are no Android implementations yet. I expect that to change this year, but I haven't heard anyone commit to a specific timeline on Android. Once that comes to fruition, that is probably your best bet forward.

That being said, I have once done a hack where I ran my own OpenGL code along with the Framework. In fact, it was during a hackathon a few years ago. It does come with a lot of inherent problems. Since the Framework wants / needs to manage OpenGL state for talking to the backends (Oculus, DayDream) and your app is also changing OpenGL state, you will run into a lot of weird problems where you're just getting black, or things are not drawing as expected because of OpenGL state being in some undetermined state. That's why it needs to be unsupported. It would be a nightmare always be trying to determine whether the issue is on our side or on the app side.

It's been a few years, so my memory is a bit fuzzy on what I did. I think I set up along the lines of setting up an onDrawFrame() callback and doing my calls in there. Though, you need to be careful if you have any of your own framebuffer objects. You would need to retrieve the currently bound fbo, do your GL calls, then re-bind that fbo before leaving your drawing function.

Finally, I think we need to do some better advertising, but we migrated our source code base from GearVRf to SXR SDK (sdk.samsungxr.com). It's the same thing, but we make it more explicitly clear that we support more than just GearVR (oculus, daydream, monoscopic AR, etc.). Class names go from a GVR prefix to an SXR one. The package name gets renamed from org.gearvrf to com.samsungxr and the 'scene_object' class gets renamed to 'node'. But the SXR SDK is where we'll be making feature additions and bug fixes.

hope that helps

[adobodi]

@thomasflynn, thanks for the clarifications! And I completely understand the inherent pitfalls of wedging oneself in someplace where you may be picking a fight with a framework.

I was hoping to be able to override something simple, like a drawing primitive (e.g. cube), so as to be able to override its onDrawFrame( ) and try to take control from there. However, it feels like the rendering of the primitives is not satisfied by onDrawFrame( ) being called on the primitives themselves, and rather onDrawFrame( ) is called on something far more grand, which uses things like Scenes and RenderTargets (et al.) in one big mix that produces the render, together.

So far, in my dive into the GVR Framework, the main place I have seen where one can subclass something and then override its onDrawFrame( ) message is to either subclass the GVRViewManager, or to subclass its own specific subclasses, such as OvrViewManager. My guess would be to subclass something like OvrViewManager, override onDrawFrame( ), and be as best a citizen that I can be so as to only hijack the most limited subset of functionality of OvrViewManager that is necessary in order to achieve my goals.

Understanding that what I am doing is an unsupported hack of sorts, do you feel that subclassing OvrViewManager is a good place to start? Or is there some entirely different location within the GVR Framework that you were thinking of when you described the hackathon code that you mentioned?

Thanks again!

[thomasflynn]

@adobodi I set up a DrawFrameListener like you see in the sxr-camera2renderscript sample. In fact, I think I was doing some computer vision thing with the preview texture in that hackathon and needed some GL to accelerate it. The DrawFrameListener only gets called once per frame though. So, it's probably not what you're looking for.

If you're going to fork the codebase, then the ViewManager may be the way to go. I can't think of a better route at the moment.

And I'll reiterate an earlier point: You'll want to move to the SXR SDK code base (http://sdk.samsungxr.com or https://github.com/sxrsdk/sxrsdk/). All new development is happening there. For example, I'm adding support for the Quest over there. All that will happen in this tree are bug fixes for the existing users.

hope that helps

[adobodi]

@thomasflynn, thanks for the help--much appreciated!

I'll look into the SXR SDK.