2018年2月28日にパナソニックシステムデザイン株式会社主催にて、Panasonicグループ社内向けに行われたセミナー「Unity道場XRスペシャル in Panasonic」の講演資料です。 Unityを使用することで、ゲームのように動きの細やかなアプリケーションを自在に作成することができます。本講演では、ソフトウェアエンジニアがUnityアプリケーションを製作する上でつまづきやすい概念の違いを、具体例とともに説明します。ゲームエンジンならではの特徴を活用した、インタラクティブアプリケーション全般のプログラミング解説になります。 こんな人におすすめ ・Unityに興味のあるエンジニア 得られる知見 ・一般的に作られるアプリケーションとUnityの根本的な違い ・.NETおよびmonoに関する知識 ・意外な応用例

1. こんなに違う！
Unityアプリケーション講座
ユニティ・テクノロジーズ・ジャパン合同会社
安原祐二（やすはらゆうじ）

2. はじめに・連携の例

3. https://www.youtube.com/watch?v=lBPUENbQ5GI&feature=youtu.be&list=PLZDyxLlNKRY8MdgiUq45cZztn_f0EVz6c&t=120

4. このセッションでは
をお話しします。
プログラマに向けた実装上の注意点

5. プログラムはC#で記述
• バックエンドにMONOを使用
• .NET Framework 互換の環境
• C#で記述した（ILでビルドされた）.exe は Mono の環境で動作
する
• C#3.0/.NET3.5 と同等
• LINQ使用可
• C#6.0/.NET4.6 がExperimental（実験提供）で利用可
• async/await使用可

6. Mac で exe を
実行してみた
ビルド結果を
Macにコピー

7. １・実行タイミングについて

8. 普通のコンソールアプリケーションの例

9. ウインドウアプリケーションの例

10. Unityアプリケーションの例
初期化
繰り返し実行

11. Unityアプリケーションの例
block関数を呼んではいけない！

12. Arduinoの例
似ているけれど・・・

13. Arduinoの例
ブロック関数は特に問題ない

14. なぜブロック関数がいけないか
• 複数のオブジェクトを逐次扱うので、他
の実行も止めてしまう
• 描画処理も同期しているので、画面の更
新が遅れてしまう
• いわゆる「処理落ち」が起きてしまう

15. 短い処理を繰り返す
時間
処理

16. Unity の実行タイムライン
物理シミュレーション
void Update()
ユーザプログラム
アニメーションなど
レンダリング
待機
16.666 msec
入力
処理

17. Main Thread と Render Thread
void Update()
レンダリング（Platform非依存）
待機
16.666 msec
レンダリング（Platform依存）
Main Thread
Render Thread

18. 待機とは？V Syncを待つこと
VSync待ち
16.666 msec
処理

19. V Sync とは
ブラウン管方式のTVの垂直帰線を待つ（同期を取る）
現代でもそのプロトコルは生きている

20. 余談ですが・・
ブラウン管は電子ビームを照射していたので、光る点の時
刻から画面の位置を特定できた→ガンコントローラの原理

21. VSync で処理の重さの違いを吸収する
16.666 msec 16.666 msec 16.666 msec 16.666 msec 16.666 msec
処理 処理 処理 処理 処理
軽い 重い

22. • CPUのタイマーなどで垂直同期と同等の
処理を実現
垂直同期のないデバイスでは？

23. 要するに、毎フレーム更新が基本
• 必ず全画面を再描画
• 画面が変わっていなくても更新
• CPUのスリープ期間が短い
• 電力消費につながりやすい

24. ２・実行バイナリについて

25. C#の動作
• Mono （.NET互換プラットフォーム）で動作
• ビルド時に IL2CPP を指定するとIL から C++
に変換
• IL 実行時に .NET(mscorlib.dll）は参照しな
い
• 例外はUWP＆非IL2CPP

26. AOT? IL2CPP?
• AOT(Ahead Of Time)
• 事前コンパイル
• JIT(Just In Time)との対比として使用されるコトバ
• IL2CPP
• 弊社が開発した、IL を CPP に変換する技術
• いずれもネイティブ実行で仮想マシン実行ではない
• プログラムカウンタはCPUのものを使用

27. 事前コンパイルが前提
• 動的生成コードはまず動かない
• 式木(Expression Tree)や Reflection.Emit は使えない
• Emit以外のリフレクションはけっこう動作する
• 多くのプラットフォームではセキュリティ上、実行可能
領域へのメモリ書き込みを許容していない
• 動的なコード生成（実行部分のダウンロードを含む）が
必要な場合は、別途中間言語を用意しましょう

28. プラットフォームごとの
動作制限
https://docs.unity3d.com/Manual/ScriptingRestrictions.html
Universal Windows Platform
Universal Windows Platform

29. ３・入力について

30. 入力の扱い
• 必ず毎フレーム fetch している
• OnClick などのイベント方式ではない
• 押し下げの瞬間、指を離す瞬間、同時押し、
などをサポートする必要
• 同時押し
• ハードウェアで複数の同時押しに対応してい
ない場合に注意

31. 16.666 msec
入力状態
フレームの開始時に記録
キーの状態を毎フレーム完全に記録する

32. キーの状態を毎フレーム完全に記録する
押し下げ
変化したかどうかは
前のフレームの状態と比較して判断
Input.GetKey
Input.GetKeyDown
Input.GetKeyUp

33. ４・ブロック関数の書き方

34. スレッドを作る
• C# のThread を使う
• システムコールで作られるユーザスレッド
• メニーコア環境ではちゃんとコアに分かれて実行され
る
• Unity のAPIは作成したThreadから呼べないものが多い
• 基本的にマルチスレッド非対応
• WebGLでは使用できない

35. コルーチン
• しばしばスレッドよりも便
利
• 排他処理を考えなくても
よい
• UnityAPIを呼べる
• Unity にはすぐに使える
Coroutine が用意されて
いる（右のコード）

36. まとめ
• ブロック関数に注意
• あらゆるものが毎フレーム実行
• VSync という同期機構を意識しよう
• 基本的にネイティブ実行
• 入力はデバイスの状態をfetchしたもの
• コルーチンは便利

37. 実演パート

38. カメラ動き
トレイル動き

39. おまけ・タイムライン機能

42. おしまい