cancel
Showing results for 
Search instead for 
Did you mean: 

Porting rendering to SDK 1.5.0

dpasca
Honored Guest
Our game is currently on the 1.0.3 SDK using the DrawEyeView path.

I’ve looked into the RENDER_MULTIVIEW approach and while I understand its purpose, I think that it’s very limiting and it would require quite a bit of refactoring.
Right now our priority is to implement the Gear VR controller, so I’d rather not have to rework the rendering pipeline around this.

One possible solution would be to render my two eye images offscreen and then pass them as “ovr surface”.
All I’d pass is two quads with two textures, one per eye.
Is that a viable solution ?
If so, is there some sample code already doing that somewhere ?

Also, I see this RENDERMODE_STEREO, but I don’t see it used in the samples. So, I’m not sure if it would be a valid alternative.

Many Thanks !
1 ACCEPTED SOLUTION

Accepted Solutions

InnerExodus
Adventurer
Hi,

Thanks for your patience while we looked into this.

The VrCubeWorld sample in the mobile SDK does this. Multiview is not required, but it can make your app up to 50% faster.

View solution in original post

6 REPLIES 6

InnerExodus
Adventurer
Hi,

I am currently looking into this issue and will advise you on what next steps need to be taken.

Thanks for your patience.

dpasca
Honored Guest
Sorry to come back on this. I was wondering if there are any news.

Thanks 🙂

InnerExodus
Adventurer
Hi,

Thanks for your patience while we looked into this.

The VrCubeWorld sample in the mobile SDK does this. Multiview is not required, but it can make your app up to 50% faster.

dpasca
Honored Guest
I see that in VrCubeWorld_NativeActivity.c  ...I should have said this more clearly, but we're trying to replace the DrawEyeView path, so we're using the VrAppInterface, meaning that we'd have to use ovrSurfaceDef to render anything to the final display.

But I'm assuming that the official answer at this point is go "full native" or to pass draw calls like in VrCubeWorld_Framework.cpp

Thanks

mcclanahoochie
Honored Guest
I am facing a similar situation, and I like the idea that is being proposed, of drawing off screen and then pass these in as ovr surface.  but I haven't quite figured out how to pull this off.  Did this ever get sorted out, and is there any sample guide that might serve as a guide?

dpasca
Honored Guest
I ended up creating one of those OVR surfaces to be used in a blit (full-screen quad) of the Left and Right eye textures coming from the rendering of the engine. The shader picks one texture or the other depending on the "view ID".

Here's my class that sets up a surface for this. Feel free to use it for reference or as it is.
It's from a few months ago, but it should still work:
https://gist.github.com/dpasca/dadf900df27299e47531ab0475c808b2