New Platform Readme

[NickAtAccuPS]

I'm trying to add another platform and the best resource I have at the moment is the git commit history. It would be very helpful to have a high level overview of files to modify to add controller functionality.

[andrewnakas]

Wow awesome that is really great to hear, which platform? The two scripts that handle actual painting are the dlineManager.cs and PinchDraw.cs on the controller left gameobject. The bulk of everything is handled by the canvas master scrips that are supposed to be singltons :), ie brushmanger, toolmanager, undo manager and settings manager. I use unity build compilation to sort out the current platforms. If you search the entire solution for something like #if UNITY_ANDROID you can find all the places you need to work with your input solution. Also you should copy the open brush tango scene and go from there as it is by far the most portable.

Let me know if you have any questions, as everything is not too documented yet. Also if you can show me some good examples of other projects with a good high level overview, I can write that out in a similar style for open brush.

I'm about to fix a glitch with the flat brush painting returning null, and add mesh serialization very soon, also planning on getting it on daydream next!

[NickAtAccuPS]

We're adding support for the Aerowand, a 6dof head/hand controller that's platform agnostic. The Aerowand relates to VR HMDs as a mouse does to a monitor. We are looking to add support to help demo the controller with Android (Daydream) and desktop VR displays. :)

Thanks for the pointers on where to look. Our hardware shares more features with the Vive than Tango so I think that might be the easier thing to port, just need to swap out the Vive tracker scripts with our own. Are there any gotchas we might run into if we used the Vive base instead of the Tango?

Also, have you been tracking the Unity 5.6 beta for Daydream support? Today's B3 release is apparently the first one appropriate for Daydream testing outside of the dedicated Daydream branch. I think it would simplify the scenes if they were using more of Unity's native VR support. Might make sense to pull this conversation into another issue (tag me if you do this).

As for a good reference, I think SDL has a pretty good starting point.

[andrewnakas]

Wow sounds cool, I've been patiently waiting for a 6dof mobile controller for some time now. I'd love to buy a developer controller if possible when ready as this is the missing link for the tango phab hmd vr. Definitely super fired up for mobile vr and happy your working on 6dof looking forward to hear more about it.

For your case following the vive version makes more sense. The main gotcha that I would think will come up is the vive input solution.

I use http://wacki.me/blog/2016/06/vr-gui-input-module-for-unity-htc-vive/ and it's great and is built so it can be portable to other platforms. I've ported it over to daydream on other projects and it should not be super hard to get working with your system. Just switch out the vive things with the native input module and set it to the controllers pose. The gotcha mainly revolves around how the ui transfers over.

In the vive version there is some code in the iuiLaserPointer.cs that accesses the checking if brushmanager is allowed to paint. This is the effect where if you are pointing a controller at the ui, you select things with the controller and cant paint. It's the bhit if statement that does this on line 90. If you do have two controllers it should port over relatively fine with the native input stuff.

One controller plays into a larger architecture thing that I was thinking about for the 3dof daydream version but have yet to implement. This is the idea that you will need to put the right controller ui menus on the painting controller and access it via a toggled menu. Then the headset gaze, becomes the ui selection and the controller houses the menus. To me this seems like the best way to accommodate both 3 and 6dof one controller systems. Let me know if any issues come up for this, it should be pretty straight forward but don't hesitate to reach out if anything comes up.

I have not been tracking the daydream 5.6 support that closely but that is exciting to hear they finally caught up, I was sick of 5.43 gvr.. I've been working in 5.6 and the next commit should reflect that!

Stoked at the future of vr/ar and the idea that open source software is going to be the only effective way to address the industry fragmentation that is happening.

[andrewnakas]

Also thanks for the SDL porting document. I will write out something like that and add a lot more documentation, when I get closer to v1. I'm definitely hitting this hard over the next couple weeks so that should be pretty soon.

[pickettd]

I managed to get a very simplistic Daydream 6dof build working today in my fork. I started with the Tango scene and added a bit of code/prefabs for the Daydream controller.

I'm testing it on a Lenovo Mirage that does 6dof tracking of the HMD. So for now I'm using the controller for menu selection (app key) and to hold down (touchpad) for painting (but the positional tracking during painting all comes from the HMD - so it is kind of like painting with your face while you hold the touchpad button).

[andrewnakas]

Hey David,

That's super cool, the whole painting with a 3dof a very interesting problem that I've thought a bit about. I was prototyping it originally for the 3dof daydream controllers with 3dof headsets but didn't want to bother to put locomotion and painting on one controller. One idea that could work really well potentially with 6dof headset 3dof controller would be to try to parent a 2d plane to 6dof headset at a user togglable distance away from head set, and then 3dof controller works as pointer to shot recast and paint on invisible 2d plane in 3d space. So your still using head to set where u want 2 paint but then controller tilt paints along set plane. Idk maybe an idea to try if you want to upgrade system with 3dof controller.