Unity 4.0 では GameObject のアクティブ(active)状態の操作の仕方が変わりました。GameObject のアクティブ状態は親子構造の子の GameObject へ引き継がれるので、非アクティブの GameObject の子はすべて非アクティブになります。新しい挙動は古いものよりも役に立つと思いますし、いつもこの方法にすべきです。また今後実装予定の新しい GUI システムではこの新しい挙動に依存し、それなしでは実現が不可能です。残念なことですが、新しい Unity 4.0 の挙動のせいで今まで作っていたプロジェクトを修正するためにいくつか作業が発生してしまいます。下記がその作業項目です。
3 つの GameObjectA、B、C があり、B と C は A の子であるとします。
これらの変化を可視化するために、Unity 4.0 のエディターでは、非アクティブの GameObject は、Hierarchy で暗く表示されます（それ自身が .activeSelf プロパティーが false 、またはその親がそうなっていれば）。Inspector でもアイコンは暗く表示されます。GameObject の自身の .activeSelf プロパティーは active チェックボックスをオンにすると反映されます。親状態に関係なく切り替えることができます（ただし、すべての親がアクティブである場合、このチェックだけでその GameObject をアクティブになります）。
4.0 の開発の過程で、当社のアセットインポートパイプラインは、パフォーマンス、メモリ使用量、安定性を向上させるために、内部のいくつかの重要な工程が変更されました。これらの変更はほとんどの部分については影響はありません。例外として、アセット内のオブジェクトは、インポートパイプラインの最後の最後まで以前にインポートされたバージョンのものが存続し、最後に完全に置き換えられます。
最初のパートでは、ポストプロセス時には、アセット内のオブジェクトへ正しい参照を取得することはできないことを意味し、次のパートでは、ポストプロセス中の変更を保存している間、前のインポートしたバージョンへ参照を使う場合、それらの変更が失うことを意味します。
次の短いコード例でみてみます。
public class ModelPostprocessor : AssetPostprocessor
{
public void OnPostprocessModel(GameObject go)
{
PrefabUtility.CreatePrefab("Prefabs/" + go.name, go);
}
}
Unity3.5 では、これはメッシュ等の正しい参照を持ったプレハブが生成されるでしょう。これはすべてのメッシュがすでに永続化されているからです。しかし、Unity4.0 の場合ではそうならないので、同じポストプロセッサーでもメッシュへの参照が切れたプレハブを作成します。それは、Unity4.0 のはまだ元のモデルプレハブ内のオブジェクトへの参照を解決する方法を知らないという単純な理由です。正しく modelprefab をコピーするには、すべてのアセットのインポートをやり過ごす OnPostProcessAllAssets を使うべきです。そうすると modelprefab をみつけて、上記のように新しいプレハブを作成します。
二番目の例は少し複雑ですが、実際にあった、3.5 で正常に動いたものが 4.0 で動かなくなったケースです。ここでは ScriptableObject は簡単なメッシュへの参照を持っているとします。
public class Referencer : ScriptableObject
{
public Mesh myMesh;
}
モデル内のメッシュへの参照を持つアセットを作成するために、この ScriptableObject を使います。その後ポストプロセッサーで、その参照を持ってきて、別の名前を付け、モデルを再インポートした際にメッシュの名前は最終的な結果はポストプロセッサーが決定します。
public class Postprocess : AssetPostprocessor
{
public void OnPostprocessModel(GameObject go)
{
Referencer myRef = (Referencer)AssetDatabase.LoadAssetAtPath("Assets/MyRef.asset", typeof(Referencer));
myRef.myMesh.name = "AwesomeMesh";
}
}
これは Unity3.5 でうまくいきましたが、Unity4.0 ですでにインポートされたモデルを完全に置き換えられますので、前回のインポートからメッシュの名前を変更しても影響はありません。ここでの解決策は、何か他の手段によってメッシュを見つけて、その名前を変更することです。注意するべきもっとも重要なことは、Unity 4.0 ではポストプロセッサーに与えられた入力を修正する「だけ」にするべきで、同じアセットの以前にインポートされたバージョンをあてにしないことです。
Unity 4.0 では モデルのインポート の Import Settings に “Read/Write Enabled” オプションが追加されました。このオプションがオフにすると、Unity はゲーム内でのメッシュデータのコピーをアンロードすることができるので、メモリを節約できます。
ただし、あなたは単にスケーリングしたり、や非線形なスケールを使用して実行時にメッシュをインスタンス化したりしている場合は、あなたはそれらのインポート設定で “Read/Write Enabled” を有効にする必要があります。その理由は、非線形なスケーリングはメッシュデータをメモリ内に保持する必要があるからです。通常、ビルド時にこれを検出しますが、メッシュは、実行時にスケーリングやインスタンス化されるときには、これを手動で設定する必要があります。そうしないと、ビルドされたゲームの中で正しくレンダリングされない場合があります。
Unity 4.0 の Model Importer は、メッシュの最適化が改善されました。Unity 4.0 では Model Importer の “Mesh Optimization” チェックボックスがデフォルトで有効になっており、最適なパフォーマンスを出すためにメッシュ内の頂点の順序を変更します。あなたのプロジェクト用の、メッシュの頂点の順序に依存するポストプロセスのコードや効果は、この変更によって壊れる可能性があります。その場合には、Mesh Importer の “Mesh Optimization”はオフにしてください。SkinnedCloth コンポーネントを使用している場合は特に、このメッシュの最適化で、頂点ウェイトのマッピングが変更されることがあります。 3.5 から引き継いだプロジェクトで SkinnedCloth を使用しているのであれば、影響を受けるメッシュの “Mesh Optimization”をオフにするか、新しい頂点の順序と一致するように頂点ウェイトを再構成する必要があります。
Unity 4.0 によりモバイルセンサー入力はプラットフォーム間の整合性が改善され、具体的にはモバイルプラットフォームで典型的な入力をハンドリングする場合にコードの記述する量が少なくなっています。改善により加速度センサーとジャイロセンサーの入力は iOS と Android で同じように画面の向きに従います。この変更を活用するには、入力に関わるコードのリファクタリングを行い、加速度センサーとジャイロセンサーの入力のハンドリングを行う際のプラットフォームと画面の向きに固有のコードを削除します。iOS で以前の仕様をそのまま使用したい場合は Input.compensateSensors を false に指定します。