MixedRealityToolkit / MixedRealityToolkit-Unity

This repository holds the third generation of the Mixed Reality Toolkit for Unity. The latest version of the MRTK can be found here.
BSD 3-Clause "New" or "Revised" License
358 stars 91 forks source link

[FEATURE REQUEST] Enhancing the usability of MRTK3 samples #498

Open HoloMoto opened 10 months ago

HoloMoto commented 10 months ago

Describe the problem

I have noticed that obtaining MRTK3 samples has become more challenging compared to the MRTKv2 era. In my understanding, during the time of MRTKv2, there was an Examples package that made it easy to access and view samples.

However, with MRTK3, the samples are within the DevTemplate Unity project, requiring users to clone or download it and open it as a Unity project to inspect the samples.

I believe that making it more convenient to access and explore the samples is crucial, especially for MRTK3 beginners or new users, This would greatly facilitate the learning process for MRTK3.

Describe the solution you'd like/Describe alternatives you've considered

"I have been working on a prototype that allows scenes within DevTemplate to be provided as samples. You can check it out by adding the following URL in UnityPackageManager:

https://github.com/HoloMoto/MixedRealityToolkit-Unity_MRTK3fork.git?path=/org.mixedrealitytoolkit.examples#holomoto/ExamplePackage

This is just an initial proposal, and I plan to clean up folder structures and add dependencies based on feedback from the MRTK3 team.

However, one challenge is that the samples may not be loaded within DevTemplate as it is now. To address this, I intend to create an editor extension within the DevTemplate project's Assets/Editor directory, similar to the usability of MRTK3's GraphicTools samples.

Here is the repository I am currently working on. I am awaiting feedback from the MRTK3 team and am preparing to submit a pull request once it's ready.

https://github.com/HoloMoto/MixedRealityToolkit-Unity_MRTK3fork/tree/holomoto/ExamplePackage/org.mixedrealitytoolkit.examples

image

Additional context

This is my first time contributing to the MRTK3 project (although I've been involved with GraphicsTools), and I would be honored if my proposal is accepted, allowing me to participate in the project. I'm really excited about the prospect!

Thank you!

HoloMoto commented 10 months ago

In addition to my proposal to create an MRTK3 sample package, I'd like to suggest the following:

Currently, GraphicsTools are provided as an independent package with separate samples. From a beginner's perspective, having graphics samples as a separate entity from the MRTK3 samples could potentially lead to confusion.

If my proposal is accepted, it would be even more convenient if, within the sample package, the existing MRGT samples remain intact alongside the newly added MRTK3 samples. This means that users would have the option to import both MRGT and MRTK3 samples from a single package.

In other words, I believe it would be clearer and more user-friendly if users could access a comprehensive set of samples for MRTK3 in one place.

Alternatively, another approach could be to create new samples within the MRGT package, incorporating MRTK3 components like MRTKRig. This way, users could access MRTK3 features within the context of existing MRGT samples.

This approach would streamline the user experience and make it easier to work with both MRGT and MRTK3 samples. @Cameron-Micka What are your thoughts on this idea?

AMollis commented 10 months ago

Hi @HoloMoto ... I like the idea of making the samples parts of our packages. However, I think we need a little thought as to the best approach here. At the moment I can see 4 options:

  1. Create a separate package with all MRTK sample (like you've mentioned in your description)
  2. Place samples under their relevant MRTK package (i.e. audio samples go around the org.mixedrealitytoolkit.audio pacakge).
  3. Keep things the way they are. Samples are in GitHub only.
  4. Combo of 2 and 3. Complex samples (ones that require cross package dependencies) remain in GitHub. Simple samples are moved to thier corresponding package.

(1) is a whole lot easier than (2) and keeps the file size of the "main" packages down. However, it would be harder to decipher which sample package version demonstrates usage for a particular "main" package version. For example, imagine in the future, when org.mixedrealitytooklit.uxcomponents is at version 4.5.0, and the user what's samples for org.mixedrealitytooklit.uxcomponents 3.1.0; how does this user find the corresponding sample package? Also, semantic versioning of a sample package may get out of control. As each "main" package version changes its major or minor version independently, this package would also be updated.

(2) is more in-line with other non-MRTK packages from Unity and makes it easier to find samples for a particular package version. However, it would require some major refactoring of the samples to avoid taking hard dependencies on packages not needed by the non-sample code (i.e. org.mixedrealitytoolkit.core samples can't depend on org.mixedrealitytoolkit.uxcomponent).

(3) is the easiest, and users can utilize branch tags to find the corresponding samples for the package version they are using. However, GitHub discovery can be hard.

@shaynie , @keveleigh , @david-c-kline , @whebertML , @ghazen-ml , what do you think?

HoloMoto commented 10 months ago

@AMollis Thank you your response I want to emphasize that my primary goal is to improve accessibility to samples, especially for beginners. I'll brainstorm some more ideas on how to achieve this.

Absolutely! I'm looking forward to hearing the opinions of other team members regarding the best approach and how to handle dependencies as needed. I'll get to work on that!

AMollis commented 9 months ago

@HoloMoto , the project maintainers discussed. Here's our recommendations: