Feedback from user:
Most of the movement system seemed to focus on X/Y movement which made it hard as I like to use a lot Z Movement when moving around. The teleportation system worked however teleportation is not very precise/immersive. I found it very useful to cross long distances but again it was only on the X/Y Plane. If the Teleporter was directional rather than a typical arc teleporter I think I would find it more useful. That way I could teleport up and Down by pointing in that direction.
There is a movement system on the asset store we use quite a bit for navigating around in 3D space. The Rubber band movement works like a 3D Joystick allowing control your velocity quite precisely. They also have a flight system that uses the rotation of the controller to move around. I would take a look at it to see what you think.

I get a different selection level in the hierarchy depending on whether I use direct selection versus raycast selection. One of the screenshots shows direct selection of the right front wheel of GreenTank1, which results in the GreenTank1 prefab being selected as shown in the Hierarchy view. In the EditorVR window you can see that GreenTank2 is not selected.

I de-selected, then used raycast selection on the same wheem of the same tank. As shown in the other screenshot, this results in the GreenTanks transform being selected in the Hierarchy view, and the EditorVR window shows that GreenTank2 is selected.

See the attached screen shots. In EditorVR if I use raycast selection to select PurpleCube it actually selects PurpleArmy which is two layers up in the hierarchy. But if I raycast select a GreenTank it selects GreenTanks which is only one layer up in the hierachy. Selecting a BrownTank gets BrownTanks, also one level up.

Does the hierachy level which is selected via raycast depend on whether or not the hierarchy contains prefabs versus only non-perfab GameObjects?

Having to rotate your wrist to point down onto a flat plane takes more work and is not likely how your wrists are positioned when you've launched a workspace. This also came as feedback from a developer on Quill.

EditorVR.Tools.cs filters all tools that are ILocomotors as being permanent tools.

This is done at line 42 as follows:

bool IsPermanentTool(Type type) { return typeof(ITransformer).IsAssignableFrom(type) || typeof(SelectionTool).IsAssignableFrom(type) || typeof(ILocomotor).IsAssignableFrom(type) || typeof(VacuumTool).IsAssignableFrom(type); }

This is very likely a mistake. You probably meant to explicity filter BlinkLocomotor and your other permanent locomotion tools.

The behavior of the code as you have it above, filters out my tool from showing up on menus, because the system believes all ILocomotor tools are permanent. Which they're not. It's perfectly reasonable for me to create a special locomotion tool that I want to be activated from the menu.

There are two cases when the HMD turn off (with SteamVR, it switch to Compositing mode).
1- When Unity lose focus
2- When a context-menu in Unity are opened. (to reproduce: click on Unity->File menu)

I don't know if are issues that can be fixed in Unity itself or in EditorVR asset with some workaround.
About the 1), "Player-Settings -> Run in background" allow to retain HMD on when lose focus, but works only in Play Mode.
About the 2), it seem related to Windows native menu, because for example the "Add component" submenu don't reproduce the issue.

Paste is at head position, since normals are outward, you don't see it at first time.
Paste (or clone) should be "in place" and de facto selected so we can move it from the same position.

hey all, congrats on the release!

Took me a while to find the associated blog post: https://blogs.unity3d.com/2016/12/15/editorvr-experimental-build-available-today/

Would be nice to include those details in a readme file in case other people find this repo first.

• Make semi transparent when menu is not being interacted with via ray or analog
• Reduce overall size
• Center around the bottom/back of the radial menu region; buttons shouldn't populate from the top down along the left side, but from the bottom center outward (less important, but would present better)
• Make semitransparent when objects are direct selected
• If user interacts with menu while direct selecting, radial menu regains typical transparency

Fixed with #50

Originally when we were discussing EditorVR design we knew that we'd want to experiment with every part of the system from menus, UIs, tools, etc. One idea we had at the time is that a group of these might be a complete package from a developer. So, the developer might have the need to re-skin all of EditorVR. This isn't entirely what @leith-bartrich is alluding to in #48, but it has parts of it.

So, details need to be flushed out about what a context encompasses. I suppose without a context that you'd be in VR staring at an empty scene with possibly controllers, but nothing else -- no menus, no tools, no workspaces, etc. It begs the question, what is the UX for switching contexts?

Aside from that, there would still need to be a default context at startup as some people are coming to EditorVR as a user with not much Unity knowledge and not as a developer who is looking to build tools or a custom VR editing environment. So, it would be a non-starter if a user had to code something or wire up some settings in a ScriptableObject on disk or a menu somewhere.

Opening this up for comments.

Here's what I found:
I can build a wall by starting a freeform cuboid with one hand and slide (touchpad) to another location with the other, very convenient!

But I can also select an axis to slide an object with one hand and, at the same time, select the clone in the menu (rotating thumb on the Vive touchpad) with other hand, but it does nothing.
It should equal "clone it and move the copy" (like sketchup ctrl+move).

It opens a whole world of natural interactions!

Heres a screenshot where left hand select menu while right hand is on blue axis to move pillar:

I have a plane in my scene. In the MiniWorld workspace the plane has a flickering effect as shown in the attached screen shot. This is not a big problem but it is a bit distracting.

The flickering is probably due to highlighting that occurs when the selection ray from one of the hand controllers intersects with the non-MiniWorld plane.

This is the first place where we will add the ability to create an empty Gameobject/Transform.

Once a ray is intersecting with a workspace that has an EditorWindow (see #11) forward any button presses as mouse clicks.

In the Unity Editor if I copy-and-paste (or duplicate) a prefab in my scene, the new copy is also a prefab. But in EditorVR if I select a prefab then use copy-and-paste or duplicate via the radial menu, then the new copy is an hierarchy of game objects rather than a prefab.

In the attached screen shot the Hierarchy shows several Tank prefabs. In EditorVR I selected one of these and used the Duplicate button via radial menu. Then I selected the prefab again and pressed Copy on the radial menu, following by Paste. These operations generated Tank(Clone) and Tank(Clone)(Clone) which are not prefabs. Rather, they are hierarchies of primitive objects. (Prefabs are blue in Hierarchy.)

The attached video illustrates a way to break EditorVR easily, as a user, by deleting the Input Manager.

But I think it illustrates the peril in using fairly unprotected scene objects as the editor itself.

While it's probably trivial to filter the object I used to illustrate, from the VR Hierarchy workspace, it is not filtered from the main Unity UI or 3rd party systems and tools. I'd think there should be some thought put into how to protect this class of object in a more comprehensive manner.

https://www.youtube.com/watch?v=AehOh1Db4dY

Similar to EditorUtility.SetSelectedWireframeHidden in the Editor.

The use being custom highlighting schemes. In my case I want to highlight the mesh triangles and vertices that are being hovered, but not the object as a whole.

As suggested by Amir here a workaround in the current state is to simply inherit ISetHighlight and manually disable the highlight per-object.

Adjust colliders to match the frame geometry, so that they can be grabbed easily for resizing instead of having to dip in the area around the workspace.

Will be added as a button on the front of the hierarchy workspace

It is difficult to select small objects in MiniWorld. For example if I zoom out in MiniWorld to see a large portion of my scene and/or to work with large assets, it becomes difficult or impossible to select my MiniWorld avatar to move my position in the world.

If there could be a mechanism for automatically adjusting the collider sizes of objects in MiniWorld based on MiniWorld scale and the proximity of other objects, that could make the MiniWorld more usable for cases where the size gamut of objects in the scene is diverse.

The PrimitiveTool's visual style doesn't match that of the MainMenu. The appearance of this tool should match that of the established style defined by the MainMenu (shaders, frame geometry, etc).

This is to avoid accidental movement

For example, if I move an object in the 2D editor or with the manipulator, the values in the inspector do not update.

I'm not a lefty, but I do expect my software to work well for lefties.

I should not be restricted to hard-coding an input mapped control to a left or right VRInputDevice.

I should be able to map to "Dominant" and "Non-Dominant" hand as well.

I should be presented with: Any, Left, Right, Dominant and Non-Dominant at a minimum.

You should allow the user in the editor to set their handedness. And in runtime mode, I should be able to set the handedness of the player programmatically such that I can expose it to them via UI.

One would expect Dominant and Non-Dominant maps to switch devices based on a change to the handedness. But that Left and Right will remain the same regardless of the player's handedness.

While considering this I'd consider other likely future needs.

I'd consider that you're not really tracking a hand at all. In the future, we're likely to have a tracked (anatomical) hand and also a tracked controller in that hand as separate things. Hierarchy and nomenclature should reflect this likely expansion of capability.

I'd consider accessibility here. Especially since VR is being adopted in the medical field. The assumption that these are attached to hands, is probably not a good assumption. It should be explicitly defined in the map rather than assumed by the map. Even if current VR hardware and SDKs don't allow this just yet.

I'd consider tracked objects and controllers that do not correspond to anatomy or correspond to alternative anatomy. A tracked keyboard. A tracked keypad on the wrist. Etc.

Instead of dipping pointer into the front, use the grip button to move the workspace

Position and rotation seem to work fine though

Previously, we had these split across Tools, Workspaces, Actions, etc., but from our preferred dev usage we'd like to have someone have one simple using UnityEngine.Experimental.EditorVR.

Well I cannot see a project structure in this repo it seems like there is only contents of Assets folder has been committed. But since I see those .meta files is here I guess there's no problem so I imported into an empty project.

But soon I get 120 of missing assembly reference errors, does anyone have a chance to work it out ?

• Include marquee/lasso/sphere selection

And add the other actions to it when something is selected
Remove joystick/touchpad for selection

This has been tagged with concept because it requires more design work, but essentially it is the idea of having a way to store arbitrary objects in a scratch area.

Feedback from user:
The Popup Menus for the Inspector/Profiler/Project View, It was fantastic to have them however I found myself constantly moving them to get them out of my way. They would be better as a belt that I could access when needed. This would could like vanishing realms does their inventory system.
I however would go with something like an MMO hotbar. This hotbar has other uses such as easily accessing prefabs/scripts. If I could set this up before I go into VR I will not need to spend the time digging through the file structure of my project to find the one prefab I need. For example as the level designer my job is to setup all the trees. I can quick slot the 20 different trees rocks and shrubs which are all in different folders. I am using and easily place them without touching the project folder. Then move in to NPCs by either dragging them in from the VR Editor or exiting VR and using the mouse to select and move them. Same goes for applying a scripts and calling up inspectors having a hotbar means I can access things quickly. This bar might even be useful in the desktop editor.

When this feature was first implemented, the BlinkLocomotionTool was a two-handed tool, meaning that only one instance existed across both hands. Now that this is not the case, you can locomote with the opposite hand when an IExclusiveMode is active.

Selections can be made with the opposite hand, and while the TransformTool is deactivated, the manipulator doesn't go away when an IExclusiveTool is selected.

With the change to use ProcessInput, it's necessary to cast to Standard in order to make use of the standard action map, so more documentation is needed or possibly a different interface.

Like the 2D Hierarchy window, we should be able to drag and drop objects to change their order and parenting.

We need a way to verify that contributions don't break existing functionality. For starters, we will test:

1. Whether Unity can build VR-capable Players with EditorVR in the project
2. Whether a script compile succeeds when dependencies (partner SDKs) are missing
3. Whether the TagManager feature has correctly set up Tags and Layers

This will make it easier to close out the tool then having to use the main menu or active tool toggle.

Save the layout of workspaces and possibly even the user's location

This is throughout the rest of EVR (e.g. instantiation / deletion)

Feedback from user:
Scaling and Object selection worked fantastically. I was able to pick up and manipulate objects with ease. The 3D gizmos for selection took a little to get use to however it did not take me long to get the hang of it. It was quite an incredible feeling when you picked up a 3D object and you got to place it in the VR world. The idea of having a tip on the controller in which to pick objects works great; I do wish I had the ability however pull myself to an object for selecting sort of like the F Key works now.
Additionally I was unsure when I had picked an object the radial menu that appeared on the controller was helpful but the animation I think got in the way either speed it up or make it instant a visual change could also alter the controller visuals similar to how Oculus Medium changes when you pick a new tool.

We need a way of displaying tooltips throughout the system. A tooltip is a piece of text that will appear when a user hovers over a button. Tooltips will automatically rotate to face the camera, and appear at some position offset relative to the button.

This feature will consist of a ToolTip component which will show/hide the tooltip, and a ToolTipAttribute for specifying tooltip data on dynamically generated UIs.

Because our UI is a mixture of hand-made prefabs and dynamically generated content (i.e. "View All" button on workspaces vs. RadialMenuSlots), there will be two way of defining a Tooltip. On hand-made prefabs, the author will simply add a ToolTip component and set the positional offset as a Vector3 field in the inspector. For dynamically-generated UI, developers will add the ToolTipAttribute with the text string to be displayed. The code which generates these UIs will be modified to check for the ToolTipAttribute and, if present, add a ToolTip component and specify the proper offset based on contect. In this way, the Radial Menu can decide where its ToolTips go based on the position of the button, which could change.

This would allow you to create this workspace and switch between or select any other window in Unity potentially.

(This doesn't affect tool developers or public API)

First pass was #33.

For this pass, the current plan is to split out more of the partial classes to modules, add internal interfaces where needed for communication between modules and eventually get back to a single EditorVR.cs.

As far as a run-time stub, the idea is that we will derive from EditorVR and override any Editor specific parts.

Currently it's only possible to have 1:1 scale from the viewer's perspective. We have the MiniWorld to allow scaling the view of the scene for manipulation purposes. This feature would allow scaling the view of the world around you.

Instead of having them in Tools, Menus, Actions, etc.