Here’s what it’s supposed to look like, this is how it looks in the preview window:
Here’s how it looks in the built version:
When running in the Oculus Rift the lighting looks normal like in the top pic. I thought maybe it had something to do with the “Virtual Reality Supported” option in the player settings, but it works the same way whether or not that option is checked. Forward rendering path here.
Any ideas?
More info: This only happens in full screen mode and is the same regardless of forward/deferred rendering. When running in a window it looks correct.
More: If I run the Oculus rift build in full screen so its duplicated in full screen, the Rift display is correct while the duplicate on the monitor is dark. So basically it always looks right in the Rift, and it always looks wrong on the monitor if full screen is selected whether or not the Rift is present.
Hope that helps.
So, I just went to eat lunch and am now getting some weird rendering problems on the Rift. The left and right eyes flicker a lot. The left is on most of the time while the right only shows a little flash of something a few times per second with the exception of the stering wheel which is visible in the right eye 100% of the time. Very odd, no idea why it started happening just now.
At the same time this problem is happening, the health and safety image appears to be swapped between the left and right eyes. Not sure if this is down to the Oculus runtimes I just upgraded yesterday or the new Unity beta or what.
Could you test this with a new project and/or scene to see if the built player looks as drastically different as you showed above. If the built player looks the same with and without Virtual Reality Supported, I wouldn’t expect this to be and issue caused by the VR integration. If you can reproduce this easily in a new project, it would be best if you could file a bug report.
Just tried it with a new project and the problem did not occur. The duplicate view was correct in both windowed and full screen mode. Not sure what could be causing my previous project to do this. Maybe an errant, old file somewhere that should not be there in this new beta? Several of my other problems were caused by that, using the OVR stuff that shouldn’t be there, incorrect Oculus runtime, etc… That’s all cleaned up now though so I’m not sure what else might be there that shouldn’t be. Any ideas?
One thing I just realized when building a new project as you suggested is that there is no longer a _DirectToRift exe. I tried deleting that in my previous project and running the main exe directly hoping that might have been the problem (until now I have been running the _DirectToRift.exe) but it’s still the same. So maybe a note about that in the release notes would be a good idea in case it can cause problems. I also tried it in full screen on the main exe without the Rift and it’s still dark. That and I’m still getting the same flickering/partial rendering problems.
I haven’t been able to reproduce the darkened stuff in a new project, so at least you shouldn’t have to worry about that one with new projects.
I just tried a new scene in the old project and it’s still dark. This time though something interesting happened:
I’m running two monitors like I have been for all these tests. In this test the Rift was plugged in but turned off, 1920x1080 fullscreen mode (my monitors are 1920x1200 native). Left side of the screen is the left monitor, right side is the right. So it only went to fullscreen on one of the monitors by the looks of it. This is the first time this has happened, normally it goes to full screen across both monitors like it should.
EDIT: I just ran it four more times and it went full screen across both monitors like it should in every case (still dark though). So the split behavior shown in the pic would seem to be a rare occurrence.
Anyway, it’s still dark with a new scene, but only in the old project.
Think I might have just found something that might help: It is of course silly to run it in full screen mode at only part of the total resolution available. At the moment with two monitors plugged in if I run my boat project in full screen at 3840x1200 the way somebody would actually do it on regular monitors, the lighting is correct and there is no problem.
I guess the trouble with that is that if you want to run the duplicate-to-monitor stuff going on and have two monitors + Rift running, the full screen resolution has to drop to that of the Rift. So the duplicate on the monitors goes dark. As I said before though, this isn’t happening with a new project so it must be something I’ve missed in my original one. At the moment I have no idea what to even look for though.
Good news regarding flickering and rendering problems in the Rift: One of the Unity folks just replied to a bug report I sent on it saying they’ve been able to reproduce it and will work on it.
Fixed in beta 5 both with and without Rift. Good job, guys. You sure move quickly. 
Actually no, it just did the dark stuff again. Maybe it’s a sporadic thing.
I’m experiencing this in Unity 5.1.0f2 (64-bit)
@ Could you submit a bug report with your project and post the bug report number here. I have not seen this issue on my machine, but it may be something in the scene causing this.
Project is too massive for that. I tried to recreate the core parts of the project in a new project, but couldn’t replicate the issue in the new project. I’ll try again tomorrow
I created an abstracted sample Project which is quite small.
It actually (for me) only occurs in Deferred Linear Workflow when Screen-size (in Fullscreen-Mode) is set to a non native Resolution (means: supported but not recommended).
Works fine in Window-Mode.
Bug Report Number: 700776
Project without builds attached as zip.
Screenshots of Build (correct & incorrect):
Regards Michael
Thanks for submitting the bug report. I’ve sent it to our QA team to have them reproduce the issue and then we’ll look into a fix. I’ll continue checking back to this post and providing more information as we have it.
Doh! I forget to change to Deferred Linear in my test project. That’s definitely where the issue occurs. Thanks everyone!
