既存のアプリケーションを HoloLens 2 で利用できるようにするGetting your existing application ready for HoloLens 2

このガイドは、開発者が HoloLens (第 1 世代) 用の既存の Unity アプリケーションを HoloLens 2 デバイス用に移植する場合に役立ちます。This guide is tailored to help developers who have an existing Unity application for HoloLens (1st gen) to port their application for the HoloLens 2 device. HoloLens (第 1 世代) の Unity アプリケーションを HoloLens 2 に移植する主な手順は 4 つあります。There are four key steps to porting a HoloLens (1st gen) Unity application to HoloLens 2. 次のセクションでは、各ステージについて詳しく説明します。The sections below detail information for each stage.

手順 1Step 1 手順 2Step 2 手順 3Step 3 手順 4Step 4
Visual Studio のロゴ Unity のロゴ Unity のアイコン MRTK のロゴ
最新のツールのダウンロードDownload latest tools Unity プロジェクトの更新Update Unity Project ARM 用にコンパイルCompile for ARM MRTK v2 に移行Migrate to MRTK v2

移植プロセスを開始する前に、開発者がソース管理を使用してアプリケーションの元の状態のスナップショットを保存しておくことを強くお勧めしますIt is highly recommended that, before beginning the porting process, developers use source control to save a snapshot of the original state of their application. さらに、プロセス中のさまざまな時点でチェックポイントの状態を保存することを推奨します。Additionally, it is recommended to save checkpoint states at various points during the process. 移植プロセスの中で、元のアプリケーションの別の Unity インスタンスを並べて比較できるようにするのも非常に便利です。It can also be very helpful to have another Unity instance of the original applicaiton to allow for side-by-side comparison during the porting process.

注意

移植の前に、Windows Mixed Reality の開発用に最新のツールがインストールされていることを確認します。Before porting, ensure you have the latest tools installed for Windows Mixed Reality development. ほとんどの既存 HoloLens 開発者は、主に最新バージョンの Visual Studio 2019 への更新と適切な Windows SDK のインストールを行うことになります。For most existing HoloLens developers, this primarily involves updating to the latest version of Visual Studio 2019, and installing the appropriate Windows SDK. 以下の内容では、Unity のさまざまなバージョンと Mixed Reality Toolkit (MRTK) バージョン 2 についてさらに詳しく説明します。The content that follows dives further into different Unity versions and the Mixed Reality Toolkit (MRTK) Version 2.

詳しくは、ツールのインストールに関するページをご覧ください。For more information, please see Install the tools.

プロジェクトを最新バージョンの Unity に移行するMigrate project to latest version of Unity

MRTK v2 を使用している場合、Unity または MRTK で互換性に影響する変更が発生しない最適な長期サポート パスは Unity 2018 LTS になります。If you are using MRTK v2, then Unity 2018 LTS is the best long-term support path with no breaking changes in Unity or in MRTK. また、MRTK v2 は Unity 2018 LTS のサポートを常に保証していますが、必ずしも Unity 2019.x のすべてのイテレーションのサポートが保証されるわけではありません。Also, the MRTK v2 always guarantees support for Unity 2018 LTS, but does not necessarily guarantee support for every iteration of Unity 2019.x.

Unity 2018 LTS と Unity 2019.1.x の他の相違点を明らかにするために、以下では、これら 2 つのバージョン間でのトレードオフについて説明します。To help clarify additional differences between Unity 2018 LTS and Unity 2019.1.x, the following outlines the trade-offs between these two versions. 2 つの主な違いは、Unity 2019 で ARM64 用にコンパイルする機能です。The primary difference between the two is the ability to compile for ARM64 in Unity 2019.

開発者は、現在プロジェクトに存在するすべてのプラグインの依存関係と、これらの DLL が ARM64 でビルドできるかどうかを評価する必要があります。Developers should assess any plugin dependencies that currently exist in their project, and whether or not these DLLs can be built for ARM64. ARM64 でハードに依存するプラグインをビルドできない場合は、Unity 2018 LTS を使用しなければなりません。If a hard dependency plugin cannot be built for ARM64, then you will have to use Unity 2018 LTS.

Unity 2018.4.xUnity 2018.4.x Unity 2019.1+Unity 2019.1+
ARM32 ビルドのサポートARM32 build support ARM32 および ARM64 ビルドのサポートARM32 and ARM64 build support
安定版の LTS ビルド リリースStable LTS build release ベータ版の安定性Beta stability
.NET スクリプト バックエンド 非推奨.NET Scripting back-end deprecated .NET スクリプト バックエンド 削除済み.NET Scripting back-end removed
UNET Networking 非推奨UNET Networking deprecated UNET Networking 非推奨UNET Networking deprecated

Unity でシーンまたはプロジェクト設定を更新するUpdate scene/project settings in Unity

デバイスで最適な結果を得るために、Unity 2018 LTS または Unity 2019 以降への更新を行った後、Unity を特定の設定に更新すること をお勧めします。After updating to Unity 2018 LTS or Unity 2019+, it is recommended to update particular settings in Unity for optimal results on the device. この設定については、 Unity の推奨設定 で詳しく説明しています。These settings are outlined in detail under Recommended settings for Unity.

もう一度お伝えしますが、.NET スクリプト バックエンドは、Unity 2018 で非推奨となり、Unity 2019 で "削除" されます。It should be re-iterated that the .NET scripting back-end is being deprecated in Unity 2018 and removed in Unity 2019. 開発者は、プロジェクトを IL2CPP に切り替えることを特に検討する必要があります。Dvelopers should strongly consider switching their project over to IL2CPP.

注意

IL2CPP スクリプト バックエンドを使用すると、Unity から Visual Studio へのビルド時間が長くなる場合があります。そのため、開発者は、IL2CPP ビルド時間の最適化のために開発者のコンピューターをセットアップする必要があります。IL2CPP scripting back-end can cause longer build times from Unity to Visual Studio, and developers should set up their developer machine for optimizing IL2CPP build times. また、大きなアセット (スクリプト ファイルを除く) がある場合や、常にシーンやアセットを変更する Unity プロジェクトの場合は、キャッシュ サーバーをセットアップするとよいでしょう。It might also be beneficial to set up a cache server, especially for Unity projects with a large amount of assets (excluding script files) or constantly changing scenes and assets. プロジェクトを開く際に、Unity は条件を満たすアセットを内部キャッシュ フォーマットで開発者のコンピューターに格納します。When opening a project, Unity stores qualifying assets into an internal cache format on the developer machine. 項目を変更した場合は、再インポートして再処理されるようにする必要があります。Items must be re-imported and re-processed when modified. このプロセスが 1 回実行されると、キャッシュ サーバーに保存され、すべての開発者と共有されます。すべての開発者がローカルで新しい変更の再インポート処理を行う必要がなくなるので、時間を節約できます。This process can be done once and saved in a cache server and consequently shared with other developers to save time, as opposed to every developer processing the re-import of new changes locally.

開発者は、更新した Unity のバージョンに移行してから破壊的変更に対処した後、HoloLens (第 1 世代) で現在のアプリケーションをビルドしてテストする必要があります。After addressing any breaking changes after moving to the updated Unity version, developers should build and test their current applicationss on HoloLens (1st gen). この時点でソース管理にコミットを作成し、保存しておくとよいでしょう。This is a good time to create and save a commit into source control.

ARM プロセッサ用の依存関係およびプラグインのコンパイルCompile dependencies/plugins for ARM processor

HoloLens (第 1 世代) は、x86 プロセッサ上でアプリケーションを実行するのに対して、HoloLens 2 は ARM プロセッサを使用します。HoloLens (1st gen) executes applications on an x86 processor while the HoloLens 2 uses an ARM processor. したがって、既存の HoloLens アプリケーションは、ARM をサポートするように移植する必要があります。Therfore, existing HoloLens applications need to be ported over to support ARM. 前述のように、Unity 2018 LTS は ARM32 アプリのコンパイルをサポートしますが、Unity 2019.x は ARM64 アプリのコンパイルをサポートします。As noted earlier, Unity 2018 LTS supports compiling for ARM32 apps while Unity 2019.x supports compiling for ARM64 apps. 一般的に、パフォーマンスに重要な相違があるため、ARM64 アプリケーションでの開発が推奨されます。Developing for ARM64 applications is generally preferred as there is a material difference in performance. ただし、そのためには、すべてのプラグインの依存関係も ARM64 でビルドする必要があります。However, this requires all plugin dependencies to also be built for ARM64.

アプリケーション内のすべての DLL 依存関係を確認してください。Review all DLL dependencies in your application. 不要になった依存関係は、プロジェクトから削除することをお勧めします。It is advisable to remove from your project any depencency that is no longer needed. 必要な残りのプラグインについて、Unity プロジェクトにそれぞれ ARM32 または ARM64 バイナリを取り込みます。For remaining plugins that are required, ingest the respective ARM32 or ARM64 binaries into your Unity project.

関連する DLL を取り込んだ後、Unity から Visual Studio ソリューションをビルドし、アプリケーションが ARM プロセッサでビルドできるかどうかを試すために、Visual Studio で AppX を ARM 向けにコンパイルします。After ingesting the relevant DLLs, build a Visual Studio solution from Unity, and then compile an AppX for ARM in Visual Studio to test that your application can be built for ARM processors. ソース管理ソリューションでコミットとしてアプリケーションを保存することをお勧めします。It is advised to save the applicaiton as a commit in your source control solution.

MRTK バージョン 2 に更新するUpdate to MRTK version 2

MRTK バージョン 2 は、Unity をベースにした新しいツールキットで、HoloLens (第 1 世代) と HoloLens 2 の両方をサポートします。また、手による操作や視線追跡など、すべての HoloLens 2 の新機能が追加されています。MRTK Version 2 is the new toolkit on top of Unity that supports both HoloLens (1st gen) and HoloLens 2, and where all of the new HoloLens 2 capabilities have been added, such as hand interactions and eye tracking.

MRTK バージョン 2 の使用方法の詳細については、以下を参照してください。Please read the following for more information on using MRTK version 2:

移行を準備するPrepare for the migration

新しい MRTK v2 用の *.unitypackage ファイルを取り込む前に、1) MRTK v1 を組み込んだ任意のカスタム ビルド コードと、2) 入力操作や UX コンポーネントのカスタム ビルド コードのインベントリを取得することを推奨します。Before ingesting the new *.unitypackage files for MRTK v2, it is recommended to take an inventory of 1) any custom-built code that integrates with MRTK v1 and 2) any custom-built code for input interactions or UX components. Mixed Reality 開発者が MRTK v2 を取り込む際に最も競合が起きやすいのは、入力と操作に関係する部分です。The most common and prevalent conflict for a mixed reality developer ingesting MRTK v2 involves input and interactions. MRTK v2 入力モデルを読んで理解しておくことをお勧めします。It is advised to begin reading and understanding the MRTK v2 input model.

最後に、新しい MRTK v2 は、スクリプトのモデルおよびシーン内マネージャー オブジェクトから、構成およびサービス プロバイダー アーキテクチャに移行されています。Finally, the new MRTK v2 has transitioned from a model of scripts and in-scene manager objects to a configuration and services provider architecture. これにより、シーンの階層とアーキテクチャのモデルがクリーンになりますが、新しい構成プロファイルを習得する必要があります。This results in a cleaner scene hierarchy and architecture model but requires a learning curve for understanding the new configuration profiles. したがって、重要な設定やプロファイルについて理解し、アプリケーションのニーズに合わせて調整することができるように、Mixed Reality ツールキット構成ガイドを参照してください。Thus, please read the Mixed Reality Toolkit Configuration Guide to start becoming familiar with the important settings and profiles to adjust to the needs of your application.

移行するPerform the migration

MRTK v2 をインポートすると、高い確率で、Unity プロジェクトでたくさんのコンパイラ関連エラーが発生します。After importing MRTK v2, your Unity project most likely has many compiler related errors. 一般的に、これらの原因は新しい名前空間の構造と新しいコンポーネント名です。These are commonly due to the new namespace structure and new component names. スクリプトの名前空間とコンポーネントを新しいものに変更し、これらのエラーを解決します。Proceed to resolve these errors by modifying your scripts to the new namespaces and components.

HTK/MRTK と MRTK バージョン 2 の具体的な API の相違点の詳細については、MRTK バージョン 2 wiki の移植ガイドをご覧ください。For more information on specific API differences between HTK/MRTK and MRTK Version 2, see the porting guide on the MRTK Version 2 wiki.

ベスト プラクティスBest practices

  • MRTK 標準シェーダーの使用を優先する。Prefer use of the MRTK standard shader.
  • 互換性に影響する種類の変更には 1 つずつ対応する (例:IFocusable を IMixedRealityFocusHandler に)。Work on one breaking change type at a time (ex: IFocusable to IMixedRealityFocusHandler).
  • 変更のたびにテストし、ソース管理を使用する。Test after every change and use source control.
  • 可能な場合は既定の MRTK UX (ボタン、スレートなど) を使用する。Use default MRTK UX (buttons, slates, etc) when possible.
  • MRTK ファイルを直接変更するのは避け、MRTK コンポーネントのラッパーを作成する。Refrain from modifying MRTK files directly; create wrappers around MRTK components.
    • これにより、将来の MRTK の取り込みや更新プログラムの影響を受けなくなります。This protects against future MRTK ingestions and updates.
  • MRTK で提供されているサンプルのシーンを確認する (特に HandInteractionExamples.scene)。Review and explore sample scenes provided in the MRTK, especially HandInteractionExamples.scene.
  • キャンバス ベースの UI を四角形、コライダー、TextMeshPro テキストで再構築する。Rebuild canvas-based UI with quads, colliders, and TextMeshPro text.
  • 深度バッファーの共有の有効化、フォーカス ポイントの設定、またはこれらの両方を行い、パフォーマンスを向上させるために 16 ビットの深度バッファーを使用する。Enable Depth Buffer Sharing and/or set focus point; use a 16-bit depth buffer for better performance. 色をレンダリングするとき、深度もレンダリングするようにする。Ensure when rendering color, to also render depth. Unity では、一般的に、透明なゲームオブジェクトとテキスト ゲームオブジェクトの深度は書き込まれません。Unity generally does not write depth for transparent and text gameobjects.
  • 単一パスのインスタンス化レンダリング パスを設定する。Set Single Pass Instanced Rendering Path.
  • MRTK 用の Hololens 2 構成プロファイルを利用する。Utilize the Hololens 2 configuration profile for MRTK

アプリケーションのテストTesting your application

RC1 時点で、HoloLens 2 のコンポーネントおよび機能が MRTK バージョン 2 で使用できるようになっています。そのため、手による操作を直接 Unity でシミュレートすること、および手による操作と視線追跡の新しい API を使用して開発を行うことができます。Now that HoloLens 2 components and capabilities are available in MRTK Version 2, as of RC1, you can simulate hand interactions directly in Unity as well as develop with the new APIs for hand interactions and eye tracking. 十分なユーザー エクスペリエンスを作成するには、HoloLens 2 デバイスが必要です。The HoloLens 2 device is required to create a satisfying user experience. より詳しく理解するために、ドキュメントとツールの学習を開始することをお勧めします。Your are encouraged to start studying the documentation and tools for greaer understanding. MRTK v2 は HoloLens (第 1 世代) での開発をサポートしています。このため、エアタップによる選択などの従来の入力モデルは HoloLens (第 1 世代) でテストできます。MRTK v2 supports development on HoloLens (1st gen), and traditional input models, such as select via air-tap can be tested on HoloLens (1st gen).

HoloLens 2 向けの操作モデルの更新Updating your interaction model for HoloLens 2

アプリケーションを移植して HoloLens 2 に対応するよう準備できたら、操作モデルやホログラムの設計配置の更新を検討できるようになります。Once your application is ported and prepped for HoloLens 2, you're ready to consider updating your interaction model and hologram design placements. HoloLens (第 1 世代) では、アプリケーションで視線入力とコミットによる操作モデルが使われており、視野に収まるようにホログラムがかなり遠くにある可能性が高くなります。In HoloLens (1st gen), your application likely has a gaze and commit interaction model with holograms relatively far away to fit into the field of view.

アプリケーションの設計を HoloLens 2 に最適な状態になるように更新する手順は次のとおりです。Steps to update your application design to be best suited for HoloLens 2:

  1. MRTK コンポーネント:事前の作業で MRTK v2 を追加した場合は、HoloLens 2 用に設計および最適化されているさまざまなコンポーネントやスクリプトを活用できます。MRTK components: Per the pre-work, if you added MRTK v2, there are various components/scripts to leverage that have been designed and optimized for HoloLens 2.

  2. 操作モデル:操作モデルを更新することを検討します。Interaction model: Consider updating your interaction model. ほとんどのシナリオでは、視線入力とコミットを手に切り替えることをお勧めします。For most scenarios, we recommend switching from gaze and commit to hands. 通常、ホログラムは手の届かないところにあるので、手に切り替えることで、ポインティング レイやグラブ ジェスチャによる遠隔インタラクションを利用することになります。With your holograms typically being out of arms reach, switching to hands results in far interaction pointing rays and grab gestures.

  3. ホログラムの配置:手による操作モデルに切り替えた後は、直接手で近接インタラクションのグラブ ジェスチャを使用した操作を行えるように、ホログラムを近くに移動することを検討します。Hologram placement: After switching to a hands interaction model, consider moving some holograms closer to directly interact with them with your hands using near interaction grab gestures. 直接つかんだり操作を行ったりするために近くに移動させることが推奨されるホログラムの種類は、小さなターゲット メニュー、コントロール、ボタン、およびグラブしたり調べたりしても HoloLens 2 の視野に収まる小さなホログラムです。The types of holograms recommended to move closer to directly grab or interact are small target menus, controls, buttons, and smaller holograms that fit within the HoloLens 2 field of view when grabbing and inspecting the hologram.
    どのアプリケーションやシナリオにも同じものはないので、フィードバックや継続する学習に基づいて設計ガイダンスを見直し、掲載し続ける予定です。Every application and scenario is different, and we’ll continue to refine and post design guidance based on feedback and continued learnings.

X86 から ARM へのアプリケーションの移行に関するその他の注意事項と確認事項Additional caveats and learnings about moving applications from x86 to ARM

  • 単純な Unity アプリケーションは、ARM アプリケーション バンドルを構築できるため、またはバンドルを実行するためにデバイスに直接デプロイできるため、シンプルです。Straight-forward Unity applications are simple because you can build an ARM application bundle or deploy directly to the device for the bundle to run. 一部の Unity ネイティブ プラグインでは、特定の開発上の課題が発生する可能性があります。Some Unity native plugins can present certain development challenges. このため、すべての Unity ネイティブ プラグインを Visual Studio 2019 にアップグレードし、その後、Unity 2019、ARM64 を使用して ARM 用に再構築する必要があります。Because of this, you must upgrade all Unity native plugins to Visual Studio 2019, and then rebuilt for ARM with Unity 2019, ARM64.

  • 1 つのアプリケーションで Unity AudioKinetic Wwise プラグインが使用されており、そのバージョンの Unity には UWP ARM プラグインがなかったため、ARM で実行するその問題のアプリケーションにサウンド機能を再構成するためにかなりの労力が必要でした。One application used the Unity AudioKinetic Wwise plugin, and that version of Unity did not have a UWP ARM plugin, which caused a considerable effort to re-work sound capabilities into the applicaion in question to run on ARM. 開発プランに必要なすべてのプラグインがインストールされていて、Unity で利用できることを確認してください。Ensure that all required plugins for you development plans are installed and available in Unity.

  • 場合によっては、アプリケーションが必要とするプラグインに UWP/ARM プラグインが存在しない場合があります。これにより、アプリケーションを移植して HoloLens 2 で実行する機能がブロックされます。In some cases, a UWP/ARM plugin might not exist for application-required plugins, which blocks the ability to port the application and run it on HoloLens 2. 問題を解決して ARM のサポートを提供するには、プラグインのプロバイダーにお問い合わせください。Contact your plugin provider to resolve the issue and provide support for ARM.

  • シェーダーの minfloat (および min16float、minint などのバリアント) の動作は、HoloLen 2 と HoloLens (第 1 世代) で異なる場合があります。The minfloat (and variants such as min16float, minint, etc…) in shaders might behave differently on HoloLen 2 than on HoloLens (1st gen). 具体的には、「少なくとも指定された数のビットが使われる」ことが保証されます。Specifically, these guarantee that at least the specified number of bits will be used. たとえば、ほとんどの Intel/Nvidia の GPU では、単なる 32 ビットとして扱われます。On Intel/Nvidia GPUs for instance, these are largely just treated as 32 bits. ARM では、指定されたビット数が実際に使用されます。On ARM, the number of bits specified is actually adhered to. つまり、実際には、HoloLens 2 でのこれらの数値の精度や範囲は、HoloLens (第 1 世代) よりも小さくなります。That means in practice, these numbers might have less precision or range on HoloLens 2 than they did on HoloLens (1st gen).

  • ARM では _asm 命令は動作しないと見られるので、_asm 命令を使用しているコードはすべて書き直す必要があります。The _asm instructions don’t appear to work on ARM, meaning any code using _asm instructions must be rewritten.

  • ARM では xmmintrin.h、emmintrin.h、tmmintrin.h、immintrin.h などの各種ヘッダーは使用できないため、ARM では SIMD 命令セットはサポートされません。The SIMD instruction set is not supported on ARM because various headers, such as xmmintrin.h, emmintrin.h, tmmintrin.h, and immintrin.h, are not available on ARM.

  • ARM のシェーダー コンパイラは、シェーダーの読み込み時ではなく、シェーダーが読み込まれた後またはシェーダーが依存するものが変更された後の最初の描画呼び出しの中で実行されます。The shader compiler on ARM runs during the first draw call after the shader has been loaded or something the shader relies on has changed, not at shader load time. コンパイルする必要があるシェーダーの数によっては、フレーム レートへの影響が顕著になる場合があります。The impact on framerate can be very noticeable, depending on how many shaders need to be compiled. これは、HoloLens 2 と HoloLens (第 1 世代) でのシェーダーの処理、パッケージ化、更新の方法の違いに対してさまざまな影響を与えます。This has various implications for how shaders should be handled, packaged, updated differently on HoloLens 2 vs HoloLens (1st gen).

関連項目See also