Forum Discussion
Oculus SDK for Windows 1.8.0 Released
Oculus PC SDK 1.8.0
This release includes performance improvements, memory management fixes, and minor updates.
New Features
- Oculus now provides a boundary system. When a user gets too close to the edge of the boundary, translucent boundary markers are displayed in a layer that is superimposed over the game or experience. For more information, see Oculus Guardian System.
- Added AdaptiveGpuPerformanceScale. The value is calculated as desired_GPU_utilization / current_GPU_utilization. When it is 1.0, the GPU is performing optimally. When this drops below 1.0, consider resolution and other changes to improve frame rate.
API Changes
There are no breaking changes to version 1.8.0.Known Issues
- If you encounter intermittent tracking issues, remove the batteries from any Engineering Sample Oculus Remotes that you paired with your headset and contact Developer Relations for replacement remotes.
- When Touch controllers wake up from idle, they might move erratically for a couple of seconds before tracking is reestablished.
- If you bypass the shim and communicate with the DLL directly, without specifying a version to ovr_Initialize, the DLL has no way of knowing the SDK version with which the application was built. This can result in unpredictable or erratic behavior which might cause the application to crash.
- There are some USB chipsets that do not meet the USB 3.0 specification and are incompatible with the Oculus Rift sensor. If you receive a notification in Oculus Home or the Oculus App, plug the sensor into a different USB 3.0 port (blue). If none of the USB 3.0 ports work, plug the sensor into a USB 2.0 port (black).
- Antivirus software, such a McAfee, can cause installation issues. To work around the issue, make sure you have the latest updates and disable real-time scanning.
- If you encounter installation issues, delete the Oculus folder and install the software again.
- If the Rift displays a message that instructs you to take off the headset, remove it and place it on a flat surface for 10-15 seconds.
- The keyboard and mouse do not work in Oculus Home. To select an item, gaze at it and select it using the Oculus Remote or Xbox controller.
- Bandwidth-intensive USB devices, such as web cams and high-end audio interfaces, might not work when using the Rift. To work around this issue, install the device on another USB host controller or a separate computer.
- For dual-boot systems using DK2 or CB1 HMDs, the OS selection screen might appear on the HMD instead of the monitor. To work around this, try plugging the HMD into a different port or unplug the HMD while booting.
- If you are running your application from the Unity Editor and you press the controller's home button to return to Oculus Home, you will be prompted to close the application. If you select OK, Unity might remain in a state where it is running, but will never get focus. To work around this, restart Unity.
12 Replies
- I used Oculuswrap but with this update Initialize return Libversion error ?
- Does ATW work when moving around with the touch controllers?
- Please include the Tools folder that you included for Version 1.5 SDK - we still need the OculusDebugTool - not all games have support for the Pixel Density Override setting
cybereality said:- If you bypass the shim and communicate with the DLL directly, without specifying a version to ovr_Initialize, the DLL has no way of knowing the SDK version with which the application was built. This can result in unpredictable or erratic behavior which might cause the application to crash.
What's "the shim"? Is the code for the shim available? In the pyovr python bindings I found I now need to pass an ovrInitParams argument to ovr_Initialize(), otherwise I get the Libversion error reported by etick:
etick said:
I used Oculuswrap but with this update Initialize return Libversion error ?
I'd like to reproduce the exact behavior of the shim, whatever that is, in pyovr if possible. For now I'm just guessing.
By the way, I also found that this is one case where calling ovr_GetLastErrorInfo() causes an error of it's own.
cybereality said:- If you bypass the shim and communicate with the DLL directly, without specifying a version to ovr_Initialize, the DLL has no way of knowing the SDK version with which the application was built. This can result in unpredictable or erratic behavior which might cause the application to crash.
What's "the shim"? Is the code for the shim available? In the pyovr python bindings I found I now need to pass an ovrInitParams argument to ovr_Initialize(), otherwise I get the Libversion error reported by etick:
etick said:
I used Oculuswrap but with this update Initialize return Libversion error ?
I'd like to reproduce the exact behavior of the shim, whatever that is, in pyovr if possible. For now I'm just guessing.
By the way, I also found that this is one case where calling ovr_GetLastErrorInfo() causes an error of it's own.- Does this only work with Touch? After trying out for hours given the information in the pcsdk link above I suspect it does. A heads-up notice would have been nice. All the available documentation make it sound as if this is actually available now. From a technical perspective, hard-linking the guardian system to Touch make absolutely no sense.
- If you are using Oculuswrap, you need to set the RequestedMinorVersion and Flags in InitParams - for example:var initializationParameters = new OVRTypes.InitParams();initializationParameters.Flags = OVRTypes.InitFlags.RequestVersion;initializationParameters.RequestedMinorVersion = 8; // this refers to 1.8// Then you can call Initializebool success = _wrap.Initialize(initializationParameters);
- Many thanks for the tip. I do not use Oculuswarp, but calling the oculus SDK directly has a similar initialization feature. I used to provide nullptr to get default values. That seemed to be fine until now. Will try this later today.
Obviously Cybers 3rd known issue remark is exactly about that. I didn't realize until now I am 'bypassing the shim' :smiley: - Black smear is back in Elite Dangerous since this update !
- Yeah, I just noticed that this afternoon. I looked down at the floor of my Python and thought "wait, that's black smear, I can't remember the last time I saw that".
If the solution for red glow causes black smear, I'd prefer the red glow, it was way less annoying for me.
whitav8 said:
Please include the Tools folder that you included for Version 1.5 SDK - we still need the OculusDebugTool - not all games have support for the Pixel Density Override setting
The tools directory with the debug tool is still there in 1.8.
lamour42 said:
Does this only work with Touch? After trying out for hours given the information in the pcsdk link above I suspect it does. A heads-up notice would have been nice. All the available documentation make it sound as if this is actually available now. From a technical perspective, hard-linking the guardian system to Touch make absolutely no sense.
It does appear this way.
The guardian area is set up using touch controllers (to define the boundary shape).
There's a registry key to force a default boundary for debugging: BoundaySystemDevAlpha in [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Oculus VR, LLC\Oculus]. Yes, it's Bounday, the docs don't have a spelling error, the oculus service searches for BoundaySystemDevAlpha (I watched it with Procmon).
But it doesn't appear to work, possibly because I don't have touch.
The oculus world sample has boundary support, but is set up to only display it if you turn it on using a touch controller. I edited the code to use the oculus remote instead. Calling ovr_RequestBoundaryVisible returns success, but immediately calling ovr_GetBoundaryVisible says the current state of the boundary is -52.
The call to ovr_GetBoundaryGeometry says the number of points in the geometry is 0.
So at the moment even with BoundaySystemDevAlpha set, the boundary system won't start without a touch controller.
