最近、Unity用のプラグインの作成に遭遇しました。 以前は経験がなかったため、この環境のユーザーは2〜3か月しかいません。 プラグインの開発中、多くの興味深い点が蓄積されており、インターネットに関する情報はほとんどありません。 開拓者のためにこれらすべてのポイントをより詳細に説明したいと思います。そうすれば、私自身が何度も踏んだのと同じレーキに落ちないようになります。

この記事は上級ユーザーにも役立つはずです。 OSX、Windows、iOS、Android用のプラグイン開発の有用なツールとニュアンスを考慮します。

Unityで長時間ビデオを再生すると、すべてがうまくいくとは限りませんでした。 組み込みツールは非常に限られており、モバイルプラットフォームではフルスクリーンモードでのみビデオを再生できますが、これはアイスゲームゲームではありません！ 最初は、サードパーティのプラグインを使用しました。 ただし、必要な機能が欠けているか、バグがあり、その修正は長い間待たなければなりませんでした（修正された場合）。 このため、 ブラックジャックとw ... 、停止、および機能を備えたUnity用のビデオデコーダーの独自バージョンを作成することにしました。

プラグインとコードの作成は投稿しません-申し訳ありませんが、商業上の秘密はありますが、一般的な原則について説明します。 ビデオデコーダーを実装するために、オープンでライセンスフリーのWebM形式を再生できるvp8およびvp9コーデックを使用しました。 ビデオフレームをデコードした後、YUVカラーモデルのデータを取得します。 次に、各コンポーネントを個別のテクスチャに書き込みます。 実際、ここでプラグインが終了します。 さらにUnity自体では、シェーダーはYUVをRGBカラーモデルにデコードします。これは既にオブジェクトに適用されています。

あなたが尋ねる-なぜシェーダーですか？ いい質問です。 最初に、プロセッサでカラーモデルソフトウェアを変換しようとしました。 デスクトップの場合、これは許容範囲であり、パフォーマンスはそれほど低下しませんが、モバイルプラットフォームでは状況は根本的に異なります。 ワークスペースのiPad 2では、ソフトウェアコンバーターは8-12 FPSを提供しました。 シェーダーでの色変換が25-30 FPSを受け取ったとき、これは既に通常の再生可能なインジケーターです。

プラグイン開発のニュアンスに移りましょう。

キーポイント

Unity用のプラグインを作成するためのドキュメントはかなり少なく、すべてが一般的な用語で説明されています（iOSの場合、私は経験から多くのニュアンスを見つけました）。 ドキュメントへのリンク 。

喜ばしいこと-現在のスタジオとプラットフォーム用に収集された例があります（iOSを除く：Appleはおそらく開発者に余分なお金を払わなかったでしょう）。 サンプル自体はUnityの更新ごとに更新されますが、軟膏にもフライがあります。API、インターフェイスは頻繁に変更され、定義され、定数は名前が変更されます。 たとえば、新しいヘッダーを使用した場所から新しい更新を取得しました。 次に、気づくまで、プラグインがモバイルプラットフォームで動作しない理由を見つけました。

SUPPORT_OPENGLES  //  SUPPORT_OPENGL_ES //  

おそらく、すぐに考慮する必要があるすべてのプラットフォームの唯一の重要なポイントは、レンダリングサイクルです。 Unityレンダリングは、別のスレッドで実行できます。 これは、メインスレッドがテクスチャで機能しないことを意味します。 この状況を解決するために、スクリプトには、 適切なタイミングでコールバックをプルするIssuePluginEvent関数があります。この関数では、レンダリングに必要なリソースの操作を実行する必要があります。 テクスチャを使用する場合（作成、更新、削除）、フレームの最後にコールバックをプルするコルーチンを使用することをお勧めします。

 private IEnumerator MyCoroutine(){     while (true) {            yield return new WaitForEndOfFrame();            GL.IssuePluginEvent(MyPlugin.GetRenderEventFunc(),magicnumber);     } } 

興味深いことに、メインスレッドでテクスチャを操作しようとすると、ゲームはDX9 APIでのみクラッシュします。

OSX

おそらく最も簡単で最もトラブルのないプラットフォームです。 プラグインは急速に進んでおり、借方記入も簡単です。 xCodeで、Process-> Unityにアタッチします。 休憩を入れたり、落下したときにコールスタックを監視したりできます。

興味深い点が1つだけありました。 Unityは最近、バージョン5.3.2に更新されました。 エディターでは、OpenGL 4がメインのグラフィックスAPIになりました。古いバージョンではOpenGL 2.1でしたが、現在は非推奨です。 更新されたバージョンでは、エディターは単にビデオを再生しませんでした。 クイックデバッグは、 glTexSubImage2D関数（GL_TEXTURE_2D、0、0、0、幅、高さ、GL_ALPHA、GL_UNSIGNED_BYTE、バッファー）がGL_INVALID_ENUMエラーを返すことを示しました。 OpenGLのドキュメントから判断すると、 GL_REDはGL_ALPHAピクセル形式を置き換えるようになりました。これはOpenGL 2.1では動作しません...松葉杖でバックアップする必要がありました。

 const GLubyte * strVersion = glGetString (GL_VERSION); m_oglVersion = (int)(strVersion[0] – '0'); if (m_oglVersion >= 3) pixelFormat = GL_RED; else pixelFormat = GL_ALPHA; 

そして最も不思議なことは、OpenGL 4でコンパイルされた最終ビルドでは、すべてがGL_ALPHAフラグで正常に機能することです。 私は魔法のセクションでこのニュアンスを書き留めましたが、それでも人間的にそれをしました。

Unity Editorは、古いバージョンのOGLで実行できます。 これを行うには、コンソールに次のように記述します。

Applications/Unity/Unity.app/Contents/MacOS/Unity -force-opengl

便利なユーティリティの中で、グラフィックツールの一部であるOpenGLプロファイラーについて言及したいと思います。 ツールは、Apple Webサイトの「開発者」セクションからダウンロードできます。 プロファイラーを使用すると、アプリケーションのOpenGLの状態を完全に監視できます。エラーをキャッチし、テクスチャの内容（サイズ、タイプ、フォーマット）、ビデオメモリのシェーダーとバッファを確認し、さまざまなイベントのブレークポイントを設定できます。 グラフィックを操作するための非常に便利なツール。 スクリーンショット：



そのため、Unity Editorで1326テクスチャが使用されていることがわかりました。

窓

このOpenGLプラットフォームでは、プラグインバージョンも問題なくコンパイルされました。 しかし、DirectX 9ではさらに詳しく説明します。

1. DirectX 9には、デバイスの紛失（紛失したデバイス）などの「機能」があります。 OpenGLおよびDirectX（バージョン10以降）には、この欠点がありません。 実際、グラフィックリソース（テクスチャ、シェーダー、ビデオメモリメッシュなど）の制御が失われます。 この状況を処理する必要があり、発生した場合は、すべてのテクスチャを再度ロードまたは作成する必要があります。 私の観察によると、多くのプラグインがまさにそれを行います。 私は少しカンニングをすることができました。Unityスクリプトからテクスチャを作成し、そのポインターをプラグインに渡します。 したがって、リソース管理全体をUnityに任せ、彼自身がデバイスの損失の状況に対処しています。

 MyTexture = new Texture2D(w,h, TextureFormat.Alpha8, false); MyPlugin.SetTexture(myVideo, MyTexture.GetNativeTexturePtr()); 

2.すべての準備が整ったと思われるとき、予期しない問題が発見されました。 スクリーンショットに示すように、一部のビデオでのみ、画像がオフセット付きで表示される場合がありました。



画像のタイプから判断すると、エラーは、データをテクスチャにコピーするアルゴリズム、テクスチャ座標、またはラップテクスチャに関連付けられている可能性があります。 ドキュメントは、DirectXが余分なバイトを追加することで最適化のためにテクスチャサイズを均等化できることを示唆しました。 この情報は構造に保存されます：

 struct D3DLOCKED_RECT { INT  Pitch; void *pBits; } 

ピッチ -整列を考慮した、テクスチャの1行のバイト数。
コピーアルゴリズムをわずかに修正すると、目的の結果が得られました（余分なピクセルをゼロで埋めました）。

 for (int i = 0; i < height; ++i) { memcpy(pbyDst, pbySrc, sizeof(unsigned char) * width); pixelsDst += locked_rect.Pitch; pixelsSrc += width; } 

OpenGLのデバッグには、gDEBuggerユーティリティが役立ちます。OSX用のOpenGL Profilerと機能が似ています。



残念ながら、DX9用のそのようなユーティリティは見つかりませんでした。 そのようなツールの存在は、データをテクスチャにコピーする際にエラーを見つけるのに役立ちます。

IOS

サンプルには、このプラットフォームのサンプルプロジェクトはありませんでした。 ドキュメントには有用な情報はほとんどなく、主にプラグインからの機能へのアクセスについてのみです。

重要な側面について説明します。

1. xCodeで、StaticLibタイプの通常のiOSプロジェクトを作成します。 OpenGLフレームワークを接続します-プラグインを作成できます。

2.最終的なプラグインファイルの名前は重要ではありません。 Unityでは、iOSフォルダーにあるすべてのプラグインから関数がインポートされます。

 [DllImport("__Internal")] 

3.重要なポイント-別のプラグインに同じ名前の関数がある場合、ビルドをビルドできません。 リンカUnityは二重実装を誓います。 アドバイス-誰もそのような名前を考えないように名前を付けてください。

4.プラグインのロード時に呼び出されるUnityPluginLoad（IUnityInterfaces * unityInterfaces）は呼び出されません！ プラグインがいつ開始したかを確認し、現在のレンダーデバイスに関する情報を取得するには、 UnityAppControllerから継承した独自のコントローラーを作成し、プラグインとRenderEventを開始する関数呼び出しを登録する必要があります。 作成されたファイルは、iOS用のプラグインがあるフォルダーに配置する必要があります。 関数を登録するためのコントローラーの実装例：

 #import <UIKit/UIKit.h> #import "UnityAppController.h" extern "C" void MyPluginSetGraphicsDevice(void* device, int deviceType, int eventType); extern "C" void MyPluginRenderEvent(int marker); @interface MyPluginController : UnityAppController { } - (void)shouldAttachRenderDelegate; @end @implementation MyPluginController - (void)shouldAttachRenderDelegate; { UnityRegisterRenderingPlugin(&MyPluginSetGraphicsDevice, &MyPluginRenderEvent); } @end IMPL_APP_CONTROLLER_SUBCLASS(MyPluginController) 

5.プラグインが複数の異なるアーキテクチャを使用している場合、それらを単一の静的ライブラリに結合して利便性を高めることができます。

lipo -arch armv7 build/libPlugin_armv7.a\
-arch i386 build/libPlugin _i386.a\
-create -output build/libPlugin .a

6.テスト中に、負のテクスチャ座標が頂点シェーダーからピクセルシェーダーに転送されないことがわかりました。常にゼロが発生します。 デフォルトでは、テクスチャはアドレッシングモードCLAMP_TO_EDGEで作成されます。 この場合、OpenGL ESはすべてを[0..1]の範囲にカットします。 デスクトッププラットフォームでは、これは観察されません。

7.重大なバグが見つかりました。 スクリプトデバッグを有効にしてiOS用のプロジェクトをビルドすると、ゲームがクラッシュするとxCodeもクラッシュします。 その結果、ログもコールスタックもありません...

iOSプラットフォーム用のプラグインのデバッグは楽しみです。xCodeには、クラッシュしたときに常にコールスタックがあります。 コンソールでは、スクリプトとプラグインの両方のログを読み取ることができます。プロジェクトに* .CPPプラグインファイルを追加すると、ブレークを入れて、完全なlldbデバッガー機能を使用できます。 しかし、スクリプトを使用すると、すべてが悪化するため、ログを記録してください。

Android

Android用のビルドには、ほとんどのツールが必要です。

-C ++コードを編集するための通常のIDE。 私はxCodeを使用しました。 とにかく、Androidのポピーで組み立てる方が簡単です。
-Cコードを静的ライブラリにビルドするためのNDK。
-Javaなどのすべてのニーズを備えたAndroid Studio。スタジオは、アプリケーションで何が起こっているかを簡単に記録するために必要です。

興味深い点を見てみましょう。

1. Androidでのプラグインのデバッグの状況はかなり悲しいので、すぐにログをファイルに書き込むことを検討することをお勧めします。 もちろん、混乱してリモートデバッグの設定を試みることもできますが、これに時間はなく、Android Studioを介してログを参照するより簡単な方法を選択する必要がありました。 このため、android / log.hには__android_log_vprint関数があり、printfと同様に機能します。 便宜上、クロスプラットフォームビューでラップします。

 static void DebugLog (const char* fmt, ...) { va_list argList; va_start(argList, fmt); #if UNITY_ANDROID __android_log_vprint(ANDROID_LOG_INFO, "MyPluginDebugLog", fmt, argList); #elif printf (fmt, argList); #endif va_end(argList); } 

assertをバイパスしないことをお勧めします。 それらがトリガーされた場合、Android Studioでは完全な呼び出しスタックを表示できます。

2.このプラットフォームでは、プラグインの命名の詳細はlibMyPluginName.soです。 たとえば、libプレフィックスが必要です（詳細については、Unityのドキュメントを参照してください）。

3. Androidアプリケーションでは、すべてのリソースが1つのバンドル（jarファイルまたはzipファイル）に保存されます。 他のプラットフォームのように、ストリームを開いてデータの読み取りを開始することはできません。 ビデオへのパスに加えて、Android apkへのパスを含むApplication.dataPathが必要です。この方法でのみ、目的のアセットを取得して開くことができます。 ここから、ファイルの長さとバンドルの開始に対するオフセットを取得します。

 unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) activity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity") assetMng = activity.Call<AndroidJavaObject>("getAssets") assetDesc = assetMng.Call<AndroidJavaObject>("openFd", myVideoPath); offset = assetFileDescriptor.Call<long>("getStartOffset"); length = assetFileDescriptor.Call<long>("getLength"); 

パスApplication.dataPathに沿って標準ツール（fopenなど）でファイルストリームを開き、オフセットオフセットでファイルの読み取りを開始します-これがビデオです。 ビデオファイルがいつ終了し、それ以上の読み取りを停止するかを知るには、長さが必要です。

4.バグを見つけました。

 s_DeviceType = s_Graphics->GetRenderer(); 

s_DeviceTypeには常にkUnityGfxRendererNullが含まれます 。 フォーラムから判断すると、これはUnityのバグです。 Androidは定義でコードの一部をラップし、デフォルトで定義されています：

 s_DeviceType = kUnityGfxRendererOpenGLES 

Android用に開発するときは、コンソールでの定期的な掘削と定期的な再構築の準備が必要です。 最初にAndroid.mkおよびApplication.mkを正しく構成した場合、アセンブリに関する問題は発生しません。

まあ、のように、それがすべてです。 私は最初から明らかではなかったすべての重要な点に焦点を当てようとしました。 この知識があれば、通常のプラグインアーキテクチャを事前に開発できます。コードを何度も書き換える必要はありません。

結論として

予備的な計算によると、この作業には2〜3週間かかりましたが、2か月かかりました。 ほとんどの場合、上記のポイントの明確化に費やす必要がありました。 最も退屈で長いステージはAndroidです。 静的ライブラリとプロジェクトを再構築するプロセスには約15分かかり、新しいログを追加してデバッグが行われました。 コーヒーを買いだめして、我慢してください。 Unityの頻繁なクラッシュとフリーズを忘れないでください。

この資料が有用で、貴重な時間の節約に役立つことを願っています。 批判、質問は大歓迎です！

ご清聴ありがとうございました。