Closed AndrewTHEManeri closed 5 years ago
FYI - there's a change in the mix from Harald Nielsen to assembly definition files that may allow optional dependencies. Until then, we'll need to figure out a solution for our partner SDKs (i.e. Vive and Oculus).
@amirebrahimi I'm getting errors about missing the SteamVR assembly and OVR Assembly. Did you make those manually or are they in updated libraries somewhere?
Yeah, those assembly definition files were created manually. I can send them to you if you like. Still need to think about how to patch those SDKs.
Yeah, send the files over. Maybe we could do something like a combination of the serialized object references and CCU? Determine if an assembly is present, and if so, copy the assembly file into that folder
Use 7z.exe x -oAssets partner-sdk-asmdefs.zip
to overlay files over existing directory structure. This assumes that your zip is in the root of your unity project folder and that the OVR and SteamVR SDKs have not been moved from the original installation.
I am getting another error: Assets/EditorVR/Scripts/Core/VRView.cs(466,24): error CS0122: `OVRPlugin' is inaccessible due to its protection level
Is your version of OVRPlugin not set to internal? Or should the asmdef allow us to access internal entries?
@AndrewTHEManeri - You're right. I forgot that I also added AssemblyInfo.cs to OVR:
[assembly: InternalsVisibleTo("EXR")]
@amirebrahimi I'm wondering what version of OVR you used during your work on play-mode? AFAIK, only older versions of OVR still have a folder hierarchy similar to that which is contained in "the partner-sdk-asmdefs.zip"?
@amirebrahimi I'm wondering what version of OVR you used during your work on play-mode? AFAIK, only older versions of OVR still have a folder hierarchy similar to that which is contained in "the partner-sdk-asmdefs.zip"?
@dunity - When I go to Tools->Oculus->Update plugin it says 1.22.0. The last zip file I have on disk for OVR Utilities is 1.15.0 though. Did they switch their folders around?
A few updates:
@mtschoen-unity - Lemme know how those revert changes go and then I'll approve.
I'd say this is good to go at this point. I've been able to use all workspaces and tools in Edit Mode, a subset of workspaces in Play Mode, and the MiniWorld Workspace and tools in a built player. I haven't tested all actions in the player but we can refine individual functionality in smaller PRs. I have made tasks for a few remaining cleanup items.
The asmdef fix works out pretty nicely. EXR won't compile on first import, but all you have to do is immediately import the asmdef package and you're good to go. We can even include the asmdefs in the release package to avoid this issue for users of the package. The issue will also go away in 2019.1, where missing references are simply ignored and compilation can continue. I've updated the readme to explain this.
There is one minor issue where the EXR object (the one w/ the EditingContextManager) in the open scene gets destroyed right before you enter Play Mode. I think there is some code in the EXR lifecycle that destroys the ECM, but I don't want to get rid of it now in case we end up leaking them or something. I have created a task to investigate and fix this issue. This does not affect Edit Mode.
Some things I encountered and fixed during testing:
1b360f2
deletes a bunch of .fbx files.EditorOnlyWorkspaceAttribute
to mark workspaces that we don't want available in Play Mode. Eventually we can probably let contexts handle this.
Purpose of this PR
Enables EditorVR support in play-mode, applies assembly definition files for all submodules.
Testing status
That's what we're doing here. Let's be thorough.
Technical risk
High - the 'editor only' assumption of EXR is going away and we need to be very vigilant looking for unintended side-effects.
Comments to reviewers
Let's see what kind of velocity we have with all-eyes on everything. If we're not making much progress we might do a divide-and-conquer approach instead.