以前に教えてもらった、C#のコードがどのようなILに変換されるのかを確認することが出来るWebサービスについてです。
時々ど忘れするので、こちらにもメモしておきます。
SharpLab
SharpLabは、コードをILやアセンブリに変換することが出来るサービスみたいです。
ところで、文字列のツナギ方で結構違いが出るんですね。
【Unity】Unityエディターを日本語化する方法（Unity2018.1）
今日Unite Tokyoで発表されたUnityエディターの日本語化についてです。
Unityエディターの日本語化
Unityエディターの日本語化対応方法が公式から公開されました。
エディターを日本語化することで、メニューアイテムが日本語化される他、殆どのUIの注釈等も日本語で表示されるようになります。
また一度日本語化すると日本語と英語は即座に変更可能になります。
Unityの機能はAPIと名前が一致している機能も多いので、コレのAPI何だっけってなった時には切り替えると良さそうです。
つまり、基本的に英語を使用するが、新しい機能を触るときには機能を把握するために日本語化する…といった事も可能という事です。
将来的には、日本語化の手順無しに日本語化ができるようになるみたいです。インストール時に言語もインストールする的な。
将来のバージョンでは正式にUnity Hubからのインストール時に言語が選択可能になる予定です。日本語以外のサポートも予定しています。
Unity Habからのインストールで日本語化が可能になりました。
大前提として、Unity 2018.1以降が必要です。
日本語化の手順
日本語化手順ですが、まずはUnityに対応したPOファイル（文字を置換する為のファイルみたいなもの）が必要です。
このPOファイルは現状２つの手順でインストールできます。
Unity未インストールの場合 もしくはUnityHubでインストールした場合
Unityがまだインストールしていない場合は、Unity Hubでインストールするのが一番楽です。
- Unity Hubを開き、Installを選択します。
- Official Releaseを選択します
- インストールしたいバージョンをDownloadします。
- 「Add Components to your install」ウィンドウが出て、追加で導入するコンポーネント（対応プラットフォーム）を選択するのですが、この一番下に言語パックがあるので、日本語にチェックを入れます。
Unity 2018.2から、追加で日本語の言語パックをインストール出来るようになっているみたいです
POファイルを入れたなら
POファイルを入れたならば、次はPreferenceを開きます。
これはMacならばUnity>Preference
MacならばEdit>Preferenceにあります。
Preferenceを開くと新しいLangageというメニューが追加されているので、それを選択、Editor Langageにチェックを入れ、Editor LangageをJapaneseに切り替えます。
最後に再起動します。
これでエディターの日本語化は完了です。
関連
これを期にソースコードに日本語使ってみても…？
→戦争
POファイルのURL
http://editor-localization.s3-website-ap-northeast-1.amazonaws.com/2018.1/ja.po
求ム フィードバック
以下、古いアプローチ
既にインストールしている場合(使用不可）
チラっと探しましたが残念ながらPOファイルを独自に配っている感じではなかったので、下の手順で取得します。
まずPOファイル*1をダウンロードします。これは下のURLから取得できますconnect.unity.com
次に指定のフォルダを作成します
フォルダパスはWindowsの場合は
{Unityをインストールしたファオルダ}\Editor\Data\Localization
Macの場合は
{Unityをインストールしたフォルダ}/Unity.app/Contents/Localization
となります。Unityをインストールしたフォルダは、例えばWindowsは
C:\Program Files\Unity\
C:\Program Files\Unity\Hub\Editor\{Unityエディターのバージョン}\
Macの場合は
/Applications/Unity/
/Applications/Unity/Hub/Editor/{Unityエディターのバージョン}/
あたりでしょう。
例えば「/Applications/Unity/Hub/Editor/2018.1.0f2/Unity.app/Contents/Localization」とか。
あとはダウンロードしたPOファイルをLocalizationフォルダ以下に格納します。
なお、Macの場合、アプリケーションの中に入るのに「パッケージの内容を表示」で中に入れます。
*1:多言語対応によく使われているファイル
【Unity】Timelineで物理演算の動きを使用するアイディア
今回はTimelineで物理演算の結果を使用する方法について考えてみます。
Timelineという機能
Timelineは時間やシーケンスに関する表現を実現するための機能です。Animationやオーディオの再生、スクリプトの制御などなど。
現在*1はアニメーショントリガーが無く少し面倒な所もありますが、Scriptで拡張可能なので割と何とかなったりします。
ちなみにTimeline自体は意外と軽いです。ただエディター上だと超重く、ロード時間も長いです。ビルドすると軽く、ロードも大幅に短縮されます。
またTrackが増えすぎると重くなるので、複数のTimelineに分割するアプローチが求められます。
Timelineはゲームを再生しないから効率的
さて、Timelineの強みは間違いなくエディターを再生せず動作を確認できる事です。
この動作によりゲームの再生→確認→修正の回転を、確認→修正（リアルタイムに反映）まで落とし込めるので効率的に動きを調整出来る訳です。
特にパーティクルやオーディオのタイミングは、ミリ秒違うだけで印象が大きく変わります。この数ミリ秒を調整のために毎回数秒～数十秒待つのは間違いなく高いコストです。
Timelineをうまく活用することで、調整すべき事を短いサイクルで作れる訳です
物理演算の動きはゲームの再生を要求する
とは言え、幾つかのコンポーネントによって実現する動き…例えばRigidbodyが実現する物理の動き等はTimelineだけではなくゲームを再生しないと得られない結果があるのも事実です。
例えばコップの落下タイミングに合わせてモデルを差し替えて音を出す（スローモーション付き）みたいな事をやろうと思うと、結構面倒です。破片の動きなど入ったら嫌です。
物が吹き飛ぶ動きをアニメーションカーブで実現しろとか言われたら、笑えます。
大抵の項目はPlayableBehaviourを記述したりITimeControlの定義で何とかなりますが、それでは実現できない項目があるのも事実。
それを今回は何とか出来ないか考えてみます。
Timeline上で物理演算を動かす
アイディアその1として、Timeline上で（ゲームを再生せず）物理演算を進めるアプローチを考えてみます。
Physics.Simulateで物理演算を手前で進めてしまうアプローチです。
考え方は単純で、シーン内全てのRigidbodyを集めてリセット可能なポイントを用意、あとはTimelineの時間までシークすれば…というものです。
オブジェクトの収集タイミングは「Preview」になったタイミングなので、座標の調整時にはPreviewをOFFにして調整します。
物理演算の動きをAnimationClipに保存する
アイディアその2は、AnimationClipに物理演算の動きを保存してしまうアプローチです。
これは二つの利点があります。
- 高速（負荷は物理演算を回すよりもとても安い傾向にある）
- 再現性（ゲーム用物理演算は、全ての環境で同じ結果を出すとは限らない）
ただし動かすオブジェクトの対象が多すぎると、エディターでオブジェクトをバインドするのにとても長い時間を要求する事もあります（数分のレベル）
このAnimationClipへの保存は、GameObjectRecorderを使用します。
コードはマニュアルそのまま行けます…というか、ちょくちょく変化するので、マニュアルを見て下さい。
Unity - Scripting API: GameObjectRecorder
全てのオブジェクトを物理演算で動かす→最低10FPS、オブジェクトをGameObjectRecorderでClipに変換してTImelineで動かす→最低80FPS #unity pic.twitter.com/IcGqK0mcTP
— 椿 (@tsubaki_t1) 2018年5月4日
インタラクティブな要素が無い 演出目的 なら、物理演算ぶん回すよりClipに変換してTimelineなりAnimatorなりで再生した方が良い印象 pic.twitter.com/GHuiwIzN3q
— 椿 (@tsubaki_t1) 2018年5月4日
お蔵入り確定してますが、一応「Timelineで再生中の動きを保存する」奴も置いておきます。
gist:d9e867be84b6f71176a4cf451028e86b · GitHub
*1:Unity2018.1
【Unity】物理演算を指定秒数 進める Physics.Simulate
今回は「シーンの物理現象をシミュレートする」という、一見分かりにくいAPIのPhysics.Simulateおよび Physics2D.Simulateついてです。
物理演算を指定秒数進めるAPI
このSimulate系のAPIは、簡単に言えば「物理演算を指定秒数、進める」事のできるAPIです。
通常は物理演算は「時間」によって進みますが、コレをスクリプトから超加速出来る訳です。
と言っても凄く癖のある機能で、
- RigidbodyもしくはRigidbody2Dに動作する
- FixedUpdateは呼ばれない
- 1回に進められる時間はFixedDeltaTime（0.0167秒）辺りが限界*1
- 他のRigidbody等の接触により結果が変わる事がある*2
という、中々に微妙な機能でもあります。
物理演算を進める
実際の操作を見てみます。
まずSimulate系のAPIですが、PhysicsのautoSimulateがOFFになっていることが前提条件です。ONだと動作しません。
まあ通常はInspectorよりはPhysics.autoSimulationで切り替えます。
コレを無効にすると、ゲームループ内で自動的にPhysics.Simulateが呼ばれなくなります。ただ MonoBehaviour .FixedUpdateは普通に呼ばれます。
まずはAutoSimulationを手前でやってみます。
下のコードでは、コンポーネントが有効なときにのみ物理演算のシミュレートが進みます。
次にn倍速にしてみます。0.1から1.5倍速あたり。これは1回のFixedUpdateで進める時間を調整すれば実現出来ます。
これは所謂Time.Timescaleと異なり、時間軸自体は通常通り動く所が面白いところです。現象だけ遅くする事が出来るので、世界をゆっくりにして云々するのも面白いかもしれません。気分はカブト*3
ただコレは、移動も物理演算に頼っている場合は、少し面倒なことになるかもしれません。単純に時間を弄る系はTime.TimeScale弄ったほうが最終的に楽できます。
物理演算を指定秒数進める・巻き戻す
さて、次は物理演算を指定秒数進めてみます。
時間指定はそれ程難しくはありません。指定時間に到達するまで秒数分ぶん回すだけです。パーティクルのPrewarmと同じようなものです。
強いて問題を上げるとすれば、高い負荷を計上する事があるという点ですが、まぁ。*4
では巻き戻しは？ …実は出来ません。
なので、「0秒の状態を保持しておいて、毎回0秒から指定秒まで演算を進める」という超力技で実現します。
下の2つは、このアプローチで巻き戻しを実現しています。
Physics2D.Simulateを使って、2D物理演算の"巻き戻し" #unity pic.twitter.com/LsTEGkSn2D
— 椿 (@tsubaki_t1) 2018年4月8日
Timelineで物理演算のプレビューするやつを作ってみる。ゲームを再生しなくても動きや結果が分かるのは楽しい #unity pic.twitter.com/qluMNi83ZY
— 椿 (@tsubaki_t1) 2018年4月15日
ただ、このときの動作が「他の物理演算の有無」により結構誤差が出ます。また負荷も半端ないので、実際にゲームで使う際にはTransform単位でキャプチャするほうが現実的かもしれません。
未来予測
最後に未来予測です。これも基本的には「巻き戻し」と同じ考え方です。
要するに、指定時間まで秒を進めて結果を回収する…という物です。
もっと軽くても良いよ！という場合は、下の設定にすると、大分負荷が減ります。
ただし計算精度も雑になります。まぁゲームのちょっとした弾道予想ではコチラの方が都合が良いかもしれません。
- float deltaTime = Time.fixedDeltaTime を float deltaTime = Time.fixedDeltaTime * 10; に変更
（計算制度を雑にする） - 予測したいRigidbodyのCollision DetectionをContinuous Dynamicに設定
感想
中々に楽しい機能ではあるのですが、大体において「重い」です。複数フレームでやるような処理を1フレームでやってるので、仕方がないとも言えます。
個人的には、用途としては「弾道予想」と「エディターで物理演算をレコードする時に使う（GameObjectRecorder）」くらいかなと思ってます。
今回は3Dの紹介でしたが、2Dでも同じAPIがあります。動作も同じです
関連
普通に高校で習う内容で落下位置を予測しようぜ！という話。
複雑な地形や複数のオブジェクト間の接触、それの最適化等を考えるとしんどい
たぶん見るであろう「壁貫通」について
TImeScaleで行うスローモーション
