[0.8 PC GL] copy texture to TextureSet

No, this is perfectly normal. There is no easy way (if any), to spoof the textures used by OVR-Runtime. Just copy your renderings to the textures given by OVR-Runtime and you are fine...

"kojack" wrote:
the oculus sdk seems to be keeping an internal pointer the the textures made by ovr_CreateSwapTextureSetD3D11 and is always using them.

Yes, this is your canvas for submitting content to the SDK. You can either copy to it, or better yet, wrap it in a framebuffer and either draw to the framebuffer or blit from another compatible framebuffer you've created.

There are really good reasons for the Oculus SDK to only use it's own textures as a source for rendering. For one thing, it allows the Oculus SDK to do everything using Direct3D, whether the client is using D3D or OpenGL.

"cybereality" wrote:
See this section of the docs:

https://developer.oculus.com/documentat ... dg-render/

Uhm, I'm having a similar issue with the same context form-factors (DK2, PC, OpenGL, 0.8.0beta).

In my case the ovrHmd_CreateSwapTextureSetGL() call returns a textureset with zero textures (but calls glGenBuffer as fallback), and the return value is -1006 (ovrServiceError).

Would it make sense / be helpfull to go back to 0.7.0 or something earlier? I've spent a day trying to figure this out but no luck so far.

At first I thought it was my multisample setting, but the Oculus TinyRoomDemoGL Sample also does not start up. The DX11 version works fine, and also the demo scene from the configuration shows up and works as expected, with mirror screen.

Kind regards,
Ignace

"jherico" wrote:

Yes, this is your canvas for submitting content to the SDK. You can either copy to it, or better yet, wrap it in a framebuffer and either draw to the framebuffer or blit from another compatible framebuffer you've created.

And there are good reasons, why this (except blit) is impossible in some rendering envrionments...

There are really good reasons for the Oculus SDK to only use it's own textures as a source for rendering. For one thing, it allows the Oculus SDK to do everything using Direct3D, whether the client is using D3D or OpenGL.

You can have the wildest interop of D3D and OpenGL without this - working clean with fast mutex on any modern NV or AMD GPU. Can not be the reason! Maybe it is a driver level hack for better timewarp, but there are no really good reasons I would know. Sure it is convenient in some cases, but without being able to give the SDK some shared texture handles somehow, you must have the suboptimal blit to those textures resulting in wasted GPU cycles.

"jherico" wrote:
You can either copy to it, or better yet, wrap it in a framebuffer and either draw to the framebuffer or blit from another compatible framebuffer you've created.

"thewhiteambit" wrote:
Just copy your renderings to the textures given by OVR-Runtime and you are fine...

Please, if anyone of you has a piece of working code, a functioning workaround, please share. All I get are either black textures or crashes with access violations. The theory is all fine, but I have yet to see something actually working.

"broozar" wrote:
Please, if anyone of you has a piece of working code, a functioning workaround, please share. All I get are either black textures or crashes with access violations. The theory is all fine, but I have yet to see something actually working.

I've got it working fine in DX11 using the device context's CopyResource method.

In OpenGL I'm trying to use glCopyImageSubData but it's failing. (I wish opengl would at least hint at which of the 15 parameters is causing the GL_INVALID_VALUE result)

"thewhiteambit" wrote:
You can have the wildest interop of D3D and OpenGL without this - working clean with fast mutex on any modern NV or AMD GPU. Can not be the reason!

There were severe limitations in the OpenGL functionality with versions of the SDK before it took over texture management. I believe this is because while D3D has lots of touchpoints for intercepting calls (since it's a Microsoft API), with GL, much of the dirty work goes on inside the vendor provided driver. It's possible with the advent of direct support for VR functionality in the recent AMD and nVidia drivers that this, but personally I prefer that the SDK does all the annoying dirty work of getting a texture (D3D or GL) to the screen, and for that, it really has to have ownership of the texture and the final compositing / rendering context.

In case you want to provide the texture to the runtime, it is probably because it was already created by your rendering environment - in best case as the rendertarget.

As some rendering environments don't let you set the rendertarget but give you access to the textures, you end up with a gpu-copy you would not need. Wasting GPU-time just for convenience of users considering texture creation 'dirty work', seriously?

I don't want to say the SDK should not create the textures, but being capable of inserting existent textures would be a need in some cases.

"jherico" wrote:
...but personally I prefer that the SDK does all the annoying dirty work of getting a texture (D3D or GL) to the screen, and for that, it really has to have ownership of the texture and the final compositing / rendering context.

No it does not have to create or own the texture! What makes you think it would? Both, OpenGL and DirectX feature enough interop to NOT have this need. Sorry, this sounds so DirectX/OpenGL noob (or am I missing something serious here) what you were saying about texture-ownership. Stop beveling, start knowing... you just have to assure there is no concurrent access to them, but that is all to easy with using SwapTextureSets (what brings up the problem to have a rendertarget set alternating too - in my special case a solvable problem, not even with the trade-off of more memory usage, because at least you save one texturebuffer also [minus 2 Textures owned by the OVR-Runtime, plus 1 Texture used as Rendertarget]).

https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554(v=vs.85).aspx
https://www.opengl.org/registry/specs/NV/DX_interop2.txt

@kojack For OGRE OpenGL specifically I was just hacking on this the past two days.

I got it to work (in OGRE 1.9) by linking directly against the OpenGL render system, and utilizing Ogre::GLTextureBuffer, which can take an OpenGL texture id value (provided by the Oculus SDK), and acts as a render buffer, from which you can call getRenderTarget(), and proceed with the normal OGRE render-to-texture workflow (add viewport with a camera, call update() on the viewport, etc...).

I just hacked it in, but it *appears* to be working.

"ccrooks" wrote:

I just hacked it in, but it *appears* to be working.

At least you have access to the sourcecode and insert it as rendertarget. Sometimes you don't have sourcecode but just some sealed objects with an API as unflexible as OVR currently here. This is were you end up with unnecessary copying. I am just asking for the option of DirectX interop here by providing own TextureSet. I have no problem sharing even OpenGL textures as DirectX textures with the SDK and handle syncing myself. Just in case the OpenGL side would be to hard to implement in the SDK. I already do this with my OpenGL textures - SDK side everything is used as DirectX even when using OpenGL rendering :)

PS: what you did sounds not all to hacky for me, all objects seem to be used the way they could and you end up with the normal way to render to targets