Client kit render params #71
Conversation
…ntKitRenderParams
…tionality, like setting EyePose.
…lity, like setting HeadPose.
…r heads, eyes, and surfaces.
…e were getting an unpredictable eye count.
….Bottom works where Unity expects "top".
…ead, along with EndOfFrame coroutine.
…SetupDisplay() from Start(), although it probably won't succeed in Start.
There was a problem hiding this comment.
This is the guts of the new implementation. Would like a review here. Do we also need to do anything in VRSurface::OnPreRender(), or will this suffice?
|
Still need to update demo scenes, prefabs, and maybe some cleanup. Can VRDisplayTracked prefabs go away? |
…layController" but it's the same prefab. Removed test scene displayController.unity and DisplayController prefab.
There was a problem hiding this comment.
Do we want to let the developer set IPD through the inspector here? Usually would be part of a user profile, but a developer might want to modify this temporarily for artistic effect. If not here, where?
There was a problem hiding this comment.
Nowhere - this is part of the problem with the existing solution. Simulator sickness is not an artistic effect.
There was a problem hiding this comment.
and actually, isn't there already a control in the camera component for the near and far plane? No need to duplicate, just use those - they're the only settings from the camera we'll not override.
There was a problem hiding this comment.
There's no longer a camera component in the scene, it gets created at runtime and initialized with these variables.
There was a problem hiding this comment.
Asked about IPD because Cardboard allows FOV to be changed for special effect: https://github.com/googlesamples/cardboard-unity/blob/91bdb1c00ac35e14f0f403bc4ede49670dad8008/Cardboard/Scripts/StereoController.cs#L76
Could be used in a game if the player could change size (would a smaller IPD make everything look bigger?). Agreed that it shouldn't really be tampered with in most cases.
There was a problem hiding this comment.
You change size by adjusting the room-to-world matrix and doing a scale change there. Everything in room space needs to stay the same for consistent viewing.
…amelcase, for consistency.
…play descriptors is no longer necessary in Unity, that data is in ClientKit.
…ainCamera". This will be our dummy MainCamera instead of creating one at runtime on a Viewer. This forces us to move our EndOfFrame corotuine and OnPreCull() to DisplayController.cs, rather than VRViewer.cs. This is a better move anyway.
… CreateSurfaces functions.
… OnPreCull and EndOfFrame coroutines. Added array of VREyes to VRViewer, and UpdateEyes function.
|
Added a lot of comments and made some structural changes towards supporting multiple viewers and surfaces, but still ensuring there is only 1 of each right now. This involved moving our main "stereo rendering update loop" (OnPreCull and EndOfFrame coroutine) to DisplayController rather than having these in VRViewer. DisplayController now owns the dummy camera. The properties of this camera are copied to each VRSurface camera. I made a todo for copying any other effects that may be attached to the dummy camera that a developer might want attached to each surface camera. The client is currently being updated before each GetViewerPose() and before each GetViewerEyePose(), as well as in ClientKit::Update() and ClientKit::LateUpdate(). |
|
Exception being thrown when getting viewer or eye pose but no HMD is connected. Put this in a try/catch? Error message: InvalidOperationException: [OSVR] DisplayConfig.GetViewerEyePose(): native osvrClientGetViewerPose call failed. |
… has received its first pose. This fixes the error when no HMD is connected.
|
The error above has been fixed with latest commit. Just need confirmation that this doesn't introduce ghosting/lag before merging. Unable to test with HDK. |
Conflicts: OSVR-Unity/Assets/OSVRUnity/src/VREye.cs OSVR-Unity/Assets/OSVRUnity/src/VRHead.cs
Unity now retrieves the output of the computational display model from the OSVR-Core API
Setting up rendering from new ClientKit functionality. No longer parsing display config in Unity. This implementation assumes exactly one viewer and one surface per eye. Latency feels a little high. This isn't ready for a merge, but would like a review/comments.
The example scene is displayController.unity