今回の主な話題：FairyGUI開発経験の共有、リニアワークフローアートテクスチャ作成方法の選択、コマンドラインコンパイルパッケージがVideoPlayer MP4動画を再生する時のブルースクリーン、Invalid AABB aabbエラー。
UI
Q1: 主にプログラムの作業負荷を軽減するために、新プロジェクトにFairyGUIを使用したいです。みなさんはプロジェクトに使うことありませんか？主にアトラス、DrawCallの最適化、スクロールバーの最適化、Richtext分析などについて、FairyGUIは上手くサポートしていますか？カスタムUIコントロールもサポートできますか？
①
主な利点は、
1）アーティストに友好です。すべての習慣はAdobeシリーズと一致しており、エディター自体はAS3によって開発されています。
2）様々な概念が詰め込まれており、インターフェース作業に非常に便利です。たとえば、関連付け→画面の適応、コントローラー→ステータス制御などです。
3）前のバージョンの解析にxmlを使用し、GCが増えました。最新バージョンではバイナリに更新され、インターフェースが作成するCPUとメモリのコストは大幅に削減されました。しかし、まだ内部で使用されており、発表されていません。この機能は、FairyGUIにも２ヶ月しかリリースされていません。
4）組み込みのアトラスはAlphaチャンネル分離をサポートしており、テクスチャ圧縮とモデルの互換性に直接適用できます。P.S.:コードを少し変更し、Alphaテクスチャの形式をAlpha8になさせます。実際にテストした結果、こうすれば視覚効果を確保しながらテクスチャを小さく圧縮できます。
5）さまざまな基本事物：DrawCall、アトラス、さまざまなタイプのコンポーネントなど、すべて良好な状態であり、通常、サポートできないものは発生しません。
6）一つDebugの欠点について話します。FairyGUIのコンポーネントはMonoBehaviourタイプではないため、Unityで表示されるGameObjectはコンポーネントを1つずつ対応できません。妙な問題が発生した場合は、ある程度の想像力が必要です。 UGUIまたはNGUIUIパラメーターのような直接確認することはできません。
7）FairyGUIはクロスプラットフォームであり、FairyGUIエディターでのプレビューとUnityEditorでのプレビューが違う状況はよくあります。Flashレンダリングについてある程度理解している場合は、障害になることはありません。関する経験のない場合、いくつ回の試す必要があります。
②
最大の利点はもちろん開発効率です。FairyGUIの使用者たちはほぼ好きになって、この開発モードの効率は他のUIとはほど遠いで、プロジェクトが大きいほど明確です。UI開発の一つの大きな特点はリファクタリング回数が多いことです。これが発生すると、通常、最前線のプログラマーが辞任したくなさせますが、FairyGUIを使用すると、穏やかに行うことができます。
みんなが気になっているパフォーマンスについて、DrawCallを減らすためにNGUI/UGUIが採用した合併MeshテクノロジーがUI制作への要求は高すぎで、動的および静的な分離が不合理になると、災害が発生します。FairyGUIが提供する最適化テクノロジーは動的な後期最適化であり、制作する時にUI担当者にほぼ要求ありません。簡単に言えば、FairyGUIが自動最適化を担当します。両者の性能の違いはほとんど感じられませんが、UGUIを最適化しないと、FairyGUIとは大きく異なります。ですから、「FairyGUIはローエンドマシンに簡単に対応できますが、UGUIは一生懸命最適化しなければなりません。」という噂があります。
GC問題はC#ライブラリで避けられない話題であり、FairyGUIも改善し続けています。最近発表したバイナリ形式は、誰もが常に意見を持っていたローディングの問題を解決しました。FairyGUIの実行中に、テキストと画像の変換がない場合、様々なアクション効果が実行しています（位置変更、透明、回転など）が、GCはありません。これは珍しいです。通常、他のUIでこれらの効果を実現したい場合、必然的に他のプラグインを導入したり、自分で多くのコードを書きたりです。この場合、これらのコードの最適化は自分で最適化する必要があります。
最後に欠点を話します。まず、FairyGUIを使用したい場合には、もう1つのエディターを学び、別の開発モデルを理解する必要があります。現在、FairyGUIがUGUIよりもはるかに知られていない場合、FairyGUIを選択するには、決定者が先見性を持つことを要求します。次に、FairyGUIとUIの組み合わせの実行中の問題点に対して、多くのキャッシュメカニズムが付属します。例えば、ゲーム中のListは常に更新されるのを避けることができないため、FairyGUIのListにはCacheが付属しています。これらを理解する必要があります。そうしないと、FairyGUIでメモリリークが発生するに勘違いやすいです。
レンダリング
Q2: 私たちのプロジェクトはPBRマテリアルを使用していますが、ガンマ色空間でのPBR照明計算の結果が間違っています。 そこで、リニアワークフローへの移行を考慮しています。 Unityは、バージョン5.5以降、モバイルデバイスでリニアワークフローをサポートしています。OpenGLES3.0デバイスの割合は十分に高く、デバイスのサポートは問題ありません。
現在の問題は、リニアワークフローでテクスチャの作成を直接推進すると、アーティストの作業習慣に大きな挑戦となるため、線形でインポートするときにsRGBをチェックして線形とガンマを区別する方法を使用したいということです。何か注意すべきところありませんか？
①
以前のプロジェクトではリニアワークフローを使用していましたが、新しいプロジェクトでも間違いなくリニアワークフローを使用します。少し前に、友達の起業家チームにGamma空間からリニアワークフローへ転換のすることをお勧め及び協力しました。ですから、リニアワークフローを強くお勧めします。もちろん、アートチームの誰かがリニアワークフローに関連する制作経験を持っている場合、プログラムはより適切かつ迅速に実装されます。
問題主はすでにリニアワークフローの利点を認識しているので、ここでは詳しく説明せず、問題自体に戻ります。私の理解によると、問題主のアイデアは、以前のテクスチャを変更するためのアーティストの作業負荷を減らすことです。プロジェクト全体をリニアワークフローに切り替えてから、Gamma空間の仕様に従って作成されたテクスチャがsRGBをチェックしないで、新しく作成されたコンテンツがsRGBをチェックします。このように問題主のアイデアを理解することが正しいかどうかは、わかりません。
最初に明確にすることは、リニアワークフローのワークフローはテクスチャだけに対するではありません。テクスチャが線形であるかどうかは、そのほんの一部です。リニアワークフローの根本的な変化は、光の重ね合わせの計算です。
簡単な実験を行います。テクスチャがない場合、光の強度は1、Cubeの色は（128、128、128）、リニアワークフローとGamma空間でのレンダリング効果：（Unity 5.6バージョン、Standardマテリアル）
どちらが線形でどちらがGamma空間ですか？ これは重要ではありません。重要なのは2つが異なるということです。つまり、2つの空間にある単純な色は、1つのランプの照明効果でも異なります。では、アーティストがGamma空間で制作したアート効果は、リニアワークフローでの以前の効果と完全に一致することをどのように確保できますか？
個人的には難しいと思います。
テクスチャ付けの例を見てみましょう：
随意に見つけたテクスチャですが、内容に気にしないでください。効果を比較したら、それらの間に違いがあることがわかります。どのような状況でそれらは同じですか？Unlitマテリアルを選択します。
説明したいのは、リニアワークフローのワークフローはテクスチャ形式に関連しているだけでなく、照明のレンダリングにも大きな影響を与えることを説明したいと思います。したがって、少なくともシーンでは、2つの色空間方法を混用することは個人的にはお勧めしません。
もちろん、クライアントにとっては「正しい」とは言えませんが、混ぜた後、効果は大丈夫だとアーティストは考えますが、このような解決策が使えないという意味ではありません。 ただし、事前に考慮すべき問題がある場合があります。
1）効果のフォローアップ調整は少し面倒かもしれません、そして一方が他方を失う状況があるでしょう。
2）リニアワークフローとGamma空間では常に別々の制作経験があるため、アート制作が混乱になる可能性があります。例えば、リニアワークフローのテクスチャの明るさは一般より明るくなります。色空間の混用も、アーティストに迷惑をさせたり、新しいアーティストが以前のリソースの維持に問題を起こしたりする可能性があります。したがって、これを実行する場合は、別々に2つの空間の使用範囲を定義するのが最善です。
3）経験から、ゲーム開発であろうと恋であろうと、長期的な痛みは短期的な痛みよりも悪いことがわかります…
Anyway、個人的にはお勧めしませんが、結局のところ、試すから学ぶことができますので、自分のプロジェクトで試してみて、思いつく質問に満足できる答えがあるかどうかを確認することをお勧めします。これを色空間に混ぜることができます広い道から出て行くことができるかもしれません。
②
Unityプロジェクトはリニアワークフローをカットしているため、線形グラフ（法線グラフ、強度グラフ、パラメーターグラフなど）がsRGBをチェックしなくで、Gammaグラフ（色度など）がsRGBをチェックすることになります。この方法でGammaの処理方式を復元したい場合、それは無理です。
動画
Q3: 私たちのテストでは、Unityを使用してパッケージ化すると正常に再生できることがわかりましたが、Unityコマンドラインを使用してパッケージ化すると、VideoPlayerがMP4動画を再生しているときに、パッケージ化されたIL2CPPパッケージがブルースクリーンで表示されますが、音が鳴り、異常は見つかりません。この問題に遭遇したことがありますか？
adbコマンドを携帯電話に接続してAndroidシステムのログを取得し、ReportExceptionを検出しました：UnityLogError Could not find material Hidden/VideoDecodeAndroidが異常になります。ローカルマニュアルのGraphicsSettingを確認し、このシェーダーの設定がないことを確認しました。
ただし、フロントエンドUnityがIL2CPPを直接パッケージ化するのは正常であり、コマンドラインにこの異常が発生します。手動でShaderを追加してGrahpicsSettings.assetを保存した後、コマンドラインパッケージは正常になります。
エディター
Q5:アーティストの同僚が多くのプレハブをアップロードした後、プログラムの同僚がUnityプロジェクトを開き、Consoleは上記のようにすぐに多くのエラーメッセージを報告しましたが、どのPrefabまたはAssetがそれらを引き起こしたかを示していませんでした。
①
除数が0であるために発生する問題により、アーティストによって生成されたリソースを確認できます。一部のリソース値は無限に小さくなるか無限になります。このとき、コリジョンボックスの計算でエラーが発生します。
②
MisakaさんのMonoHookerをお勧めします。
CreatePreviewForAssetメソッドにHookし、パラメーターを出力します。
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com