MRTK チームが取り組む一部の機能は、詳細を完全に説明していない場合でも、多くの初期値を持っているようです。 このような機能については、コミュニティに早く見てもらいたいと考えています。 これらはサイクルの早い段階であるため、実験段階としてラベル付けして、それらがまだ進化しており、時間の経過と伴って変化する可能性があることを示します。
試験的な機能に期待する内容
コンポーネントが試験段階とマークされている場合は、次のことが予想されます。
- サブフォルダーの下にある使用状況
MRTK/Examples/Experimental示すシーンの例 - 試験的な機能にはドキュメントがない可能性があります。
- テストがない可能性があります。
- 試験的な機能は変更される可能性があります。
試験的な機能ガイドライン
実験用コードは別のフォルダーに格納する必要があります
試験的なコードは、最上位の実験用フォルダーの後に試験的な機能名が続く必要があります。 たとえば、新しい機能 FooBar を提供する場合は、次のコードを入力します。
- シーン、スクリプトの例
MRTK/Examples/Experimental/FooBar/ - コンポーネント スクリプト、プレハブ
MRTK/SDK/Experimental/FooBar/ - コンポーネント インスペクターは、
MRTK/SDK/Inspectors/Experimental/FooBar
試験的な機能名の下でサブフォルダーを使用する場合は、MRTK の同じフォルダー構造をミラーしてみてください。
たとえば、ソルバーは次のようになります。 MRTK/SDK/Experimental/FooBar/Features/Utilities/Solvers/FooBarSolver.cs
シーンを上部付近のシーン フォルダーに保持します。 MRTK/Examples/Experimental/FooBar/Scenes/FooBarExample.unity
注:
実験用のルート フォルダーが 1 つなく、代わりに Experimental を " MRTK/Examples/HandTracking/Scenes/Experimental/HandBasedMenuExample.unity" の下に配置することを検討しました。 実験機能の検出を容易にするために、ベースのフォルダーを使用することにしました。
試験的なコードは、特別な名前空間に存在する必要があります
試験的なコードが、非試験的な場所と一致する試験的な名前空間に存在することを確認します。 たとえば、コンポーネントが Microsoft.MixedReality.Toolkit.Utilities.Solversのソルバーの一部である場合は、その名前空間を Microsoft.MixedReality.Toolkit.Experimental.Utilities.Solversする必要があります。
例については 、この PR を参照してください。
試験的な機能には[試験的] 属性が必要です
いずれかのフィールドの上に [Experimental] 属性を追加して、機能が試験的であり、大幅な変更が加わる可能性があることを示す小さなダイアログをコンポーネント エディターに表示します。
試験的な機能のメニューは、"試験的" サブメニューの下に配置する必要があります
エディターのメニューにコマンドを追加するときに、試験的な機能が "試験的な" サブメニューの下にあることを確認します。 いくつかの例を示します。
トップレベル メニュー コマンドの追加:
[MenuItem("Mixed Reality Toolkit/Experimental/MyCommand")]
public static void MyCommand()
コンポーネント メニューの追加:
[AddComponentMenu("MRTK/Experimental/MyCommand")]
ドキュメント
実験用機能のドキュメントを追加するには、次の手順に従います。
試験的な機能に関するドキュメントは、実験用フォルダー内の
readme.mdファイルに含まれている必要があります。 たとえば、MRTK/SDK/Experimental/PulseShader/readme.md などです。[機能の概要] で、
Documentation/toc.ymlの [試験段階] セクションにリンクを追加します。
MRTK コードへの影響を最小限に抑える
MRTK の変更によって実験が機能する可能性はありますが、期待しない方法で他のユーザーに影響を与える可能性があります。 MRTK コア コードに対して行った回帰では、プル要求が元に戻ります。
実験用フォルダー以外のフォルダーに変更をゼロにすることを目的とします。 実験的な変更を加えることができるフォルダーの一覧を次に示します。
- MRTK/SDK/Experimental
- MRTK/SDK/Inspectors/Experimental
- MRTK/Examples/Experimental
これらのフォルダーの外部の変更は、非常に慎重に扱う必要があります。 試験的な機能に MRTK コア コードの変更を含める必要がある場合は、MRTK の変更を、テストとドキュメントを含む別のプル要求に分割することを検討してください。
実験用機能を使用することは、コア コントロールを使用するユーザーの能力に影響を与えるべきではありません
ほとんどのユーザーは、ボタン、ManipulationHandler、Interactable などのコア UX コンポーネントを頻繁に使用します。 ボタンを使用できない場合、実験用機能は使用されない可能性があります。
コンポーネントを使用して、ボタン、ManipulationHandler、BoundingBox、または対話可能なボタンを分割しないでください。
たとえば、 この ScrollableObjectCollection PR では、ScrollableObjectCollection を追加すると、ユーザーは HoloLens ボタンプレハブを使用できなくなります。 これは PR のバグによって引き起こされたのではなく 、既存のバグが公開されていたとしても、PR がチェックインされるのを防ぎました。
機能の使用方法を示すサンプル シーンを提供する
People機能の使用方法とテスト方法を確認する必要があります。
MRTK/Examples/Experimental/YOUR_FEATUREの例を指定します
試験的な機能でユーザーに見える欠陥を最小限に抑える
他の人は、それが動作しない場合、試験的な機能を使用しません、それは機能に卒業しません。
ターゲット プラットフォームでサンプル シーンをテストし、期待どおりに動作することを確認します。 機能がエディターでも機能することを確認して、ターゲット プラットフォームがない場合でも、ユーザーがすばやく反復して機能を確認できるようにします。
実験用コードを MRTK コードに卒業する
機能が非常に多くの使用を見る場合は、コア MRTK コードに分解する必要があります。 これを行うには、この機能にテスト、ドキュメント、サンプル シーンが必要です。
MRTK 機能を卒業する準備ができたら、PR でチェックする問題を作成します。 PR には、テスト、ドキュメント、使用状況を示すシーンの例など、これをコア機能にするために必要なすべてのものが含まれている必要があります。
また、"Experimental" サブスペースを削除するように名前空間を更新することを忘れないでください。