Closed StephenHodgson closed 6 years ago
Love this idea! Would there be any extra work to support two handed manipulation in the vnext version of MixedRealityToolkit?
Of course. Anything in the current dev branch under the MixedRealityToolkit namespace is subject to review and adoption of vNEXT.
Questions:
@genereddick, all very good questions.
We're still trying to formulate a plan for what our roadmap and timeline will look like. Remember, all of us have day jobs and we're doing this in our free time. So those who would like to help, please feel free to join in the discussions and make pull requests.
When do we expect to see a first production ready version?
No concrete date has been set, but I think the ideal is sometime in May 2018 to coincide with Build.
Is it expected that vNext will be feature complete with the current branch?
Yes, the new version will have most or all of the same features as the current release. Our hope is to do an A/B test to ensure no features have been lost. That being said, it's likely that some feature areas may be rewritten from the ground up.
Should we continue to develop and test against the current branch and if so until what point?
New development should happen against the Development branch, and bug fixes should go against both Stabilization and Development.
Will the current branch continue to be supported / developed against or will it be abandoned?
We haven't yet decided when to stop support for the current version. But seeing as this is an open source project, I'm sure that generous contributors will continue to post PRs against the older version.
Once vNEXT has matured and replaced the current master branch, then the old version will move from master to a new branch named HoloToolkit-Old or something similar.
Stephen, great job and kudo's for you guys. My own wish list for vNext would be primarily on the non-functional area. Probably a lot of open doors for you, but just to stress that this is important for me and I think other users:
Keep code simple. The complexer the code, the more likely it has bugs. Bugs are not avoidable, but reducable. Example: Some MRT code is very illusive and (thus) leads to (debugging) issues.
Use solid design patterns, e.g. model-view-controller pattern. Example: I extensively use my own library of Syncvars which I put on objects (model) to control the state of menu's, text values, sliders (view, controller). Something like this is now missing. Also sharing between devices requires solid design patterns.
Design for performance: HoloLens still has a weak processor and reaching 60 fps is very hard. Example: use Update() mainly for time-depedendent operations. Use events/callbacks extensively.
Better well tested code than more features. Example: Current MRT still has quite some bugs and illusive code/designs. (Of course one of the reasons to start vNext). This might be caused by the eager to add more features.
Better well documented code than more features. Example: MRT is now poorly documented, leading to a lot of nice code not being used and reinvented wheels. Unity documentation is a very good example, I like the difference in API and Manual. I do like the example scenes in MRT, but MRT and MRT-Examples is currently not so well separated.
Multi-device support: Different AR, VR devices + PC/Mac support. Also sharing experience (UNet) should be designed with all possible devices as clients.
Modular design: Allow us to only include the library-components that we need. Libraries should be loosly coupled and there should be no circular references. Example: Now I still have the complete MRT and MRT-Examples loaded in all apps, which makes the project unnecessary large. Deleting the parts that I do not need is difficult and still a task to do.
Yes on all counts!
I think you've hit on everything we've been concerned about as well. As we go forward, please be sure to voice your concerns if we're getting off track.
So, to be clear, this will generally be using compiler directives to make the tookit usable on non UNITY_UWP platforms? We've found with adding directives to various places the current MRTK does work on the windows platform, for example, but I was never sure if those kinds of changes should be pushed to the v1 branch.
Supporting multiple platforms is definitely a big plus as additional mixed reality solutions come on the market, so I'm happy to see this.
What is MixedRealityToolkit-vNext?
The V1 Mixed Reality Toolkit is a collection of scripts and components intended to accelerate development of applications targeting Microsoft HoloLens and Windows Mixed Reality headsets.
This new version of the MixedRealityToolkit aims to further extend the capabilities of the toolkit and also introduce new features, including the capability to support more VR/AR/XR platforms beyond Microsoft's own Mixed Reality setup.
The vNext branch is taking all the best lessons learned from the original Mixed Reality Toolkit and refactoring / restructuring it to both:
Support a wider audience, allowing solutions to be built that will run on multiple VR / AR / XR platforms such as Mixed Reality, Steam/Open VR and OpenXR (initially)
Provide an easier to use SDK, to enable rapid prototyping and ease adoption for new users (or users of previous frameworks)
Ensure an extensive framework for advanced integrators, with the ability to swap out core components with their own should they wish to, or simply extend the framework to add new capabilities.
Feature areas
The Mixed Reality Toolkit vNext will includes many APIs to accelerate the development of MR / XR / VR / AR projects for a range of supported devices, including (but not limited to)
FAQ
Short answer, No. Long Answer, yes, but with some significant work. We will be providing a detailed change log and an upgrade guide for those of you who want to try and update your projects.
No concrete date has been set, but I think the ideal is sometime in May 2018 to coincide with Build.
Yes, the new version will have most or all of the same features as the current release. Our hope is to do an A/B test to ensure no features have been lost. That being said, it's likely that some feature areas may be rewritten from the ground up.
New development should happen against the Development branch, and bug fixes should go against both Stabilization and Development.
We haven't yet decided when to stop support for the current version. But seeing as this is an open source project, I'm sure that generous contributors will continue to post PRs against the older version.
Once vNEXT has matured and replaced the current master branch, then the old version will move from master to a new branch named HoloToolkit-Old or something similar.