Using The EditorVR without VR - suggestions?

In the last couple of weeks I worked on tools for the EditorVR, and my main problem was, that it takes a long time to check changes on those tools.

When working on tools for the regular editor, it's just save the script file, wait a few seconds, and open the editor window, or check the inspector of a GameObject.

When working on tools for the EditorVR, it's save the script file, wait a few seconds, open EditorVR window, put the VR headset, and then select the tool or open the workspace, etc...

One of the "hacks" we do - is putting the VR headset on a tall chair, and using the controls in front of the headset, instead of wearing the headset and removing it again and again...
But it's not comfortable.

So - any suggestions for tricks/tips/tools in order to remove those uncomfortable tasks?

 

A few things that I thought of:
1. No VR mode - in which the EditorVR camera is controlled using the keyboard(right,left,up,down,forward,backward,turn left, turn right),
While we can still use the Vive controllers, Oculus Touch, or another controller that doesn't require a headset.

2. A preview mode for workspaces.
Something like - save the workspace script, wait for unity to load it, and in the regular editor click on a button to test how a specific workspace works(maybe add a sub-menu with all the workspaces available)

What do you think?

 

Well, until EditorVR is self-hosting (meaning that you can build EditorVR tools inside of EditorVR), we'll need to have stop gaps. You've identified one. We're needing this as well to help with creating more Editor Tests. Your #2 is something I hadn't considered. Would probably require a small stub that could host enough of EVR services that a workspace would need.

If this is something that you'd like to keep on our map, then please create a feature request on GH. Also open to contributions if you have something in mind already.

 

What do you think about that:
A method/function under workspace namespace that will let the developer to run the workspace out of the EditorVR.
So we won't add all the workspaces to the regular editor menu, but if a developer wants to test a workspace, he can create a regular menu item, and launch the workspace from there.

Something like CreateWorkspaceDelegate

 

There would still be the need for EditorVR to run at some level because if the workspace required any other services through the interfaces that exist something would need to service those. However, one feature that could help with testing is if the workspace state was restored each run of EditorVR, which is planned for 0.0.4.

Can you share more about the workspace that you are testing? Is it mainly the UI or is it direct interaction with your hands?

 

The main issue is working on the UI/looks of the workspace.
I think that if we'll have that, we can add our own ways to check interactions(keyboard/mouse) for testing

 

0.0.4 just moved to staging, which will at least allow you to keep workspaces open. You're also welcome to implement ISerializeWorkspace if you want to save the state of how it was, which might reduce some menu clicks. I'd be curious to see if this helps move testing forward quicker for you.

 

mate youre an inspiration

i went for the 'hanging from a lightglobe' approach

 

LOL, but it was an idea of someone else from the office.

I saw the SerializedPreferencesModule, and I saw that you have PayloadType and Payload.
But how can I add another Payload to my Workspace payload?
I want to add a string with info on the state of a specific workspace, and then use the string when DeserializePreferences is called.

Thanks

 

Just implement ISerializeWorkspace in your custom workspace and pass back an object for a class that has been marked serializable in OnSerializeWorkspace(). Then, you can cast that object back to your custom class in OnDeserializeWorkspace() and get out whatever you need.

 

Saw the example on ProjectWorkspace. Implemented it in our workspace. Works great. Thanks

 

And found some strange bug when setting the "Preserve Layout" to false. When I closed the EditorVR window, the EditorVR GameObjects staying on the scene. I need to check if this is because of my changes, or if it also happens on other projects

 

Found the bug:
On "EditorVR.cs", Line 247
m_HasDeserialized = true;
I replaced it with
m_HasDeserialized = preserveLayout;

The true value made error exception on EditorVR.Shutdown() when "Preserve Layout" is false

 

Another bug is when WorkspaceModule is trying to Deserialize an unknown type of workspaceLayout.
I added
if (Type.GetType(workspaceLayout.name) != null)
before
CreateWorkspace(Type.GetType(workspaceLayout.name), (workspace) => ...

 

Thank you, @De-Panther.

I created a fix here: https://github.com/Unity-Technologies/EditorVR/pull/154
Would you be willing to create GitHub issues for bugs you find? It's easier for us to track. You're also welcome to submit a PR if you like.