Up and Coming

Getting rid of health and safety warning

261 replies
65444 views

What is the proper way to get rid of the health and safety warning in Unity?
In OVRDevice.cs, I tired commenting out this:


if (HMD != null && Input.anyKeyDown && HMD.GetHSWDisplayState().Displayed)
	HMD.DismissHSWDisplay();

and adding this to the end of Awake():


HMD.DismissHSWDisplay();

But that only works in the Editor but in the standalone version the head tracking stops working and the warning is not removed.

Show previous replies

S

spyro

Up and Coming

IHMO it's annoying as hell, even after this short time.

spyro

J

jherico

Inspiring

"fungus" wrote:
"mbzdmvp" wrote:
As a developer I now have to build my app every time I need to test it, and seeing that warning every time has become extremely frustrating. Especially when I only need to run my app for 30 seconds.

This.

There's no way a developer should have to sit through it 1000 times per day....

If you're working directly against the SDK you can disable it programatically. Indeed I had to do this because in 0.4.0 they weren't using VAO's and my OpenGL version requires them. You should probably make sure any changes involving disabling the warning are ifdef'd within debug only macro definitions, so that your release builds still contain the warning. Or alternatively you could have the SDK check for a config file or registry setting to disable the warning.

If you're working with Unity or Unreal, I'm not sure there's an easy way to do this.

Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

2

2EyeGuy

Up and Coming

"usb420" wrote:
It's good that there's a warning screen. The other day I started developing an eye problem. I'm not blaming the rift but I suspect it has to do with having a bright screen too close to my eyes. I think it caused a blood vessel to burst in my retina and I was seeing a spot (in real life) that wouldn't go away.

Thankfully it's clearing up a bit after a few days but for while it was a little bit scary.
Needless to say I will not be putting screens this close to my face anymore.

Pretty sure Its not because I'm a dumb American this can happen to anybody.

That seems unlikely to be the cause.

Currently working on Dolphin VR Follow along: https://github.com/CarlKenner/dolphin/commits/VR-Hydra Latest Version: viewtopic.php?f=42&t=11241&start=1020#p249426

N

n00854180t

Up and Coming

FYI I just went to go try and call ovrhmd_EnableHSWDisplaySDKRender as part of building in support for it in Unreal Engine 4 as part of the command line functions, and the function is not there.

I don't think it's exposed anymore - all you get is the basic dismiss call and the get state call. So even if you are using the SDK you're going to have a hard time setting this up properly now (this is with the 0.4.1 SDK).

Using the basic dismiss call won't dismiss it immediately since it has that check for forcing you to view it for a certain amount of time.

Now I just want ovrhmd_EnableHSWDisplaySDKRender back.

Twitter IndieDB

M

Mattiwatti

Participant

Here's how I disabled the warning in UE4, using the repository at https://github.com/Oculus-VR/UnrealEngine:

1. Grab a fresh copy of the SDK from the Oculus site.
2. Open the .sln file in OculusSDK/Samples.
3. Open CAPI/CAPI_HSWDisplay.cpp and change #define HSWDISPLAY_DEFAULT_ENABLED 1 to #define HSWDISPLAY_DEFAULT_ENABLED 0.
4. Set the build configuration to Release x64 and build the project, then close Visual Studio.
5. Rename the OculusSDK/LibOVR folder to LibOVR_04.
6. Copy the LibOVR_04 folder to Engine/Source/ThirdParty/Oculus in your UE4 engine directory, overwriting existing files.
7. Build the UE4 engine project as normal.

Note that this is only for Windows and VS, I don't have access to other build environments to try this but you might be able to do something similar.

The (seemingly more sane) way suggested by PathogenDavid of calling ovrhmd_EnableHSWDisplaySDKRender didn't work for me, but perhaps I'm not calling it in the right place (I put it in FOculusRiftHMD::Startup()).

I'll have to agree with the other posters that this warning is really unnecessary. It annoyed me so much that I resorted to the above procedure just to get rid of it, and that's only after two days! The worst part is that the warning doesn't actually go away after pressing a key unless a certain amount of time has passed. This is bad UI design because you're not keeping your promise to the user ('press a key to make this screen go away'), and generally unnecessary because the warning always shows the same text. I know what it said after the first time reading it, and I have the memory capacity of a goldfish.

I will admit that the screen is probably extra annoying for us developers, but as a user I definitely wouldn't be happy with it either. What's wrong with putting it in the manual, where similar warnings ('don't put your dog in this microwave') go for other products?

Edit: Updated instructions for SDK 0.4.x.

N

nn23

Up and Coming

"spyro" wrote:
IHMO it's annoying as hell, even after this short time.

spyro

q.f.t.

N

n00854180t

Up and Coming

"Mattiwatti" wrote:
Here's how I disabled the warning in UE4, using the repository at https://github.com/Oculus-VR/UnrealEngine:

1. Grab a fresh copy of the SDK from the Oculus site.
2. Open the .sln file in OculusSDK/Samples.
3. Open CAPI/CAPI_HSWDisplay.cpp and change #define HSWDISPLAY_DEFAULT_ENABLED 1 to #define HSWDISPLAY_DEFAULT_ENABLED 0.
4. Build the project.
5. Copy the OculusSDK/LibOVR folder to Engine/Source/ThirdParty/Oculus in your UE4 engine directory, overwriting existing files.
6. Build the UE4 engine project as normal.

Note that this is only for Windows and VS, I don't have access to other build environments to try this but you might be able to do something similar.

Nice work! Thanks :)

The (seemingly more sane) way suggested by PathogenDavid of calling ovrhmd_EnableHSWDisplaySDKRender didn't work for me, but perhaps I'm not calling it in the right place (I put it in FOculusRiftHMD::Startup()).

I couldn't actually find it exposed anywhere (a search of all the code showed no results). Is it indeed still there?

I'll have to agree with the other posters that this warning is really unnecessary. It annoyed me so much that I resorted to the above procedure just to get rid of it, and that's only after two days! The worst part is that the warning doesn't actually go away after pressing a key unless a certain amount of time has passed. This is bad UI design because you're not keeping your promise to the user ('press a key to make this screen go away'), and generally unnecessary because the warning always shows the same text. I know what it said after the first time reading it, and I have the memory capacity of a goldfish.

Totally agreed. I feel it's not implemented well at all, either in UI design practices, or best practices for VR UI.

I will admit that the screen is probably extra annoying for us developers, but as a user I definitely wouldn't be happy with it either. What's wrong with putting it in the manual, where similar warnings ('don't put your dog in this microwave') go for other products?

Exactly. There's no way that consumers will be putting up with the way the warning is set up now.

It should be on a sticker over the lenses or something (to appease the lawyers that people have to read it), and/or played *one time only* when the game is started, and never again. It should also be in-scene (instead of plastered on the screen at infinity/zero depth) and go away when the user presses a button, regardless of displayed time.

And as far as the one displayed in game, that should be completely controllable by the developer, because even if the current message is greatly improved upon in terms of UI design etc., it will never match every developers' needs for such a thing.

Twitter IndieDB

M

Mattiwatti

Participant

"n00854180t" wrote:
I couldn't actually find it exposed anywhere (a search of all the code showed no results). Is it indeed still there?

Ah, this might be because I had to copy the SDK files over to get the engine project to build in the first place. If you build the SDK and copy it over like in step 5, you should be able to #include "../Src/CAPI/CAPI_HSWDisplay.h" and call the function. Visual Studio doesn't actually see the file on my system and complains that it can't find it, but the project compiles fine. I'm guessing this is due to the Unreal build tool handling the include paths and such.

N

n00854180t

Up and Coming

"Mattiwatti" wrote:
"n00854180t" wrote:
I couldn't actually find it exposed anywhere (a search of all the code showed no results). Is it indeed still there?

Ah, this might be because I had to copy the SDK files over to get the engine project to build in the first place. If you build the SDK and copy it over like in step 5, you should be able to #include "../Src/CAPI/CAPI_HSWDisplay.h" and call the function. Visual Studio doesn't actually see the file on my system and complains that it can't find it, but the project compiles fine. I'm guessing this is due to the Unreal build tool handling the include paths and such.

Ahhhh yes, that would make sense. Thanks.

I'll probably just use your method, since you mentioned the function did work for you (otherwise I would have added it to the console commands available).

Twitter IndieDB

P

PathogenDavid

Participant

"Mattiwatti" wrote:
The (seemingly more sane) way suggested by PathogenDavid of calling ovrhmd_EnableHSWDisplaySDKRender didn't work for me, but perhaps I'm not calling it in the right place (I put it in FOculusRiftHMD::Startup()).

Yeah, it is pretty picky where you call it. If you call it to early, it gets reset at some point. IIRC, it has to happen after render configuration happens (since it has to know what API to use to load all the HSW resources with.)

Show more replies

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO