SDK v0.4 Discussion

"excelynx" wrote:

"DarkAkuma" wrote:
I'm getting this too.

Haha, I'm just glad it wasn't me doing something derpy again. :P

I'm also getting weird behaviour with lightning and shadows. It's almost like when shadows are enabled the normals are flipped or something - like the lighting is coming from the opposite direction, or there are shadows where there should be light. I'm using Deferred Lighting in Linear Color Space. That's in my own project, but I'll go ahead and do some tests in Tuscany too.

Im getting this exact issue... the mapping co-ordinates of shadows is messed.

Have you made any progress?


John

"KatsuomiK" wrote:
Hi, I was also having the blank Game View.
Setting the aspect ratio of the Game View "Free Aspect" might solve the problem :)

Wow! ^^^^ This!

That did it for me! Suddenly I can test my changes properly again! Thanks! =)

"DarkAkuma" wrote:

"KatsuomiK" wrote:
Hi, I was also having the blank Game View.
Setting the aspect ratio of the Game View "Free Aspect" might solve the problem :)

Wow! ^^^^ This!

That did it for me! Suddenly I can test my changes properly again! Thanks! =)

That fixed the Game View issue for me too! It also works on my main screen without having to drag the window over or anything. Thanks KatsuomiK! :) This needs to go into the documentation.

There's still other issues, but at least I can preview in Unity now!

"digital" wrote:

Im getting this exact issue... the mapping co-ordinates of shadows is messed.

Have you made any progress?

John

No luck thus far. :( I get the feeling this might be the sort of thing that we can't fix without Oculus' help.

Here's a couple of screenshots to illustrate what it looks like:

Forward


Deferred


This is a super simple scene from exactly the same angle, a plane, a light, a sphere and a OVRPlayerController dragged straight from the prefab.

"DonWhitaker" wrote:
My project no longer offers the display resolution and quality requester on launch. These options are also now locked-down in the editor. I suppose the resolution is known on the Rift so that makes sense, but it also takes away the ability for people to change key bindings if you are using the standard Unity Input events. Also no easy access to the graphics quality settings.

This is actually mentioned in the documentation:

4.4.1 Targeting a Display
To run your application on the Rift in full-screen mode, use the AppName DirectToRift.exe
file located next to your standard binary. It works in direct and extended modes. You should
include both of these files and the AppName Data folder when publishing builds.
To enable Rift support, the internal OVRShimLoader script forces your builds to 1920x1080 full-
screen resolution and suppresses Unity’s start-up splash screen by default. You can still access it
and change the settings when running your plain executable (AppName.exe) by holding the
ALT key immediately after launch. To disable this behavior, navigate to Edit  Preferences... 
Oculus VR and uncheck the ”Optimize Builds for Rift” box.

4.4.1 Targeting a Display
To run your application on the Rift in full-screen mode, use the AppName DirectToRift.exe
file located next to your standard binary. It works in direct and extended modes. You should
include both of these files and the AppName Data folder when publishing builds.
To enable Rift support, the internal OVRShimLoader script forces your builds to 1920x1080 full-
screen resolution and suppresses Unity’s start-up splash screen by default. You can still access it
and change the settings when running your plain executable (AppName.exe) by holding the
ALT key immediately after launch. To disable this behavior, navigate to Edit  Preferences... 
Oculus VR and uncheck the ”Optimize Builds for Rift” box.

THANK you. That's a big help!

"excelynx" wrote:

"digital" wrote:

Im getting this exact issue... the mapping co-ordinates of shadows is messed.

Have you made any progress?

John

No luck thus far. :( I get the feeling this might be the sort of thing that we can't fix without Oculus' help.

Here's a couple of screenshots to illustrate what it looks like:

Forward


Deferred


This is a super simple scene from exactly the same angle, a plane, a light, a sphere and a OVRPlayerController dragged straight from the prefab.

Aww man... I have a demo tomorrow... and really dont want to roll back to the 0.2.x SDK.

Oculus? Any thoughts? was this a know bug?

Thanks

"digital" wrote:
was this a know bug?

At the very least it's not listed as known in either the changelog or the documentation.

What's funny is that "Fixed issues with viewport management, deferred rendering, and linear lighting." is listed as one of the changes for Unity. Perhaps that didn't end up making this beta build or something?

Does anyone have any ideas if there's a correct way to disable and re-enable the OVRPlayerController/OVRCameraController in 0.4 and what it might be?

I have a regular default camera for non-Rift users and I used to just be able to essentially do "ovrPlayerController.gameObject.SetActive(riftEnabled)" and enable the default camera to switch between the two and it worked perfectly. Now if I do that and disable the OVRPlayerController and re-enable it in the editor, it appears to have stopped updating and doesn't render again, I just end up with the last frame rendered by the default camera.

Any ideas?

Edit: It also looks like I'm getting a hard freeze in the built standalone player if I try and set the OVRPlayerController to inactive. This doesn't happen in the Unity editor.

Weird. If I alt-tab after the freeze and then go back into the app after a short reloading pause it'll correctly bring up the default camera. I wonder if it has something to do with the Rift "capturing" the display, or something to do with the new runtime. Maybe alt-tab means the context gets released and Unity can recreate it correctly upon returning to the app.

Once that happens, if I then try and re-enable the OVRPlayerController I get a hard crash with this log:

(0x773E13A8) (kernel32): (filename not available): GetConsoleMode + 0x80
(0x131B66E6) (OculusPlugin): (filename not available): ovrHmd_GetLatencyTestResult + 0x1556
(0x131B422B) (OculusPlugin): (filename not available): ovrHmd_GetFrameTiming + 0x4b
(0x04540A38) (Mono JIT code): (filename not available): (wrapper managed-to-native) OVR.Hmd:ovrHmd_GetFrameTiming (intptr,uint) + 0x30 (04540A08 04540A6A) [00E84E70 - Unity Root Domain] + 0x0
(0x04540977) (Mono JIT code): (filename not available): OVR.Hmd:GetFrameTiming (uint) + 0x1f (04540958 045409ED) [00E84E70 - Unity Root Domain] + 0x0
(0x04540922) (Mono JIT code): (filename not available): OVRDevice:GetScanoutTime (int) + 0x4a (045408D8 04540939) [00E84E70 - Unity Root Domain] + 0x0
(0x04540898) (Mono JIT code): (filename not available): OVRCameraController:GetRenderTime () + 0x28 (04540870 045408C7) [00E84E70 - Unity Root Domain] + 0x0
(0x0453F9CF) (Mono JIT code): (filename not available): OVRCamera:SetCameraOrientation () + 0x327 (0453F6A8 045406B8) [00E84E70 - Unity Root Domain] + 0x0
(0x0453F615) (Mono JIT code): (filename not available): OVRCamera:OnPreCull () + 0x55 (0453F5C0 0453F641) [00E84E70 - Unity Root Domain] + 0x0
(0x044CE629) (Mono JIT code): (filename not available): (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) + 0x41 (044CE5E8 044CE67D) [00E84E70 - Unity Root Domain] + 0x0
(0x100F00B6) (mono): (filename not available): mono_set_defaults + 0x22bf
(0x1005D6DF) (mono): (filename not available): mono_runtime_invoke + 0x51

The OVRCameraController forces Forward rendering at runtime. Click play and select it, and you'll see the problem.
This is the shadow issue. If anyone can figure out a fix I would appreciate it. Technolust is also deferred.