fc2ブログ
ヽ|∵|ゝ(Fantom) の 開発blog? ホーム »C#
このページの記事一覧

【Unity】【C#】HDR Color を計算(変換)する  


 現在の VRM Live Viewer にはパーティクルの発光色を設定できる機能があり、HDRカラーピッカーが実装されているのだけど、これを作ったときのメモ。

 そもそも Unity にはエディタ上で普通に HDRカラーピッカーが入ってるのだけど、なぜか API にはそういった Utility クラスが無いんだよね。なので、ググってたら、いくつか見つけたので、それを少しばかり使いやすくした例。

(参考) How to Get / Set HDR Color intensity


(※) Unity 2020.3.26f1 / Windows11(x64) で確認



■LDR Color と intensity → HDR Color に変換する

 参考資料を見てみると、どうやら HDR Color の計算は LDR Color の アルファを除いた RGB の各要素に 2 の intensity 乗(= 2intensity) を掛ければ良いようだ。実際にやってみたら、Unity エディタ上のカラーピッカーの色とも合致する。なので、変換する拡張関数を定義すると以下のようになる。

(参考) How to Get / Set HDR Color intensity

●LDR Color と intensity → HDR Color に変換する
using UnityEngine;

namespace Exsample
{
public static partial class Extensions //※クラス名は任意
{
/// <summary>
/// LDR Color と intensity → HDR Color に変換する
/// https://answers.unity.com/questions/1652854/how-to-get-set-hdr-color-intensity.html
/// </summary>
/// <param name="ldrColor">LDR Color</param>
/// <param name="intensity">輝度(intensity)</param>
/// <returns>HDR Color</returns>
public static Color ToHDRColor(this Color ldrColor, float intensity)
{
var factor = Mathf.Pow(2, intensity);
return new Color(
ldrColor.r * factor,
ldrColor.g * factor,
ldrColor.b * factor,
ldrColor.a
);
}
}
}

 これは参考資料をそのまま拡張メソッドにしただけである。intensity = 0 のときは 20 = 1 なので、元のままとなるね。2 の intensity 乗(= 2intensity) というのは、そういうものと覚えておけば良いだろう。

(参考) How to Get / Set HDR Color intensity



■HDR Color → LDR Color と intensity に分離する

 次は前述の HDR Color 変換とは逆で、HDR Color を LDR Color と intensity に分離する計算だ。といっても参考資料そのままでも良いので、ここでは少しだけ使いやすく、戻り値を Tuple 型(.NET 4.x)にして、表現の値を255値にした例を書いておこう。

●HDR Color → LDR Color と intensity に分離する
using UnityEngine;

namespace Exsample
{
public static partial class Extensions //※クラス名は任意
{
private const byte k_MaxByteForOverexposedColor = 191; //internal Unity const

/// <summary>
/// HDR Color を baseColor, intensity(exposure) に分離する (Tuple)
/// https://answers.unity.com/questions/1652854/how-to-get-set-hdr-color-intensity.html
/// ※overExposed = 255 を与えると直感的になる : (白) baseColor = RGBA(1.000, 1.000, 1.000, 1.000), intensity = 1
/// Unity デフォ = 191 で HDR Color ピッカーと同等 : (白) baseColor = RGBA(0.749, 0.749, 0.749, 1.000), intensity = 1.416925
/// </summary>
/// <param name="linearColorHdr">HDR Color</param>
/// <param name="overExposed">internal Unity const = 191 (デフォルト: 255)</param>
/// <returns>(LDR Color, intensity)</returns>
public static (Color32, float) DecomposeHdrColor2(this Color linearColorHdr, byte overExposed = 255)
{
Color32 baseLinearColor32 = linearColorHdr; //※暗黙変換には型が必要
var exposure = 0f;

var maxColorComponent = linearColorHdr.maxColorComponent; //※たぶん (r,g,b) 内で一番高い値 → 1f を超えてたら HDR となる

// replicate Photoshops's decomposition behaviour : Photoshopの分解動作を複製する
if (maxColorComponent == 0f || maxColorComponent <= 1f && maxColorComponent >= 1 / 255f) //1/255 = 0.003921568627451
{
exposure = 0f;
baseLinearColor32.r = (byte)Mathf.RoundToInt(linearColorHdr.r * 255f);
baseLinearColor32.g = (byte)Mathf.RoundToInt(linearColorHdr.g * 255f);
baseLinearColor32.b = (byte)Mathf.RoundToInt(linearColorHdr.b * 255f);
}
else
{
// calibrate exposure to the max float color component : 最大フロートカラーコンポーネントへの露出を調整します
var scaleFactor = overExposed / maxColorComponent;
exposure = Mathf.Log(255f / scaleFactor) / Mathf.Log(2f);

// maintain maximal integrity of byte values to prevent off-by-one errors when scaling up a color one component at a time
baseLinearColor32.r = Math.Min(overExposed, (byte)Mathf.CeilToInt(scaleFactor * linearColorHdr.r));
baseLinearColor32.g = Math.Min(overExposed, (byte)Mathf.CeilToInt(scaleFactor * linearColorHdr.g));
baseLinearColor32.b = Math.Min(overExposed, (byte)Mathf.CeilToInt(scaleFactor * linearColorHdr.b));
}

return (baseLinearColor32, exposure);
}
}
}

//メインでは…
//var (baseColor32, intensity) = emissionColor.DecomposeHdrColor2(); //overExposed = 255

 コードも参考資料とほとんど変わらない。ただ、Unity エディタで HDRカラーピッカーを使っている時、Intensity の値を上げると、再び開き直した時、なぜか 191 になってるのが不思議だったが、どうやら内部の定数値「k_MaxByteForOverexposedColor = 191」が効いていたようだ。なので overExposed で 255 をデフォルトで与えることによって(RGB 要素で 255 を超えた場合の表現方法らしい)、より LDR Color が直感的になったので変更している。Unity エディタと同じにしたければ、overExposed = k_MaxByteForOverexposedColor (191) を引数に与えれば良い。元コードのコメントを読むと、191 は PhotoShop に合わせた値らしいが、色コード("#FFFFFF" のような形式)として扱う場合には、ちょっと使いづらいんだよね…。

(参考) How to Get / Set HDR Color intensity



■HDR Color から intensity のみを取り出す

 これは前述の HDR Color → LDR Color と intensity に分離する の縮小版みたいなものだ。実際に DecomposeHdrColor2() のコードの一部のみを抜き出した感じとなる。輝度(Intensity)だけ欲しいときなど、短く書けるので一応載せておこう(もちろん、DecomposeHdrColor2() を使って intensity だけを得ても同じ)。

●HDR Color → LDR Color と intensity に分離する
using UnityEngine;

namespace Exsample
{
public static partial class Extensions //※クラス名は任意
{
private const byte k_MaxByteForOverexposedColor = 191; //internal Unity const

/// <summary>
/// HDR Color から Intensity のみを取得する
/// https://answers.unity.com/questions/1652854/how-to-get-set-hdr-color-intensity.html
/// ※overExposed = 255 を与えると直感的になる : (白) baseColor = RGBA(1.000, 1.000, 1.000, 1.000), intensity = 1
/// Unity デフォ = 191 で HDR Color ピッカーと同等 : (白) baseColor = RGBA(0.749, 0.749, 0.749, 1.000), intensity = 1.416925
/// </summary>
/// <param name="hdrColor">HDR Color</param>
/// <param name="overExposed">internal Unity const = 191</param>
/// <returns>輝度(intensity)</returns>
public static float ExtractIntensity(this Color hdrColor, byte overExposed = 255)
{
var maxColorComponent = hdrColor.maxColorComponent;
var scaleFactor = overExposed / maxColorComponent;
return Mathf.Log(255f / scaleFactor) / Mathf.Log(2f);
}
}
}

 これは参考資料の最後にあるコードと同じ。これも DecomposeHdrColor2() と同じように、overExposed の引数を k_MaxByteForOverexposedColor (191) にすれば、Unity エディタ上の HDRカラーピッカーと同じ値になる。

(参考)
How to Get / Set HDR Color intensity







(関連記事)
【Unity】【C#】ガンマ(Gamma, sRGB) - リニア(Linear) 値の相互変換
【Unity】色形式:Unity の Color と Android の ARGB(int32) の相互変換をする


関連記事
スポンサーサイト



category: Unity

thread: ゲーム開発

janre: コンピュータ

tag: Unityライブラリ  C#  グラフィックス 
tb: 0   cm: --

【Unity】【C#】文字列の暗号化・復号化を簡単に行う  


 今回は手軽にデータの暗号化・復号化が行える「Unity Cipher」というオープンソースライブラリを紹介しよう。

 実際にはコードを見てみると、特に Unity 以外でも使えそうだが、デモ(Examples)が Unity で作られているからだろうか?とても簡単で強固なセキュリティが確保できるので、パスワードや何らかのアカウントデータなどを扱うアプリなら、導入を検討した方が良いだろう。

 詳しい内容などはライブラリ作者直々の記事があるので、そちらを参考にして欲しい。ここではどちらかと言うとオープンソースライブラリなど、余りサードパーティを利用したことのない人のためにも、細かい導入手順を書いておく。

Unity(C#) で「正しい」暗号化処理をするライブラリを作成しました

(※) Unity 2019.2.18f1 / Windows10(x64) で確認

※掲載時点 1.2.0 では 2019.2.17f1 で作られているようだが、コードにバージョン依存性はあまり無いと思うので、少し古い Unity バージョンでも問題なく使えると思う(少なくとも Unity2017 では使えた)。


■ライブラリのインポート

 まずは github でライブラリをダウンロードしよう。「Clone or download」から zip をダウンロードできるので、落としたら解凍して、「UnityCipher.unitypackage」を Unity にインポートする(プロジェクトビューにドラッグ&ドロップすると楽)。



Unity CipherMIT License



 インポートできたら、「Assets/UnityCipher/Plugins/UnityCipher/」フォルダにある cs ファイルがライブラリ本体となる。
 デモ(Assets/UnityCipher/Examples/ 以下)が必要無いなら、これらファイルだけ導入しても構わない。



 ちなみに「Plugins」フォルダに入れておくことは、スクリプトのコンパイル順に関係する事なので、汎用的なライブラリは Plugins 以下に配置されていることが多い → UniRxAssetStore版)等

特殊フォルダーとスクリプトのコンパイル順 (Unity Manual)

 簡単な使い方はデモを見るのが早いかも知れない。「Assets/UnityCipher/Examples/ 」に「Example」シーンがあるので、起動してみると良いだろう。



 オススメは「Rijndael」だ。サンプルコード上では「Examples/Scripts」フォルダ以下の「RijndaelContent.cs」を開けば、だいたい使い方がわかると思う。例えば、暗号化・復号化の部分を抜き出せば次のようになる。

●UnityCipher での暗号化・復号化
using UnityCipher;

//暗号化
string encrypted = RijndaelEncryption.Encrypt(planeText, passwordText);

//復号化
string plane = RijndaelEncryption.Decrypt(encryptedText, passwordText);

(例えば、planeText = "hogehoge", passwordText = "password" とすると)
encrypted = I8WWDJbFzGCN4OiauU7H1w2PSOTCFDZUIMXD000pA3bq4T4g06lNvzxSlW8qQEMF4agkUfrnFfL4eXRd9AtaSlI2TZpuwZF7dH1+sYwaNBvOty2ImJJuaqVWEdWbjfB6

(次に、暗号化[エンコード]された文字列(encrypted)を復号化すると[→ passwordText は同じものを使う])
plane = "hogehoge"

 このライブラリの優れた所は、デモでもう一度同じ文字列を暗号化して貰えるとわかると思うが、毎回違う文字列が生成される点だ(ライブラリ作者の記事に詳しく書いてある)。つまり文字列の並びから中身は想定はされずらいので、セキュリティ的にも安全性が高くなる(世の中には本当に凄い人もいるもので、実際に学会などで新しい暗号化方式を、何度かパターンを見ただけでやぶってしまう人もいるという…)。

 また注意点としては、当たり前だがパスワードは難しいものにしておいてね…と(笑)("password" とか "admin" とかはダメですよ(笑))。

 Unity においては例えば PlayerPrefs に使っても良いかも知れない。ただし、文字列が長くなるので、Android/iOS には大量にやらない方が良いかも(Android は ~.xml, iOS は ~.plist に書き出されるため)。もしキーと値を両方暗号化したいなら、キーには「ハッシュ値」を使うのもアリだろう。

【C#】MD5, SHA1, SHA256, SHA384, SHA512 等のハッシュ値を生成する
【Unity】PlayerPrefs, persistentDataPath, temporaryCachePath の保存場所(パス)一覧表

 また、github の Usage にも書いてあるが、byte[] も使えるので、バイナリデータを暗号化するにも良いだろう。使い方は同様なので難しくはないと思う。





(関連記事)
【C#】MD5, SHA1, SHA256, SHA384, SHA512 等のハッシュ値を生成する
【C#】GUID の生成と書式
【Unity】PlayerPrefs, persistentDataPath, temporaryCachePath の保存場所(パス)一覧表


関連記事

category: Unity

thread: ゲーム開発

janre: コンピュータ

tag: Unityプラグイン  Unityオープンソースライブラリ  C# 
tb: 0   cm: --

【Unity】【C#】Addressable Assets でキー(アドレス)の存在(登録)を調べる  


 新しいリソースの管理のシステムである Addressable Assets をちょっといじってみた。しかしなぜか、素材のアドレス(キー)が存在しないときに出る InvalidKeyException が try~catch で捕捉できないので、登録の有無の検出ができなかった…(掲載時点:Addressables System 0.5.3-preview)。


InvalidKeyException encounterd in operation UnityEngine.ResourceManagement.CompletedOperation`1[UnityEngine.Texture], result='', status='None', valid=True, location=..
UnityEngine.AsyncOperation:InvokeCompletionEvent()

InvalidKeyException: Exception of type 'UnityEngine.AddressableAssets.InvalidKeyException' was thrown., Key=hogehoge
UnityEngine.AsyncOperation:InvokeCompletionEvent()

 まだ preview 版なので、単なるバグなのかも知れないが、少し不便と感じたのでググってみたら、フォーラムにも同じ内容があった。

Can I ask Addressables if a specified key (addressable name) is valid?

 まぁそのうち、ちゃんとエラー捕捉できるようになったり、「Addressables.HasKey()」みたいなのができそうな気がするが、今使うには簡単なものを用意しておくのも良いだろう。



(※) Unity 2018.3.2f1 / Addressables System 0.5.3-preview / Windows10(x64) で確認



■Addressable Assets にアドレス(キー)が存在するか否か?を返すメソッドを定義

 フォーラムにある「AddressableResourceExists」でも判別可能ではあったが、そのすぐ下に Unity の中の人からのアドバイスが書かれていたので、試しにやってみた。

What you have above probably could work. But the thing I would actually recommend is to just do Addressables.LoadAsset<IResourceLocation>("key");

This will not load your asset, but will load the location that points to your asset. If your key is valid, then you'll get a valid location back. Otherwise you will not. You can keep and use that location (doing LoadAsset<GameObject>(myNewLocation)) or you can just discard it and continue to load with key once needed.

 Google翻訳すれば『これはアセットをロードするのではなく、アセットを指す場所をロードします。キーが有効であれば、有効な場所に戻ります』となるが、要するに「存在位置が示されればアセットは存在する」ということだろう。

●Addressable Assets にアドレス(キー)が存在するか否か?
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement;

public static class AddressablesUtil { //※クラス名は任意

// (参考) https://forum.unity.com/threads/can-i-ask-addressables-if-a-specified-key-addressable-name-is-valid.574033/
// http://fantom1x.blog130.fc2.com/blog-entry-319.html
/// <summary>
/// Addressable Assets にアドレス(キー)が存在するか否か?
/// </summary>
/// <param name="key">アドレス(キー)</param>
/// <returns>true = 存在する / false = 存在しない</returns>
public static bool Exists(string key)
{
return Addressables.LoadAsset<IResourceLocation>(key).Status == AsyncOperationStatus.Succeeded;
}
}

 やってみたら、どうやら存在しないキー(アドレス)を指定したときには「AsyncOperationStatus.Failed」になるみたいなので(まだ何もしてないときは None)、これだけで存在有無は確認できそうだ。Addressables.LoadAsset() の戻値:IAsyncOperation<IResourceLocation> は null は出ないみたいなので、チェックは省略した。

 使用例を簡単に書くと以下のようになる。

●Exists() の使用例(Addressable Assets からテクスチャを読み込んで RawImage に入れるサンプル)
using UnityEngine;
using UnityEngine.UI;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement;

public class AddressablesTest : MonoBehaviour { //※クラス名は任意

public RawImage image;

void Start () {
string key = "hogehoge"; //アセットのアドレス(キー) ※任意

if (AddressablesUtil.Exists(key))
{
Addressables.LoadAsset<Texture>(key).Completed += op => {
image.texture = op.Result;
};
}
else
{
Debug.LogWarning("Invalid key = " + key);
}
}
}




■Task と連携して非同期で読み込むメソッドを定義

 ついでに前述した「Exists」と以下の拡張メソッドを組み合わせて、動作を Task 化し、アドレスの存在検出して、有れば素材を、無ければ default(この場合は基本的に null)が返ってくる関数を定義してみよう。これを使うとかなり楽に非同期ロードができるようになる。Task 化メソッドは以下の記事(IAsyncOperationExtensions.GetAwaiter<T>)をまるっとコピーして欲しい。
 
【Unity】Addressable Asset Systemのリソース読み込みをasync/await対応する

●アドレス(キー)が存在するならロードし、無ければ default (= null) を返す
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement;
using System.Threading.Tasks; //※Task ならこっち
//using UniRx.Async; //※UniTask ならこっち

public static class AddressablesUtil { //※クラス名は任意

// (参考) https://qiita.com/toRisouP/items/e03b53e8eb6af06fbcbf (※IAsyncOperationExtensions.GetAwaiter<T> を利用)
// http://fantom1x.blog130.fc2.com/blog-entry-319.html
/// <summary>
/// アドレス(キー)が存在するならロードし、無ければ default (= null) を返す
/// </summary>
/// <typeparam name="T">素材の型</typeparam>
/// <param name="key">アドレス(キー)</param>
/// <returns>取得した素材</returns>
public static async Task<T> LoadOrDefault<T>(string key) where T : class
{
if (Exists(key)) //※前述のメソッド
return await Addressables.LoadAsset<T>(key); //※IAsyncOperationExtensions.GetAwaiter<T> が必要
return default;
}
}

 もちろん、Task を UniTask(UniRx が必要)に置き換えることも可能だ。

 簡単な使い方としては以下のようにしても良いだろう(※かなり適当なので、好きに書き換えて(笑))。

●LoadOrDefault()の使用例(Addressable Assets からテクスチャを読み込んで RawImage に入れるサンプル)
using UnityEngine;
using UnityEngine.UI;
using UnityEngine.AddressableAssets;
using UnityEngine.ResourceManagement;
using System.Threading.Tasks; //※Task ならこっち
//using UniRx.Async; //※UniTask ならこっち

public class AddressablesTest : MonoBehaviour {

public RawImage image;

void Start () {
string key = "hogehoge"; //アセットのアドレス(キー) ※任意
LoadImage(key); //※Task なら警告が出る
//LoadImage(key).Forget(); //※UniTask なら警告を消せる
}

async Task LoadImage(string key)
{
var tex = await AddressablesUtil.LoadOrDefault<Texture>(key);
if (tex != null)
{
image.texture = tex;
}
else
{
Debug.LogWarning("Invalid key = " + key);
}
}

}

 もちろんこれも UniTask(UniRx が必要)に置き換えても良い。

 待機したいなら、async/await を付ければ良い(※この例ではあまり意味がないが(笑))。
async void Start () {
string key = "hogehoge"; //アセットのアドレス(キー) ※任意
await LoadImage(key);
}



 まだ、Addressable Assets はプレビュー版だからか、使い勝手が微妙な所もあるが、いずれは Resources の代わりに使われるようになるだろう。Addressable Assets ははじめから非同期ロードだったり、プリロード機能もあったりして便利なので、今から慣れておくのも良いかも知れない。





(関連記事)
【Unity】【C#】AssetBundleManager を WebGL で使う・エラー対処法
【Unity】【C#】アセットバンドルのキャッシュを調べて不要なものを消す


関連記事

category: Unity

thread: ゲーム開発

janre: コンピュータ

tag: Unityライブラリ  Unityトラブルシューティング  C# 
tb: 0   cm: --

【Unity】【C#】LINQとfor, ListとArray(配列)での実行速度を比較してみる  


 LINQ や List はとても便利だけど、実行速度が遅いという欠点があるので、改めてよく使いそうなコードで比較してみたのを記録しておく。

 私はよくこういう実験をするのだが、気をつけて欲しいのは実行環境やマシンスペック、言語などによっても結果は異なるという点だ。また、コンパイラ等もバージョンによって最適化が入ったりして、高速になる場合もある。今回は C# で Unity 上(主にエディタ上)での実験になってるが、実機ではまた異なる結果が出る場合があるので、あくまでも目安として考えて欲しい。

 ちなみに元ネタではないが、以下の記事でも通常の for, foreach 構文と LINQ の ForEach を実験しているが、特に ForEach が遅かったのが記憶に残っていたので、改めて調べたキッカケだったりする(記事のバージョンが古いので)。だがしかし、現64bitバージョンでも値は2倍速くらいになっているが、結果(比率)は同じだった。例えば for に対してLNQ の ForEach はやはり2倍くらい遅い。こういったデータを公開してくれるのは非常に有り難い。

(参考)
【Unity】ループ構文の処理速度の検証結果
CPU のパフォーマンスに関する推奨事項:コストのかかる操作を避ける - LINQ を使わないようにする


(※) Unity 2018.2.1f1(エディタ上).NET 3.5 / Windows10(x64), Intel Core i5 x64 2.9GHz で確認



■LINQ と for 構文で比較

 ここでは簡単な数値計算でのフィルタと、全要素の文字列を LINQ と単純な for で比較してみよう。データには List を使っているが、Array(配列)にした方が速くなるのはとりあえず置いておいて欲しい(笑)。

 実際の測定方法は以下のコードを1つのメソッドにして、11回実行し、はじめの1回の結果を捨て、残りの10回の平均を出している。なぜはじめの1回を捨ててるかというと、アプリを起動したときには色々な初期化処理が動くので重くなり、測定値が不安定になるからだ(だいたい通常より値が大きくなる)。Unity に限らず、他のプラットフォームでも同じことがよく起こるので、その辺は覚えておくと良いかも知れない。



●LINQ の ForEach と for の単純アクセス(値取り出し)比較

 例えば、順次アクセスしていって、値を取り出すだけのコードを比較してみた。通常はその値を何らかで利用すると考えて欲しい。

①LINQ で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
List<int> list = Enumerable.Range(0, num).ToList();

//以下を測定
float startTime = Time.realtimeSinceStartup;

list.ForEach(i => {
int value = list[i];
});

float elapsed = Time.realtimeSinceStartup - startTime;

Debug.Log("1 : " + elapsed + " [s]"); //0.002561998 [s]

②for で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
List<int> list = Enumerable.Range(0, num).ToList();

//以下を測定
float startTime = Time.realtimeSinceStartup;

for (int i = 0; i < num; i++)
{
int value = list[i];
}

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("2 : " + elapsed + " [s]"); //0.001707292 [s]

1 : 0.002561998 [s]
2 : 0.001707292 [s]

 ただ値を取り出しただけで何もしてないが、実行速度は LINQ に比べて for は約1.5倍くらい速かった。要素数が少ないとき(50以下とか)にはあまり気にすることはないとは思うが、要素数が大きくなるほど、その差は大きく出る。大量のデータをスキャン、または変換など処理を施すのには LINQ はとても遅いので気をつけよう(プロコン問題などに使うとタイムアウトすることが多い(笑))。
List を配列にした方がもっと速い(約3.1倍:0.0008201599 [s])。



●LINQ と for でフィルタ(抽出)の比較

 例えば、連続した値の要素から、偶数だけを抽出するコードを比較してみた。

①LINQ で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 10000;
List<int> list = Enumerable.Range(0, num).ToList();

//以下を測定
float startTime = Time.realtimeSinceStartup;

List<int> list2 = list.Where(e => e % 2 == 0).ToList();

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("1 : " + elapsed + " [s]"); //0.0007956981 [s]

②for で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 10000;
List<int> list = Enumerable.Range(0, num).ToList();

//以下を測定
float startTime = Time.realtimeSinceStartup;

List<int> list2 = new List<int>(num);
for (int i = 0; i < num; i++)
{
int value = list[i];
if (value % 2 == 0)
list2.Add(value);
}

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("2 : " + elapsed + " [s]"); //0.0002808333 [s]

1 : 0.0007956981 [s]
2 : 0.0002808333 [s]

 測定部分では、LINQ はとてもシンプルで、for 文は長々と書いている感じだが、実行速度は LINQ に比べて、単純な for の方が約2.8倍くらい速かった(笑)。特に要素数が大きいときにはこの傾向は強くなる。for 文は昔ながらのとてもダサい(笑)文に見えるが、実は高速なので、Unity のようなフレームアプリケーションには向いているかも知れない(笑)。



●LINQ と for で全要素文字列変換の比較

 例えば、一定の文字列があり、それらを全部小文字にするコードを比較してみた(100個書くのが面倒くさい(笑)ので 10個x10=100個にしている)。

①Linq で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
string[] words = {
"Apple", "Banana", "Candy", "Doughnut", "Egg",
"Fish", "Grape", "Honey", "IceCream", "Jelly"
};
List<string> list = Enumerable.Repeat(words, 10).SelectMany(a => a).ToList(); //10x10=100個
int num = 1000;

//以下を測定
float startTime = Time.realtimeSinceStartup;

for (int i = 0; i < num; i++)
{
List<string> list2 = list.Select(e => e.ToLower()).ToList();
}

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("1 : " + elapsed + " [s]"); //0.04769385 [s]

②for で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
string[] words = {
"Apple", "Banana", "Candy", "Doughnut", "Egg",
"Fish", "Grape", "Honey", "IceCream", "Jelly"
};
List<string> list = Enumerable.Repeat(words, 10).SelectMany(a => a).ToList(); //10x10=100個
int num = 1000;

//以下を測定
float startTime = Time.realtimeSinceStartup;

for (int i = 0; i < num; i++)
{
int length = list.Count;
List<string> list2 = new List<string>(length);
for (int j = 0; j < length; j++)
{
list2.Add(list[j].ToLower());
}
}

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("2 : " + elapsed + " [s]"); //0.03735647 [s]

1 : 0.04769385 [s]
2 : 0.03735647 [s]

 測定部分では、for 文の方では list.Count を length に入れて使っているが、こうすると、ループのたびにプロパティを読み出しに行かなくて済むため、ほんのわずかだが速くなる。生成された list2 の方は特に何も使ってないが、通常は何か処理が入ると考えて欲しい。

 結果はだいたい、LINQ より for で書いたほうが約1.3倍くらい速くなった。思ったより速度は変わらないね。要素数が少ないなら、どちらを使っても良さそう。

 ちなみに for の例で List を全て Array で書き直すとわずかに速くなる(約1.4倍:0.03489325 [s])



■List と Array(配列)で比較

 ここではデータ格納先となる List と Array(配列)で速度を比較してみよう。

 これも同じ様に、11回実行し、はじめの1回の結果を捨て、残りの10回の平均を出した測定値だ。単純なものしか書いてないが、実際には何らかの処理が他に入ると考えて欲しい。



●単純なアクセス(値取り出し)の比較

 例えば、順次アクセスしていって、値を取り出すだけのコードを比較してみた。通常はその値を何らかで利用すると考えて欲しい。

①List で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
List list = Enumerable.Range(0, num).ToList();

//以下を測定
float startTime = Time.realtimeSinceStartup;

for (int i = 0; i < list.Count; i++)
{
int value = list[i];
}

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("1 : " + elapsed + " [s]"); //0.00246439 [s]

②Array で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
int[] array = Enumerable.Range(0, num).ToArray();

//以下を測定
float startTime = Time.realtimeSinceStartup;

for (int i = 0; i < array.Length; i++)
{
int value = array[i];
}

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("2 : " + elapsed + " [s]"); //0.0008202791 [s]

1 : 0.00246439 [s]
2 : 0.0008202791 [s]

 ただ値を取り出しただけで何もしてないが、実行速度は List に比べて Array(配列)は約3.1倍くらい速かった(笑)。これも要素数が大きくなるほど、その傾向が強くなる。ライブラリ関数も配列を返すものが多いが、もしかしたらその利用の実行速度のためであるかも知れない(笑)。

 ちなみに、二分探索の Array.BinarySearchList.BinarySearch を比較してみると、要素数が多くなっても、ほとんど違いが出ないようだ。つまりアクセス回数に比例して速度が落ちていることがわかる。



●ソートの比較

 例えば、標準関数にあるソートで比較してみた。

①List で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
List<int> list = Enumerable.Range(0, num).ToList();
list.Reverse();

//以下を測定
float startTime = Time.realtimeSinceStartup;

list.Sort();

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("1 : " + elapsed + " [s]"); //0.00460794 [s]

②Array(配列)で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
int[] array = Enumerable.Range(0, num).ToArray();
Array.Reverse(array);

//以下を測定
float startTime = Time.realtimeSinceStartup;

Array.Sort(array);

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("2 : " + elapsed + " [s]"); //0.002492619 [s]

1 : 0.00460794 [s]
2 : 0.002492619 [s]

 結果は List に比べて Array(配列)でのソートの方が約1.8倍くらい速かった

 実際には C# のソートは要素数によってアルゴリズムが変わると聞いたことがあるので(例えばクイックソートは要素数が多いときはパフォーマンス良いが、要素数が少ないときは、それほど良くないと言われているので、アルゴリズムを変えるのは有効である)、利用する場合は一度実験しておく方が良いかも知れない。

50以下挿入ソート、5万以下マージソート、あとはクイックソート

 ちなみに、Reverse(要素の反転)の代わりに、後述するシャッフルを使った場合、以下のようになった。

1 : 0.007369685 [s]
2 : 0.003433919 [s]

 比率としては約2.1倍である。誤差を含めて約2倍と考えても良いだろう



●シャッフル(Fisher-Yates shuffle)の比較

 例えば、Fisher-Yates アルゴリズムを用いたシャッフル関数を定義し、それを利用して比較してみた。

①List で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
List<int> list = Enumerable.Range(0, num).ToList();

//以下を測定
float startTime = Time.realtimeSinceStartup;

list.Shuffle();

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("1 : " + elapsed + " [s]"); //0.00126977 [s]


//拡張メソッドを定義
public static class Extensions
{
//リストの要素をシャッフルする (Fisher-Yates shuffle)
public static void Shuffle<T>(this List<T> list)
{
for (int i = list.Count - 1; i > 0; i--)
{
int j = Random.Range(0, i + 1); //[0]~[i]
list.Swap(i, j);
}
}

//要素のスワップ
public static void Swap<T>(this List<T> list, int i, int j)
{
T tmp = list[i];
list[i] = list[j];
list[j] = tmp;
}
}

②Array(配列)で書いた場合
using System.Collections.Generic;
using System.Linq;
using UnityEngine;

//前準備
int num = 100000;
int[] array = Enumerable.Range(0, num).ToArray();

//以下を測定
float startTime = Time.realtimeSinceStartup;

array.Shuffle();

float elapsed = Time.realtimeSinceStartup - startTime;
Debug.Log("2 : " + elapsed + " [s]"); //0.0006387234 [s]


//拡張メソッドを定義
public static class Extensions
{
//配列の要素をシャッフルする (Fisher-Yates shuffle)
public static void Shuffle<T>(this T[] arr)
{
for (int i = arr.Length - 1; i > 0; i--)
{
int j = Random.Range(0, i + 1); //[0]~[i]
arr.Swap(i, j);
}
}

//要素のスワップ
public static void Swap<T>(this T[] arr, int i, int j)
{
T tmp = arr[i];
arr[i] = arr[j];
arr[j] = tmp;
}
}

1 : 0.00126977 [s]
2 : 0.0006387234 [s]

 このシャッフルは以前に書いたコードそのままである。

 結果は List に比べて Array(配列)でのソートの方が約1.9倍くらい速かった

 これも誤差を含めて約2倍と考えても良いだろう。



■結果一覧

 以上をまとめると表のようになる。

●LINQ と for 構文での比較
処理内容実装方法測定時間備考
単純なアクセスLINQ0.002561998 [s] 
for0.001707292 [s]LINQ より約1.5倍速い
フィルタ(抽出)LINQ0.0007956981 [s] 
for0.0002808333 [s]LINQ より約2.8倍速い
全要素文字列変換LINQ0.04769385 [s] 
for0.03735647 [s]LINQ より約1.3倍速い


●List と Array(配列)で比較
処理内容実装方法測定時間備考
単純なアクセスList0.00246439 [s] 
配列0.0008202791 [s]List より約3.1倍速い
ソートList0.00460794 [s] 
配列0.002492619 [s]List より約1.8倍速い
シャッフルList0.00126977 [s] 
配列0.0006387234 [s]List より約1.9倍速い


 今回は単純な反復での比較しかしてないが、他にもアルゴリズムも絡めると実行速度はまた変わる。しかしそれらは言語でも異なるので注意しよう。例えば C#, Java などは文字列操作は遅いが、Ruby, PHP, Perl などは文字列操作はとても速い(=変換も速い)。実際に「数値の桁数を求める」問題があったとして、C#, Java などでは「10で割って数をかぞえる」アルゴリズムが速いが、Ruby, PHP などは「文字列に変換して長さで数える」方が速かったりする。こういったものは測定してみないとわからない。

 プロコン問題(競技プログラミング:AtCoderとか)とか見てても、上のランクほど、for, while, 配列だけで解いている場合が多いのも納得がいく。やはり 0.1秒で合否が分かれる問題などでは(10万件のデータを2秒以内に処理するプログラムとか普通なので)、LINQ や List では遅すぎるというのは体験的に知っているのだろう(事実、大量のデータを処理するには LINQ は向いてないと思う※今後のバージョンアップで改善されるかも知れないが)。

 この結果だけ見ると「LINQ は使わないで単純な構文に」「List は使わないで配列に」のように思えてしまうが、要素数が少ないときはそれほど大差ないので(1000個を超えると結構差が出てくるが、50個以下で1回きりとかなら、それほど差は出ない)、実行速度が欲しいときに、改めて見直すのもヒントとして考えるのも良いだろう。

 Unity 公式ブログにも IL2CPP について『もしあなたが10000個の要素をもつリストをイテレートしたい場合は、Listの代わりに配列を使う方がよいでしょう。なぜならその方が生成されるC++コードがよりシンプルになり、また配列アクセスの方が単純に高速だからです。』とも書いてあるね。長さを変化させる必要が無いなら、機械的に配列にするのも良いかもね。

Update()を10000回呼ぶ

 またそのうち色々実験したら、追加しておく(笑)。





(関連記事)
【Unity】【C#】配列・リストのシャッフル
【Java】数値の桁数を調べる(べき乗の桁数・べき乗のべき乗の桁を調べる)
【C#】2次元配列(ジャグ配列・多次元配列)のソート
【Java】2次元配列のソート
【Java】配列要素の反転(reverse)
【一覧】Java, C#, PHP, Ruby, Python, JavaScript での Math.round(四捨五入・五捨六入)比較


関連記事

category: Unity

thread: プログラミング

janre: コンピュータ

tag: C#  検証 
tb: 0   cm: --

【Unity】【C#】Android で VRM(VRoid)を動的に読み込む  


 VRM Live Viewer にも利用しているが、元々は「プラグインを使って VRM を Android で読み込めるか?」という実験をしてみたら、スンナリと行けてしまったので次々とアイデアが浮かび、VRM Live Viewer をリリースするまでに至ってしまったという…(タイムスタンプを見ると、試しにライブステージ導入してから、アプリリリースまで4日しかかかってない←夢中になるといつの間にかアプリを完成させてしまうことも多い(笑))。


 まぁせっかくなので、VRMVRoid を Android でも読み込み、利用する方法を書いておこう。ちなみに VRM は VRChat やバーチャルキャストで使われるアバターフォーマットではあるが、リアルタイムで読み込むことができるので、あらかじめモデルをアプリに入れてビルドする必要もなく、読み込みもそれほど時間はかからないので、応用範囲は広いと思う。

 私は Unity4 の時代から MMD を Unity で動かしたり、一般公開されているモデルを実験で使ってたりしてたが、Unity ではいつもキャラのバリエーションが少ないな~と感じていたので、VRM で動的に読み込めるのは画期的だとさえ思う。例えば RPG でもアクションでも、好きなキャラで遊べるゲームとかも作れそうだしね(もちろん、大きさやコライダの判定などの問題もあるが、あくまで可能性として(笑))。アイデアは常に新しい発想から生まれるので、既成概念に捕らわれずに色々やってみると良いと思う。それがいつか新たな作品に繋がる。

 今回はあくまで Android で VRMVRoid を読み込む方法だけだが(どちらも "~.vrm" で扱うとして)、私が試したところ、一度 Unity 内に読み込んでしまえば、プラットフォームに関係なく扱えると思うので(見た目はシェーダなどのせいで多少変わることもあるが)、ひとつの方法として覚えておけば色々活用できるだろう。ちなみに VRM Live Viewer は Android版と Windows版を出しているが、ファイル読み込みやダイアログなどプラットフォーム固有のもの以外は全て同じだ。実際にシーン1つだけでビルドしている。つまり複数のプラットフォーム対応も簡単にできることがわかる。


(※) Unity 5.6.3p1 - 2018.2.1f1 / UniVRM 0.40 - 0.43 / VRoid Studio 0.1.1 - 0.2.8 / Windows10(x64) / Galaxy S7 Edge (Android 7.0) で確認



■UniVRM をインポートする

 Unity で VRM を読み込むには UniVRM というオープンソースが必要となる。ライセンスは「MIT License」となるので、その辺りは各自で確認して欲しい。ちなみにライセンス形態にも色々あるが、MIT License は比較的緩いライセンスだ。ついでに参考資料も載せておこう。

(参考)
GPL, LGPL, BSD などのOSSライセンスの違いと注意点まとめ
知らないと損をする6つのライセンスまとめ



 なお、新規プロジェクトで Android プラットフォームでビルドして試すなら、パッケージをインポートする前に「File>Build Settings...」であらかじめ「Switch Platform」で Android プラットフォームに切り替えておいた方が良いかも知れない。UniVRM に内包されているシェーダ(MToon 等)を再コンパイルしたりするのに結構時間がかかる(笑)。


 プロジェクトの準備ができたら、まずは UniVRM をダウンロードしよう。今回はアプリに動的に VRM を読み込むので UniVRM の本体「UniVRM-x.xx_xxx.unitypackage」(xxx はバージョンなど)の他に「UniVRM-RuntimeLoaderSample-x.xx_xx.unitypackage」のインポートも必要になる。本体「UniVRM-x.xx_xxx.unitypackage」を先にインポートしてから、ランタイムローダ「UniVRM-RuntimeLoaderSample-x.xx_xx.unitypackage」をインポートしよう。とりあえず VRM の動的読み込みに必要なものはこれだけで良い。






●API のアップデートが促されたら、「Go Ahead!」する




■VRM を動的に読み込んでみる

 UniVRM のインポートが終わったら、次にプロジェクトビューで「Assets/VRM.Samples/Scenes」で、シーン「VRMViewer」を開いてみよう。ビューワ自体は PC 用なのだが、これを改造することにより、Android 等他のプラットフォームの読み込み方法もわかると思う。



 ちなみに「VRM Live Viewer」はこのシーンを元ベースとしている(見た目もたいして変わってないのでわかると思うが(笑))。他の VRM 利用アプリを見てみると、たぶん同じようにこれを改造してるものが多い気がする。エクスポートできるアプリを作るなら、シーン「VRMRuntimeExporterSample」あたりを見てみると良いと思う。せっかくのオープンソースなのだから、遠慮なく使わせて頂こう(笑)。


 このシーンでは左上部にある「Open」ボタンを押すことにより、VRM を動的に読み込んで、シーン上にモデル(アバター)をロードすることができる。ただ、Windows 上なら 「PC, Mac & Linux Standalone」プラットフォームになってればそのまま使えるが、Android では無視される。この辺りから少し改造していこう。


1.スクリプトとしてはヒエラルキーで「Canvas」をクリックして、インスペクタで表示される「Viewer UI」にそのコードが書かれている。これを編集しよう。グレーアウトしてる「Script>ViewerUI」をダブルクリックすれば、Visual Studio で開かれる(シングルクリックなら、プロジェクトビューで移動できる)。



2.「ViewerUI.cs」を開いたら、検索で「OnOpenClicked」を探してみよう。これが前述した「Open」ボタンのイベントハンドラとなっている。ここのコードを見てみるとプリプロセッサディレクティブ(#if~文)でプラットフォームが分けられている。とりあえず Unity エディタ上でもテストできるようにディレクティブ(UNITY_EDITOR_WIN)を付け加えておこう。

void OnOpenClicked()
{
#if UNITY_STANDALONE_WIN || UNITY_EDITOR_WIN
var path = FileDialogForWindows.FileDialog("open VRM", "vrm", "glb", "bvh");
#else
var path = Application.dataPath + "/default.vrm";
#endif
・・・(略)・・・
}

 ちなみに「UNITY_EDITOR_WIN」とは「Unityエディタ上でかつ Windows である場合の条件」である。プラットフォーム依存コンパイルを上手く使えば、複数のプラットフォームを分別することも可能だ。まぁしかし、コードは見づらくなるので、機能まるごとみたいな場合は、クラスごとに用意するという手もある。今回は一部を改造して使うので、この方法でやっていこう。

プラットフォーム依存コンパイル


3.「UNITY_EDITOR_WIN」を入れたら、グレーアウトしていた文字が見えるようになったと思う。しかし「FileDialogForWindows.FileDialog」の方にエラーが出たかも知れない。まぁ、これも同じプラットフォーム依存なので、「FileDialogForWindows」部分にカーソルを合わせ、「F12」を押せば、クラスがまるごとグレーアウトしてるのがわかる。手順2と同じように「UNITY_EDITOR_WIN」を #if~文に追加しよう。

#if UNITY_STANDALONE_WIN || UNITY_EDITOR_WIN
using System;
・・・(略)・・・
#endif

namespace VRM
{
public static class FileDialogForWindows
{
#if UNITY_STANDALONE_WIN || UNITY_EDITOR_WIN
#region GetOpenFileName
[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
public class OpenFileName
{
・・・(略)・・・
}
・・・(略)・・・
#endif
}
}


 これでコンパイルが通るようになったと思う。一旦、Unityエディタに戻ってプレイしてみよう。「Open」ボタンを押して適当な「~.vrm」を読み込んで見ると良い。VRMニコニ立体で多く配布されているので、いくつかダウンロードしておくと良いだろう。「ニコニ立体ちゃん」ことアリシア・ソリッドはとても軽いのでテストするにはもってこいだ。自分で作った VRoid でも可能だが、髪の毛などメッシュが多いものほど、生成に時間がかかるようだ(なので「VRM Live Viewer」では非同期読み込みの方を利用している。非同期読み込みを使うには「.NET4.x」にする必要があるので、ここでは割愛)。

ニコニ立体ちゃん (VRM)





■VRM の動的に読み込みを Android に対応させる

 VRM を動的に読み込みに成功したなら、後は Android に対応させるだけだ。ファイル選択などはプラットフォームに依存するので、先に出てきた「FileDialogForWindows」のようなものが必要になるが、Unity の標準機能には無いので、ここではプラグインを使うことにする(自分で作ったものがあれば、それでも良い)。



 ここで紹介するプラグインは元々私がブログで公開していたものだが、様々なアプリで利用して貰えてるようなのでアセットストアにも提出したというものだ(既に GooglePlay 等で公開されてるアプリなどにも利用されている。「〇〇というアプリを作ってるんですが、使わせて貰って良いですか?」と聞かれるようになったので、気兼ねなしに使えるようにアセットストアにも出したという経緯もある)。AssetStore版GoogleDrive版に機能的な違いはないので(AssetStore版 はアセットストアの規約に合わせただけ)、どちらを利用しても構わない(※ここでは AssetStore版を例にしている)。



 セットアップは以前の記事にあるので、そちらを参照して欲しい。AssetStore版GoogleDrive版では一部ファイル名やパス、素材が違うくらいで、内容的には同じだ。注意点は「Plugins」フォルダを「Assets」直下に移動し、「Plugins/Android」フォルダにあるサンプルのマニフェストファイル(AndroidManifest.xml)を用意しておくということだ(テストだけなら、"AndroidManifest_demo.xml"[AssetStore版]、または"AndroidManifest_test.xml"[GoogleDrive版]を複製してリネームすれば良い)。

AssetStore版のセットアップ
GoogleDrive版のセットアップ


1.プラグインのインポートとセットアップの準備が済んだら、プロジェクトビューの検索で「StorageOpenFileController」のプレファブを見つけよう。見つけたら、これをヒエラルキーに置き、後述のコードを書くことにより、Android でもファイルの情報を受け取れるようになる。本来なら Android でストレージの読み取りなどにはパーミッションなども必要になるが、前述のデモのマニフェスト("AndroidManifest_demo.xml"など)を使ってる分には既に含まれている(「READ_EXTERNAL_STORAGE」または「WRITE_EXTERNAL_STORAGE」が必要。デモにはそれ以外の権限も含まれているが、通常は不要な権限は削除した方が良い→ユーザーにインストを拒否られる確率が高くなるため)。

※Unity2018 以降、Android 8.0 以上を対象にしている場合は、「File>Build Settings...>Player Settings...>Other Settings>Configuration>Write Permission」を「Exernal (SD Card)」にするか、「Android アプリでパーミッション(権限)要求をする」でパーミッション要求をした方が良いかも知れない(Unity2017 のときと違い、自動で出なくなった(?))。

(パーミッション)
Android アプリでパーミッション(権限)要求をする
READ_EXTERNAL_STORAGE(ファイル読み取り権限)
WRITE_EXTERNAL_STORAGE(ファイル読み書き権限)



2.次に「StorageOpenFileController」で取得したファイル名を受け取るハンドラを、元のコード「ViewerUI.cs」の「OnOpenClicked」に追加しよう。書き方は前述のコードに追加する形となる。Android の場合ディレクティブは「UNITY_ANDROID」となるので、それを追加し、「StorageOpenFileController」でストレージを開くコードを Android プラットフォーム用に書いておこう。「using FantomLib;」を入れておくことを忘れずに。

プラットフォーム依存コンパイル

using FantomLib;

・・・(略)・・・

void OnOpenClicked()
{
#if UNITY_STANDALONE_WIN || UNITY_EDITOR_WIN
var path = FileDialogForWindows.FileDialog("open VRM", "vrm", "glb", "bvh");
#elif UNITY_ANDROID
var path = "";
StorageOpenFileController storageOpenFileController = FindObjectOfType<StorageOpenFileController>(); //ここはインスペクタで登録できるようにしても良い
storageOpenFileController.Show(); //実機ではエクスプローラのようなもので、ファイル選択ができるようになる
#else
var path = Application.dataPath + "/default.vrm";
#endif
if (string.IsNullOrEmpty(path))
{
return;
}
・・・(略)・・・
}

※この例はやっつけ的なコードなので、「StorageOpenFileController」をインスペクタで登録できるようにしたり、任意にまとめたりして使って下さい(笑)。


3.ランタイム時では「StorageOpenFileController」は閉じられてから、コールバックで結果(選択されたファイルパス名)が返ってくるので、「UNITY_ANDROID」ディレクティブ内ではパスを空(path = "")にしていることに注意して欲しい。これはすぐ下にある「string.IsNullOrEmpty(path)」で一旦終了することを意味する。

 なので、取得したパスを受け取るハンドラを作成する必要がある。ここでは簡略のため、元の「OnOpenClicked()」内のコードを一部まるっとコピーして、もう1つ「OnStorageOpenFile()」というメソッドを定義した(メソッド名は任意)。

public void OnStorageOpenFile(string path)
{
if (string.IsNullOrEmpty(path))
{
return;
}

var ext = Path.GetExtension(path).ToLower();
switch (ext)
{
case ".gltf":
case ".glb":
case ".vrm":
LoadModel(path);
break;

case ".bvh":
LoadMotion(path);
break;
}
}

※UniVRM v0.40 以前は拡張子分岐は無いが、同じように「LoadModel(path)」を呼べば良い。

 実際には「StorageOpenFileController」をインスペクタで登録できるようにしたり、拡張子による分岐などは重複してるので「OnOpenClicked() → OnStorageOpenFile(path)」へ行くように書き換えても良いだろう。その辺りはお任せする(笑)。とりあえずはコード自体はこれで良い。


4.後はヒエラルキーに戻って「StorageOpenFileController」のコールバック「OnResult」に先程の「OnStorageOpenFile(String)」に登録しよう。これで一応完成である。ただし、実機でしか確認できないので、Android ビルドして動作確認してみよう。



5.「File>Build Settings...」を開いてシーン「VRMViewer」を追加してビルドしよう。ビルドに関してはいくつか注意点があるので、以下を参照して欲しい。

「要求 API Level」の設定
シーンを追加してビルドする
Unity 2018.1.0~1.6 での Gradle ビルドにおいて、「Cannot read packageName from~(パス)\AndroidManifest.xml」と出る。




 ここまでできれば、例えば以前の「VRoid(VRM)を動かす」のようにして、ゲームに使うことも可能だろう。1つ1つの技術は結構手間のかかるものだと思うが、プラグインも含め、全て無料でできるので、これを使わない手はない(笑)。今までにない新たな利用法を考えてみるのも良いだろう。

●実機(Android)で「ニコニ立体ちゃん (VRM)」を読み込んでみた所

ニコニ立体ちゃん (VRM)
(c) DWANGO Co.,Ltd. ニコニ立体ちゃんライセンス


 今回はただ VRM を読み込んで動的にアバターを召喚(笑)しただけだが、実際にスマートフォンで利用するには画面解像度・回転の対応やピンチなど、使い勝手を良くした方が良いだろう。プラグインにはそういったスマホらしい操作(ピンチ・スワイプ・ロングタップ等)の例も入っている。VRM Live Viewer の Android 版はまさにその使用例なので、動作確認にインストして動かしてみるのも良いだろう(またはプラグインのデモもQRコードからインストできるようにしてあるので参考に)。

※この記事のUnityアセットはプラグインとして配布されています。









(関連記事)
【Unity】VRM(VRoid)をライブステージで踊らせるアプリを作ってみた
【Unity】VRoid(VRM)をインポートして動かす
【Unity】Unity2018.3.2 にアップグレードすると見た目がおかしくなることがある
【Unity】AssetStore版 FantomPlugin のセットアップ
【Unity】Androidのトーストやダイアログ、通知、音声認識、ハード音量操作など基本的な機能を使えるプラグインを作ってみた


関連記事

category: Unity

thread: ゲーム開発

janre: コンピュータ

tag: VRM  VRoid  Unityオープンソースライブラリ  Unityプラグイン  C# 
tb: 0   cm: --


プロフィール

Social

検索フォーム

全記事一覧

カテゴリ

ユーザータグ

最新記事

リンク

PR

▲ Pagetop