Mixedrealitytoolkit-unity: Is there a Gitter or Slack channel to discuss the project?

[SimonDarksideJ]

Less of an issue and more of a request, if there is some form of chat channel for the Holo/MixedReality toolkit.

FYI, I'm building a workshop for an event next month and really struggling to separate out the MR vs HoloLens areas of the toolkit, everything seems bundled together.
A fair amount of the samples don't seem to work as expected (xbox controller support almost doesn't work)

I'm happy to pitch in and do PRs to help tidy / fix up features, but would rather chat so it's aligned to the vision for the toolkit.

Especially for MR, it needs the MR only content splitting out in its own area, same for HL and then a dedicated folder for generic scripts / prefabs, etc.

Loving the hard work that's gone in so far and want to contribute effectively.

[StephenHodgson]

[Is there] some form of chat channel for the Holo/MixedReality toolkit?

There is, but I'm usually too busy to check on there often. You're more likely to get a reply from me here, not to mention it's easier to discuss and track certain work items here, rather than elsewhere.

[I'm] really struggling to separate out the MR vs HoloLens areas of the toolkit, everything seems bundled together.

Currently the master branch only has HoloLens specific scripts and prefabs, and the development branch has the occluded headset support. I'm already working on getting the MR branch caught up with the master, but there's some big differences I need to address with the input system.

Xbox controller support almost doesn't work.

You mean on the development branch, or master? I know _for sure_ that Xbox controller support is on lock for master. Testing it on every Windows platform. Now the development branch still needs some TLC. I'm working on the controller support on the development branch in a future PR that addresses quite a few issues with the input system.

Especially for MR, it needs the MR only content splitting out in its own area, same for HL and then a dedicated folder for generic scripts / prefabs, etc.

Technically it's _all_ MR, and the reason I'm not in favor of this is because the only difference is the hardware: occluded headset (VR) vs transparent headset (HoloLens). Fundamentally, much of the feature areas were designed to cover the same or similar areas. Much of the prefabs, scripts, etc _should_ be designed to be platform agnostic. Sure, maybe there's a few specific things to think about (spatial mapping / understanding), but in general we should be treating this as a singular platform named Mixed Reality (At least that's what everyone at MSFT keeps telling me 😂).

I'm happy to pitch in and do PRs to help tidy / fix up features, but would rather chat so it's aligned to the vision for the toolkit. Loving the hard work that's gone in so far and want to contribute effectively.

Please do! The most helpful things to do right away are:

1. Review open PRs.
2. Seach already open bug reports for issues you're already interested in fixing.
3. Open new bug issues for things that haven't been reported yet.
4. Working on a fix, then opening the PR for that issue.

I usually try to review and test each within a few hours, but I do have to admit this week and next might be a little difficult to do right away.

[SimonDarksideJ]

Ok, for my focus atm @StephenHodgson , it's all about the Occluded headsets. In a lot of the "Tests" folders, there is a mix of HoloLens Camera and MixedReality camera's. So either there's a path for a "combined" Mixed Reality camera for both Occluded and non-occluded or we need a better way to organise the test scenes.

So as to branches, I'm only focusing on the Develop_2017.2 branch. This is what I'll need for the workshop next month (until it's all master :D)

With the Xbox COntroller comment. I tried a few of the Occluded samples, such as MontionController and various input tests. using the Wireless Xbox One controller, only select (a) and Cancel (b) worked. Thumbsticks flatout refused.

Granted, I need to review that against the PR's

My only concern with just "digging in" is that the re-org and Master Merge PR's seem to be competing with each other and once one is merged, the other will likely need rebasing. Plus I can only focus on Occluded atm as I don't actually have a HL :D (not so deep pockets)

So happy to accept some pointers as where help is needed most in the occluded space, as that is my focus atm.

[StephenHodgson]

I'd say let me handle the issue with the re-org. I've got an extensive knowledge about what's in there and what needs to get moved without breaking.

So essentially my plan is to do the re-org then do a side by side comparison of the branches. I'm not too worried about the history of the changes as long as everything _just works_, but I also don't want to undermine the work other people have put in, so I'm still a bit apprehensive about just copying changes over. But then again, I just want it to _work_. Haha. Much of the work from that dev branch came from Build 2017 and didn't have much history _anyway_.

Really the biggest change is the Input System, which has been drastically improved from when the dev branch was split. The other pressing issue with the input system is the new point and commit vs gaze and commit updates that were added from the build conference. I need to figure out a way to make the new APIs play nicely, etc.

That's the only big challenge holding us back from including the dev branch (Besides the fact that Unity's completely changed _ALL_ the APIs). I don't really see the branches as all that compatible, and may get bloated with editor definitions.

#if UNITY_2017_2
    // Your Specific Code for 2017.2+ APIs
#elif UNITY_2017_1
    // Your Specific code for 2017.1
#else
    // All other stuff for older 5.6 projects
#endif

[SimonDarksideJ]

I'm fine with the 2017 version remaining in it's separate branch for the mo. No need to rush to merge them until Unity itself fully releases 2017.2.

But the dev branch does need a big tidy up so it can be easily used. So if the Forward merge from Master -> 2017.2 branch can be done ASAP and the re-org. It will make it far easier to then build and enhance upon it.

Looking at from a new user perspective, there just seems too much confusion as to where to actually start, especially for Occluded users, who may not be able to take advantage of most features not available for them yet.

So how can I help to get the 2017.2 branch stabilised to then make it easier to improve the MR experience?

As for #if hell, we definitely need to avoid that. Thee shouldn't be much of that from what I've seen in the repo so far. The main concern would be switching between Occluded vs non-occluded until that's aligned

P.S.
With Dream Build Play kicking off right now, we definitely need an Occluded asset that's easy to pick up

[StephenHodgson]

But the dev branch does need a big tidy up so it can be easily used.

Just to keep things in perspective, dev branches are inherently unstable and messy, and generally not recommended for production use. But, with that being said, it's also important that those branches move forward and stabilize to get accepted into the master production branch.

So if the Forward merge from Master -> 2017.2 branch can be done ASAP and the re-org. It will make it far easier to then build and enhance upon it.

That's exactly my thinking as well. I just want to try and organize the directories to be exactly the same, then pretty much build upon master with some of the improvements and enhancements that have come from the dev branch. I'll try to get the re-org and sync done this week.

So how can I help to get the 2017.2 branch stabilized to then make it easier to improve the MR experience?

Testing, reviewing, submitting new issues, and fixing where you can!

[SimonDarksideJ]

Testing, reviewing, submitting new issues, and fixing where you can!
ROFL

Trick I'm trying to figure out is the start point, which you can appreciate with the reorg/merge is tricky.
So starting testing with the Merge or Re-org branch, especially with the other "fix branches" :S

There is another thought. That it might be worth restarting the 2017.2 branch after reorganising the Master branch and simply re-add / re-apply the new 2017.2 changes. From what I can see there doesn't appear to be that many atm.

[StephenHodgson]

There is another thought. That it might be worth restarting the 2017.2 branch after reorganising the Master branch and simply re-add / re-apply the new 2017.2 changes.

That's exactly what I'm planning on doing.

[SimonDarksideJ]

Ahh, great. Happy to help with the copy over with new PR's on the new branch as soon as that's ready.

What are your thoughts then for the new branch? Separate Occluded / non-occluded test scenes/ api's or work towards a more "merged" approach?

Obviously as I'm building a workshop atm. I can dedicate time to accelerate that, as I'll need all the "stuff"

[StephenHodgson]

What are your thoughts then for the new branch? Separate Occluded / non-occluded test scenes/ api's or work towards a more "merged" approach?

Well it seems both Unity and MSFT are using the same APIs for both, so it'll be best to just keep them together.

[jessemcculloch]

@DDReaper - I'm a little late to the conversation, but if you look at the MixedRealityCamera, it already handles determining which headset you are using and then adjusting appropriately. You can look at the script attached to it to see the specific API that is getting called to do the determination.

@StephenHodgson - One thing we need to think about is all the breaking changes from all other versions of Unity to 2017.2. We are going to have to think about maintaining two separate branches for quite awhile I think.

[StephenHodgson]

We are going to have to think about maintaining two separate branches for quite awhile I think.

@jessemcculloch I think you might be right. But I'd like to make sure we're as close as we can be.

[SimonDarksideJ]

So in your opinion @jessemcculloch , should all tests currently using the HoloLensCamera be updated to use the MixedRealityCamera then?

Very confusing to beginners to see the two camera and not understand why.

[keveleigh]

Really the biggest change is the Input System, which has been drastically improved from when the dev branch was split.

@StephenHodgson What do you mean by "improved"? I know there have been some new events and input sources added, but I'm not sure of any incompatible changes that have been made. I definitely didn't run into any during my merges.

[StephenHodgson]

I'm not sure of any incompatible changes that have been made.

In the Dev branch, there was a big change with the APIs, the way Singletons are initialized, and there have been lots of fixes to the input system in master that are reoccurring in the dev branch (such as double input when using global listeners just to name one).

[jessemcculloch]

@DDReaper - Yes, I do think that when we figure out what we are doing with the Dev_Unity_2017.2 branch (keeping it and merging, or dropping and reimplementing in a different branch) then yes, all test scenes should move to using the MixedRealityCamera.

[jessemcculloch]

@DDReaper - Also, there is a HoloDevelopers Slack Team that is a separate thing than this, however if you want input from a wide variety of developers on the platform, it's a good place to go. There is a MixedReality_HoloGraphicToolkit channel there. You can join it at https://holodevelopersslack.azurewebsites.net

[SimonDarksideJ]

Right, I'm on it (as soon as I have a min :D)
*Edit, I also learned something new about slack today, since I thought all channels from a server were shown by default, but I had to add that one :D