実験的な機能

MRTK チームが動作する一部の機能は、詳細を完全に拡充していない場合でも、初期値が多数あるように見えます。 この種の機能については、コミュニティで早期に確認できるようにしたいと考えています。 これらはサイクルの早い段階であるため、今後も進化していて、時間の経過と共に変化する可能性があることを示すために試験段階としてラベル付けします。

実験用の機能によって期待されること

コンポーネントが試験段階としてマークされている場合は、次のことを想定できます。

  • サブフォルダーの下にある使用状況を示すシーンの例 MRTK/Examples/Experimental
  • 試験的な機能にドキュメントが含まれていない可能性があります。
  • 多くの場合、テストはありません。
  • 試験的な機能は変更される可能性があります。

試験的な機能のガイドライン

試験的なコードは別のフォルダーに存在する必要があります

試験的なコードは、最上位の試験的なフォルダーに入り、その後に試験的な機能名が続きます。 たとえば、新しいフィーチャー FooBar を投稿する場合は、次のコードを記述します。

  • 例としては、スクリプトが MRTK/Examples/Experimental/FooBar/
  • コンポーネントスクリプト、prefabs 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つではなく、その代わりに試験的なルートフォルダーを配置していると考えてい 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")]

ドキュメント

実験用の機能に関するドキュメントを追加するには、次の手順に従います。

  1. 試験的な機能のドキュメントは、試験的なフォルダー内のファイルに記載さ readme.md れています。 たとえば、MRTK/SDK/実験的/PulseShader/readme.txt です。

  2. [ 機能の概要 ] で、「」の 実験的 なセクションにリンクを追加 Documentation/toc.yml します。

MRTK コードへの影響を最小限に抑える

MRTK の変更によって実験が動作する可能性がありますが、他のユーザーが予期しない方法に影響を与える可能性があります。 MRTK コアコードに対して行った回帰により、プル要求が元に戻されます。

試験的なフォルダー以外のフォルダーでは、変更をゼロにすることを目標としています。 実験的な変更が可能なフォルダーの一覧を次に示します。

  • MRTK/SDK/実験的
  • MRTK/SDK/インスペクター/実験的
  • MRTK/例/実験

これらのフォルダー以外の変更は、慎重に扱う必要があります。 試験的な機能に MRTK コアコードへの変更を含める必要がある場合は、MRTK の変更をテストとドキュメントを含む別のプル要求に分割することを検討してください。

実験用の機能を使用しても、ユーザーがコアコントロールを使用する能力に影響を与えることはありません

ほとんどの開発者は、ボタン、対話型 Ationhandler、およびのようなコア UX コンポーネントを頻繁に使用します。 これらの機能では、ボタンを使用できない場合に、実験的な機能が使用されない可能性があります。

コンポーネントを使用する場合は、buttons、BoundingBox、または対話型を中断しないようにしてください。

たとえば、この scrollableobjectcollection PRでは、scrollableobjectcollection を追加すると、HoloLens ボタン prefabs を使用できなくなりました。 これは PR のバグによるものではなく、既存のバグを公開したものでもありますが、PR がチェックインされるのを防ぐことができました。

機能の使用方法を示すシーンの例を提供する

ユーザーは、機能の使用方法とテスト方法を確認する必要があります。

MRTK/example/実験的/YOUR_FEATURE の下に例を入力してください

試験的な機能でユーザーに表示される欠陥を最小化する

機能しない場合、試験的な機能は使用されません。機能を卒業することはありません。

ターゲットプラットフォームでサンプルシーンをテストし、想定どおりに動作することを確認します。 機能がエディターでも動作することを確認します。これにより、対象のプラットフォームがない場合でも、ユーザーは迅速に反復処理して機能を確認できます。

卒業実験用コードを MRTK コードに変換する

機能が非常によく使用されている場合は、それをコア MRTK コードに卒業する必要があります。 これを行うには、この機能にテスト、ドキュメント、およびシーンの例が含まれている必要があります。

機能 MRTK を卒業する準備ができたら、PR を確認するための問題を作成します。 PR には、これをコア機能にするために必要なすべてのもの (テスト、ドキュメント、使用状況を示すシーンの例) を含める必要があります。

また、必ず名前空間を更新して、"実験的な" サブ空間を削除してください。