Forum Discussion
Future SDK Speculations?
Hi guys,
We all know that the first DK2 batch is hold one week for waiting new SDK release.
So, I was asking myself what the new SDK may add in term of functionality (not bug fixes and stuff)
If you have ideas, you can post them here ! :D
Even if we are wrong, it would be interesting to see what the dev comunity wants from OculusVR.
Personaly, I'm actually working with Ogre, I have a functional integration of 0.3.2 on Linux/OpenGL now but I'm trying hard to have flawlessly a full screen rendering on the rift only... (I have various windows management problems in fact)
The way the SDK work right now (in case of SDK Distortion Rendering, manual stuff stays manual stuff ^^") is "Create your window and then pass it to the SDK" (ovrXXXConfig struc)
I think I would found simpler to get an OS specific window handle with a window correctly set-up by the SDK and then putting my stuff inside (or just giving the 2 textures conainign both eyes renders, and let the SDK take care of it)
your turn ! :-D
We all know that the first DK2 batch is hold one week for waiting new SDK release.
So, I was asking myself what the new SDK may add in term of functionality (not bug fixes and stuff)
If you have ideas, you can post them here ! :D
Even if we are wrong, it would be interesting to see what the dev comunity wants from OculusVR.
Personaly, I'm actually working with Ogre, I have a functional integration of 0.3.2 on Linux/OpenGL now but I'm trying hard to have flawlessly a full screen rendering on the rift only... (I have various windows management problems in fact)
The way the SDK work right now (in case of SDK Distortion Rendering, manual stuff stays manual stuff ^^") is "Create your window and then pass it to the SDK" (ovrXXXConfig struc)
I think I would found simpler to get an OS specific window handle with a window correctly set-up by the SDK and then putting my stuff inside (or just giving the 2 textures conainign both eyes renders, and let the SDK take care of it)
your turn ! :-D
7 Replies
- I think the delay is being caused by something already hinted at in the current 0.3.2 SDK:
// These flags are intended for use with the new driver display mode.
/*
ovrHmdCap_ExtendDesktop = 0x0004, // Read only, means display driver is in compatibility mode.
ovrHmdCap_DisplayOff = 0x0040, // Turns off Oculus HMD screen and output.
ovrHmdCap_NoMirrorToWindow = 0x2000, // Disables mirrowing of HMD output to the window;
// may improve rendering performance slightly.
*/
(From OVR_CAPI.h, line 132)
Cybereality has referenced it a bit before too. I don't know 100% what it is, but it seems to be some custom solution to bypass the OS and make the Rift more than a dumb monitor. This is very exciting because it should mean a much more user-friendly experience. I started to add some stuff to my game to make monitor configuration and mirroring (in the game, rather than the OS) more user-friendly - but it is looking like Oculus is developing a more engine-agnostic solution instead. Hopefully this driver (if they meant "driver" in the traditional sense) is going to be open source with the rest of LibOVR. - Sounds like something that needs support from NVidia and AMD. In the long term they certainly need to get involved if VR is going to be pain free, just treating the Rift as another monitor is fundamentally broken in many ways. It is going to be really important for consumers to absolutely never display a non-VR image in the Rift, and ideally only display an undistorted view on ordinary monitors.
Making that work well would require some display driver work to treat VR as its own special output mode beyond windowed and fullscreen with a fast path in GPU memory to mirror the display in another device context on the primary monitor. You could implement that yourself in DX11 but it would be a pretty invasive change to an engine, only the big guys would bother. Consistent behavior between applications is going to be critical.
I hope this sort of thing is what is around the corner. "PathogenDavid" wrote:
it seems to be some custom solution to bypass the OS and make the Rift more than a dumb monitor.
That would be fantastic because hadling the Rift as a second monitor is just weird and is constantly causing problems, no matter if your GPU is from AMD, NVidia or Intel.
I would also really appriciate some basic audio functionality.
spyro"spyro" wrote:
"PathogenDavid" wrote:
it seems to be some custom solution to bypass the OS and make the Rift more than a dumb monitor.
That would be fantastic because hadling the Rift as a second monitor is just weird and is constantly causing problems, no matter if your GPU is from AMD, NVidia or Intel.
I actually find the ability to use it as a cloned monitor kind of invaluable.- Shared access to the Rift by multiple applications via a DLL and a background service.
"2EyeGuy" wrote:
Shared access to the Rift by multiple applications via a DLL and a background service.
That will be great. Allowing to developp real VR "interfaces" for computers that permit to launch other programs using the rift.
But will it incrase latency ? Adding software componant that have to talk to each other, in comparaison of direct access to the resources...- I would think it more likely that instead, the separate VR applications delegate access to the rift instead, rather than a background service being thrown into the mix. It'd be more complicated, but nothing a handful of system-wide event objects can't handle.
