Unityの使い方のメモUnityの使い方のメモUnityの使い方のメモUnityの使い方のメモです。擬似ライトマップ:Unityよりも精密なライトをLightwaveでやっておき、サーフェイスベイキングカメラで光の情報までベイクしておき、Unityで使う。理論上はUnityのライトでは不可能な、超精密な陰影やテクスチャの再現が可能。テクスチャがあまりに大きすぎると、ゲーム時、メモリを大量消費する可能性があるので注意する。やり方は、まず普通にLightwaveでシーンを作り、撮影する。出来上がったら、すべての物体を含んだUVマップを作成し(アトラス、相対ギャップサイズ100)、そこにサーフェイスベイキングカメラで静止画を撮る。サーフェイスベイキングカメラはオブジェクトごとに静止画を撮るので、撮影前にベイキングする物体はすべて一つのレイヤーに納めておくこと。オブジェクトのサーフェイスをすべて一つにまとめ、そのテクスチャにこの静止画を貼り付ける。ほかのUVはすべて削除する(UnityはUVを2つまでしか認識できないらしいので)もちろんバックアップを取っておく。Unityに読み込んだら、Self-Illumシェーダーにする。Unityではテクスチャの明るさを調整できないので、明るさはテクスチャ自信を変化させて調整する。Lightwaveで普通にライトマップ:普通にライトマップを作る方法。やり方はだいたい上と同じだが、サーフェイスベイキングカメラで撮った映像を、フォトショップなどでグレースケールにする。これをUnityのLegacyのライトマップというシェーダーがあるので、それに入れる。このやり方は、ライトマップのグレースケールはRGBよりも容量が3分の1で、通常のRGBテクスチャに関してはタイリングなどを使って容量を減らせる。プロシージャルテクスチャを使った場合、陰影のない状態でサーフェイスベイキングしなければならなかったり(ライトを無効にして自己発光させてサーフェイスベイキングする、しかもUnityでの再現が完璧でない)、手続きが相当煩雑であるにもかかわらず、上記の方法に比べて容量は3分の1以上は落ちない。容量に問題がなさそうなら、上記の方法でいい。普通のライトマップの問題点:Lightwaveからは2つ以上のUVをUnityに持っていけないことから、一つのオブジェクトにつき、ライトマップ用のUVが一つ、テクスチャ用のUVを一つ持っていくことになる。テクスチャ用のUVはオブジェクトのすべての部分を一枚にまとめなければならず、背景など物体によってはすさまじい手間となる。Lightwave上では、すべての物質を表示し、複製物部分だけ一つにまとめてUV展開という、ものすごい手間になる。すべてのテクスチャをRGBで1024×1024で展開しても、3×1024×1024=3M程度で、スマホのメモリは数百メガある。手間を考えると、上記の擬似ライトマップのほうがよい。テクスチャアニメーション:テクスチャをアニメーションした場合、有料でムービーを入れられるが、ほかにも方法がある。テクスチャの透明度を調整するだけなら、その面とまったく同じ面をもう一つ重ね、Transparentなどのシェーダーで透明度をアニメーションさせればいい。テクスチャそのものを入れ替えるときは、スプライトをアニメーションで入れ替える。マテリアルを入れ替えアニメーションもできるが、負担が重そうである。板ポリゴンの使い道:カメラが停止していさえすれば、3Dでアニメーションさせる必要はなく、あらかじめ用意した板ポリゴンにアニメーションさせたテクスチャを貼り付ければよい。ムービーテクスチャでなくても、スプライトならすばやく入れ替え可能。板をカメラに常に正面を向くように設定すればよい。カメラが停止していさえすれば、どんな精密なアニメーションも板ポリゴンで入れることができる。/////////////プロジェクト、シーン新規作成:NewProject,Browseを押し、右クリックで新規フォルダーを作成してからそれを選んでフォルダーを適用する。保存:プロジェクトはフォルダーで保存、シーンはそのセットの中に保存される。操作:シフト+コントロール押しながらで、スナップ移動できる。スナップ量はEditのSnap設定でできる。移動時、Vキーを押したまま頂点を選ぶと、そのまま別の頂点へその頂点をあわせるように移動できる。alt押しながらで手のひらツールが目ツールになり、接近や回転が可能。ヒエラルキーでオブジェクトをダブルクリックで、その物体に焦点を当てる。移動速度も物体相当になるので使いやすい。("シーン名");という命令で切り替えができるが、そのときに使われるシーンはすべてFile->BuildSetting->AddCurrentに登録しておかなければならない。Paths:レンダーパスの方法を色で示す。///Game中の変更プレイ中にシーンに変更を加えると、プレイ後にもとに戻るので注意。///EditのPreferencesデフォルトのままで問題ない。Only)エディタで使用するカラースキームを選択する。Address有効の場合、キャッシュサーバのIPアドレス//////////////////////ビルド基本:ゲームオブジェクトにEditorOnlyというタグをつけていると、ビルド時にそれは含まれなくなる。デバッグ用のファイルなどはこうしておくとよい。新しいレベルのシーンをロードするときは、前のシーンのすべてのオブジェクトは破棄される。DontDestroyOnLoad()を使う。前のシーンの音楽の再生を続けたり、前と同じゲームのコントローラーを使う場合に。新しいシーンのロード時、OnLevelWasLoaded()というメッセージがすべてのアクティブなゲームオブジェクトに送信される。///コンパイルの順番いろんなフォルダにスクリプトがある場合、コンパイルには順番があり、フォルダによって決まる。何かを参照にするときは、それ以前のコンパイルでなされたものだけ可能で、逆は不可。フェーズ2で出てきた関数を、フェーズ3で取り出すことはできるが、フェーズ1で取り出すことはできない。ある全てのスクリプトは一切コンパイルされない。特殊でないフォルダに入れることで実現できる。フォルダにあるスクリプト)///名前空間これはAndroidではサポートしていないらしい。異なるスクリプトファイルで、まったく同じ名前のクラスがあると、コンパイル時に同じものと解釈されてしまうため、おかしなことになる。{...}}のように書く。するとこのクラスはコンパイル時にEnemy.Controller1Enemy.Controller2という名前となり、問題なくなる。別のファイルでController1が見つかったとき、Controller1と書いたのでは上手くいかず、Enemy.Controller1と書かなければならない。//属性スクリプトのクラス、プロパティ、関数の前に書いて、特別な効果を得るもの。strength;のように書く。////////////////最適化ゲームはスペック的な負荷が大きいと動かなくなったりする。ハードによって負荷を減らして動きやすくすることを最適化という。モバイルはスペックが弱いので、ちょっとしたことでも負荷が重く、動きにくくなる。基本:あまりにも多くのオブジェクトを出したりなくしたりしていると、負担が大きくなる。容量の大きいシーンが二つあると、それらをつなぐ瞬間にメモリ負担が大きくなってクラッシュすることがある。このような場合、空のシーンを間に差し込むことで解決できる。無圧縮ファイルを含めない。読み込みに時間がかかる。動かないオブジェクトにはstaticを有効にすると、負荷が減るらしい。使用メモリが少し増えるので、微妙なさじ加減が必要。オブジェクトの数があまりに多すぎるとまずい。レイヤー数が多すぎるとまずい。グローやデプスエフェクトは負担が大きい。それ以外のエフェクトもすべて負担が大きいので、エフェクトはなるべく使わないほうがよい。リアルタイムシャドウは負担が大きい。モバイルは使用しないほうがよい。プレハブを頻繁に使用すると重くなる。同じ物質であればプレハブよりもパーティクルのほうが軽い。ピクセルライトは負担が大きい。ポリゴン数:ポリゴンを減らす(ゲームでは三角形ポリゴンしか使えないので注意)ポリゴンを増やすくらいならノーマルマップのほうがマシだが、それでもけっこう重い。それよりもただの平面に凸凹をテクスチャに描いてしまったほうがよい。細長い三角形ポリゴンは作らないように。カメラから見た角度が変わらない物体に関しては(つまり回りこんでみる可能性のない物質は)、スプライトを使用する。板ポリゴンに出来上がった画像やアニメーションを貼り付けて使う。アニメーションは動画を貼り付けるのではなく、数十枚の静止画をつなげて使う(板ポリゴンに動画を貼り付けるのはモバイルでは不可能で、しかもProバージョンでしかできない)同じポリゴン数でも、オブジェクトの数が多いほうが負荷は大きい。画面に表示されるオブジェクト、ポリゴン数を減らせば負荷は軽くなる。一般論では、モバイルではポリゴン数は10万以下、パソコンでは数百万以下に抑えなければいけない。物理演算:物理演算は負荷が高いので、あまり大量だったり複雑にならないようにする。メッシュコライダは使わないほうがいい。使うとしてもできるだけポリゴン数を減らす。Time.fixedDeltaTimeはできるだけ大きくする。updateを少なくする。オブジェクトをできるだけ少なくする。メッシュコライダを避ける。使うなら少ないポリゴンで。リジッドボディのないColliderは動かさない(リジッドボディがあればいいらしい)。動かすと負荷が非常に大きくなる。やるならRigidbodyでIsKinematic有効を使う。リジッドボディの適用オブジェクトが多すぎるとまずい。決まったアニメーションならメカニムで変形させる。TimeManagerのFixedTimestepを大きくする。tanあたりの関数は負荷が高い。