Open HoloMoto opened 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?
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) 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?
@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!
@HoloMoto , the project maintainers discussed. Here's our recommendations:
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:
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
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!