Unity：AssetStoreのハウスジェネレーターの作成方法またはフルシチョフへの復帰方法

この記事を書いた理由は、「フルシチョフ」に関するこの出版物であり、 Unityでのプログラムメッシュ生成に関する興味深いトピックを取り上げました。



私の記事は、Unityに長年取り組んでいる人を対象とするものではありません。Unityの複雑さに精通している人にとって新しいものはないでしょう。 また、完全に新参者の場合、ここでは明白な「困難」が発生する可能性があり、すべてがエディターにあるときに何かを発明する必要があるのはなぜですか。 私たちの聴衆は、Unityで既に何かできる開発者に最も適していますが、エディターでメッシュを動的に変更する問題をまだ解決していません。 また、私たちの何人かは、検査官との経験から利益を得るかもしれません。



著者は、サブジェクト領域の絶対的な知識を持っていると主張していません。私は自分の言葉で、アセットを作成するときに現れたいくつかのタスクの解決策を伝えたいだけです。







上記の記事を読んだ後、私はすぐにこれがプロジェクトに必要なものであることに気付きました。 最初は、エクスポートされたfbxファイルから家を作成していました。 もちろん、説明されているように1対1で行うのではなく、基本的なアイデアを押し出して、すぐにタスクを設定しました。実行中のゲームモードに切り替えることなく、Unityエディターで建物を直接編集および表示します。 前のアイデアの結果として、すべての建物の設定を1つのスクリプトに収めることが判明し、その結果、オブジェクトインスペクターで構造全体を1か所で編集することが判明しました。

小さな余談

自己皮肉から始めます。 私たちの小さなチームは少し前に、モバイルプラットフォーム向けのゲームの開発を引き受けました。 独自のゲームエンジンを作成するという野心的なタスクから始めて、作業を開始しました。 他の活動分野を開発し、ゲームエンジンの作成に関する本を読んだ私自身の経験によると、すべてを純粋なsi （ PureC ）で書くことが決定されました。 エンジンのいくつかの主要な基本サブシステムが実装されました。最適化されたメモリマネージャ。 グラフィックレンダラー。 複合モデルの作成に対するコンポーネントアプローチ（ ハブでの公開 ）に基づくオブジェクトの階層。 LUAを作成したゲームのスクリプト作成機能に関連付けました。 SQLiteに基づいたローカルデータベースに、あらゆるもの（Luaのスクリプトを含む）などを保存する機能を実装しました。 上記のすべてを実装し、OpenGLが提供するインターフェイスを習得してかなり長い時間が経過した後、残念な結論に達しました。本格的なエンジンを作成できますが、すぐにできます。

Unityへの移行

当然、独自のエンジンの作成と並行して、ゲーム業界の成果に興味がありました。 私たちはアンリアルエンジンに非常に魅力を感じていましたが、モバイルプラットフォーム用の30〜45MBの最小限のプロジェクトはすぐに冷静になり、他のソリューションを探すことにしました。



最後に、Unityで最近試しました。 Unity C＃構文は部分的にマスターされていましたが、ガベージコレクションシステム（ GC ）のおかげで、作成されたリソースを解放する必要が必ずしもないという事実に慣れるのはかなり困難でした。

仕事のために選ばれたトピック

さらに作業を説明する前に、制限についてすぐに説明します。Unity5をすぐに勉強し始めました。つまり、すべての例は、Unityの5番目のバージョン、前の4番目、さらに3番目のバージョンで動作するはずです。保証はできません。 私自身の経験から、バージョン4で出会ったレッスン/スクリプトの一部はバージョン5で実行されることが判明し、一部は新しいバージョンに再フォーマットして正常に開始する必要があり、一部は開始できなかったため、コマンド構文を変更する必要がありました。 バージョンの下位互換性については何も知りません（小さな追加：アセットを公開する前に、Unity 4.5.0で以下にリストされたスクリプトを正常にテストしました）。



ゲームを視覚的に満たすために、周囲の背景をさまざまな建物で飽和させることが決定されました。 エディタで建物のおおよその外観をすぐに見たいと思いました。 エディターで直接スクリプトを「実行」できるようにするには、MonoBehaviourから継承したクラスの前に、[ExecuteInEditMode]という行を記述する必要があります。 プロジェクトでMyTest.csスクリプトを作成し、次のテンプレートに従って変更します。

using UnityEngine; [ExecuteInEditMode] public class MyTest : MonoBehaviour {     //   ,     //      //   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インスペクターのフィールドを変更すると、スクリプトメソッド（実装されている場合）Update（）が呼び出されます。 ゲーム用に収集されたスクリプトのサイズを節約するために、このメソッドは#if UNITY_EDITOR ... #endifディレクティブのペアで「エスケープ」できます。したがって、インスペクターで直接変更できるスクリプトのおおよそのテンプレートがコンポーネントに対して表示されます。

 using UnityEngine; [ExecuteInEditMode] public class MyTest : MonoBehaviour {    public int i=10; #if UNITY_EDITOR    void Update () {        Debug.Log ("Update");    } #endif }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトをステージ上の任意のコンポーネントに添付し、インスペクターのiフィールドの値を変更すると、コンソールはすぐに「更新」を表示し（より正確には「更新」メッセージの数が増加します）、残りの時間はスクリプトがパブリックフィールドの変更を「待機」します。



このスクリプトを使用してシーンに多数のコンポーネントがある場合、シーンの速度が著しく低下することに注意してください。 これを取り除くには、インスペクターの変更プロセッサーを特別なエディターフォルダーのスクリプトに移動する必要があります。 このフォルダーの内容は、完成したプロジェクトに分類されません。 Editorフォルダーと、その中にスクリプトMyTestInspector.csを作成しましょう。

 using UnityEngine; using UnityEditor; using System.Collections; [CustomEditor(typeof(MyTest))] public class MyTestInspector : Editor {    //       public override void OnInspectorGUI()    {        //           DrawDefaultInspector ();        //            MyTest mt = target as MyTest;        //  ,        //            mt.DoRefresh();    } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変更されたMyTestスクリプトを見てみましょう。

 using UnityEngine; [ExecuteInEditMode] public class MyTest : MonoBehaviour {    public int i=10;    public void DoRefresh () {        Debug.Log ("Update");    } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より便利な作業のためのインスペクターのセットアップ

公式情報とグーグルを研究した後、まず、インスペクターのパブリックプロパティの再描画とスクリプト内の適切な方法による変更への対応を提供するバリアントを決定しましたが、その後、編集用のソースデータを、失わずに操作しやすい相互接続されたデータ構造に分割することにしました建物を構築するための約130の同時表示設定。 その後、「個人検査官」の必要性はなくなりました。 ただし、コンポーネントを作成および編集する場合は、今後このアプローチに戻りたいと考えています。 誰かが興味を持っているなら、私はリンクを与えることができます： こことここ

インターフェイス作成の微妙な点

たとえば、型intまたはfloatのパブリック変数を通常作成すると、次のようになります。

 public int iterator=2; public float dx=0.5f;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インスペクターでは、単純な編集フィールドとして表示されますが、作業中にこれらの値を頻繁に変更するため、マウスカーソルを常にフィールドに移動し、互いにほとんど意味のない意味のある数字を入力し、受け取った変更を確認するのは非常に退屈です。異なるアプローチがはるかに便利です。 変数（上記の行）の直前にフィールドを宣言する場合、入力された値の有効な範囲を示します。

 [Range(-10, 10)] public int iterator=2; [Range(0.0f, 1.0f)] public float dx=0.5f;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変数の前にこのような追加を行った後、インスペクターでスライダーを動かして値をスムーズに、または突然変更するだけで十分です。



スクリプト内のすべてのフィールドを同時に表示しないようにするために、約130個のフィールドがあります。互いに強く関連する値を1つのクラスにグループ化して、このクラスをスクリプト内のパブリックフィールドとして宣言することができます。 クラスの別々のインスタンスでフィールドの変更を保存し、インスペクターでフィールドを表示できるようにするには、クラスを宣言する前に[System.Serializable]の行を記述する必要があります（上記の行）。

 [System.Serializable] public class LeftRightSide {    [Range(0, 100)]    public int leftSide=3;    [Range(0, 100)]    public int rightSide=20; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスをスクリプトでパブリックフィールドとして宣言すると、上記のクラスのコンテンツを編集するためのフィールドの非表示/展開可能なブロックがインスペクターに表示されます。 さまざまなクラスを互いに階層的にネストすることができ、常識によってのみ制限されます。 このような単純な手法により、まず：関連データをグループ化でき、次に：インスペクターでのナビゲーションが簡単になります。 スクリプト全体について説明します。

 using UnityEngine; [ExecuteInEditMode] public class MyTest : MonoBehaviour {    public LeftRightSide leftRight=new LeftRightSide();    public void DoRefresh () {        Debug.Log ("Update");    } } [System.Serializable] public class LeftRightSide {    [Range(0, 100)]    public int leftSide;    [Range(0, 100)]    public int rightSide; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッシュエディターで直接編集可能

メッシュを描画するためのコンポーネントの準備。 メッシュを編集および表示できるようにするには、エディターの機能を使用できます。たとえば、ステージ上で空のオブジェクトを作成し、メニュー項目Component-> Mesh-> Mesh Filter and Component-> Mesh-> Mesh RendererからMeshFilterとMeshRendererを追加しますそれに応じて。 最初のコンポーネントは「内部」メッシュジオメトリを担当し、2番目はスクリーン上のメッシュの描画に関連付けられています。 これらのコンポーネントを追加する別のより信頼性の高い方法があります。 スクリプトを作成するとき、スクリプトが接続されているコンポーネント上にない場合、上記の2つのコンポーネントを追加するように指示する必要があります。 これを行うには、MonoBehaviourの下位クラスを宣言する前に、文字列[RequireComponent（typeof（MeshFilter）、typeof（MeshRenderer））]を記述します。 サンプルスクリプトの準備：

 using UnityEngine; using System.Collections; [RequireComponent(typeof(MeshFilter), typeof(MeshRenderer))] [ExecuteInEditMode] public class MyTest : MonoBehaviour {    //... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少しの理論（Unityでメッシュを操作する方法を知っている人は、このセクションをスキップできます）

コンポーネントのメッシュに何かを表示するには、必要なデータでメッシュを塗りつぶす必要があります。 最小は、頂点のセットといわゆるファセット（この名前には同義語があります。たとえば、三角形、面、ファセット、インデックスの配列）、つまり、頂点を相互にリンクするためのルールで構成されます。 さらに、テクスチャを描画する可能性が考慮されます。つまり、UV座標を使用する必要があります。 法線も短時間表示されます。 すぐに予約します。ここでは、パーティクルシステムの操作、メッシュモードの操作などを考慮せずに、シェーダーの「古典的な」作業のみを考慮します。 つまり、頂点とそれらの「バンドル」のルールに基づいて三角形を描画するモードが考慮されます。 一般的に、このトピックの詳細な議論、すなわち メッシュ、シェーダー、多数の頂点、ファセット、法線、テクスチャ座標、頂点バッファー、マトリックスなどは、数冊の本のボリュームを占有する可能性があります（そうすべきです）ので、直接表示される動的メッシュを構築するのに十分な最小限の情報量に制限しますエディター。



三角形を描くことができるので、三角形を互いに組み合わせることにより、任意の複雑な図形を描くことができます。 たとえば、正方形、菱形、平行六面体、台形、および一般的に四角形の場合、2つの三角形で十分です。 より複雑な形状を描くには、より多くの三角形が必要ですが、原則は変わりません。 つまり、他のすべてを描画するための最小かつ十分なプリミティブであり、三角形を考慮することに同意します。



シェーダーについて簡単に説明します。シェーダーは、特定のルールに従って三角形を描く特別に作成およびコンパイルされたプログラムです。 実際、すべてはやや複雑ですが、簡潔にするためにこの解釈を受け入れます。 別の三角形を描画するとき、シェーダーは隣接する三角形について何も知らないことを言及します。



コンピューターのメモリは線形であり、大規模な/複合データブロック（構造、クラス、配列など）がある場合は常に、その内容はすぐ後ろにあり、その要素へのアクセスも線形に配置するのが最適です。 また、メッシュは非常に大量の異なるデータを含むことができる複雑な構造ですが、特定のデータのタイプによって結合されるため、このデータの管理も線形アクセスによって正しく編成されます。 つまり、配列を作成して適切なデータを入力し、これらの配列をメッシュにアタッチする必要があります。



メッシュを構築するために必要ないくつかのデータ型をリストします。



頂点（頂点）-Vector3型のデータの配列、つまり、x、y、z軸に沿った1つの頂点の空間座標にすぎない、float型の3つの連続したデータを含む構造体の配列で構成されます。



頂点インデックスまたはファセット（三角形）-intデータ型の配列で構成されますが、ここでは整数を3で1つの三角形にグループ化する必要があることを考慮する必要があります。 この点をより詳細に検討すると、実際には、1つの三角形（つまり、最小限の描画プリミティブ）を記述するために、3つの頂点インデックスを指定する必要があります。 最初の3つの数字は、最初の三角形の描画を決定し、2番目の3つの数字は2番目の三角形を描画します また、三角形内の頂点のトラバースの順序に言及することも重要です。 頂点（つまり、頂点のインデックス）を時計回りにリストすると、三角形が「あなたを見る」、つまり見える、さもなければ、三角形は描画されず、表示されませんが、視覚的に反対側から「回る」場合、それはあなたに見えるようになります（つまり、新しい角度から、頂点の列挙は「変化」し、時計回りになります）。 ご想像のとおり、配列全体の全長は、三角形の数に3を掛けたものに等しくなります。



法線-Vector3型のデータの配列で構成されます。これは、頂点に対する「垂直」の配列であり、法線の配列と頂点の配列の次元は同じです。 各法線ベクトルの絶対長は1に等しく、実際、頂点の「回転角」が形成されます。 なぜこれらの法線が必要なのですか？ これらは、三角形の照明を正しく考慮するために必要です。 法線、光源のビーム、および観察者の目の間の角度を知って、照明を計算できます。 法線は、想定されるように三角形ではなく、頂点ごとに作成および計算されます。 法線が三角形のみに設定されている場合、シェーダーは法線が三角形から三角形にどのように変化するかを知りません（シェーダーは隣接する三角形について何も知らないため）。これから、描画されたシェイプは明るく見えますが、非常に「角張っています」 実際、シェーダーは、各三角形を処理するときに、頂点間の法線を含む、頂点間のパラメータを一様に変更します。 これにより、同じ三角形内でも照明の滑らかな変化が得られます。 三角形の頂点の法線が互いに発散する場合、三角形は「凸」に見え、法線が収束する場合、三角形は「凹」になり、法線が平行の場合、三角形は平らになります。 隣接する三角形は同じ原理に基づいて構築され、対応する頂点は法線と一致します。三角形が異なるが、角度が大きく異なる場合、三角形間の移行は滑らかになり、それらの間の境界は区別できなくなります



UV座標（uv）-Vector2型のデータの配列で構成されます。つまり、テクスチャの「内部」のxおよびy座標であるfloat型の2つの変数を含む構造体です。 ここで、より詳細に伝える必要があります。 テクスチャの左下隅は、UV座標（0、0）、左上-（0、1）、右上-（1、1）、および右下-（1、0）に対応しています。 [0 ... 1]の範囲の座標を取得すると、指定した値に応じて、テクスチャ全体が部分的または完全に描画されます。 指定された範囲外の値を取ることができ、指定した回数だけテクスチャが繰り返されます。たとえば、uv座標（2、3.5）が選択され、x軸がテクスチャを2回、y軸が3.5回繰り返されます。 テクスチャを繰り返すために、これに必要なフラグを設定する必要があります。 多くの場合、フラグはデフォルトで設定されています。 uv座標配列の次元は、頂点配列の次元と同じです。つまり、各頂点はテクスチャ座標uvに対応します。



以上をまとめます。 メッシュを作成および描画するには、頂点、頂点インデックス、UV座標、および法線の配列を作成する必要があります。



下の図を見ると、座標の中心を基準にした長方形の頂点の配置を模式的に示しています。 長方形の角の近くには、頂点のインデックス、つまり頂点配列内のインデックスがあります。 図形を作成するときは、原点に「幾何学的中心」を持つ図形を作成することをお勧めします。 これは、予測可能な結果で形状を回転および/または拡大縮小する必要がある場合に便利です。 メッシュを作成したら、必要な方向にすべての頂点を簡単に移動できます。







頂点とインデックスのみからメッシュの作成を始めましょう。上記のスクリプトを例として変更してください：





ステージ上に「空の」コンポーネントを作成し（GameObject-> Create Emptyメニュー）、スクリプトを添付します。ピンクの三角形が表示されるはずです。三角形が見えない場合は、コンポーネントの周りでカメラを回転させます。 インスペクターでバナーの幅と高さを変更してみてください。すぐに三角形の変化が見えるはずです。 長方形を作りましょう。 これを行うには、DoRefresh（）メソッドの内容を次のように変更します。





スクリプトを編集し、Unity環境に切り替えた後、三角形は長方形に「完成」します。 次に、長方形の色を変更しましょう。 これを行うには、2つの場所でスクリプトを変更する必要があります。パブリッククラスBannerが作成される最上部で、行public Material bannerMaterialを追加する必要があります。 つまり

  public Banner banner = new Banner(); //    public Material bannerMaterial;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、DoRefresh（）メソッドの最後に、GetComponent <MeshRenderer>（）.material = bannerMaterial;という行を追加します。 つまり

  GetComponent<MeshFilter> ().mesh = tmpMesh; // ,     GetComponent<MeshRenderer> ().material = bannerMaterial;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、マテリアルタイプの変数がインスペクターに表示され、マテリアルを割り当てることができます。値を変更すると、長方形はマテリアルの変更「repaint」にすぐに応答しますが、1つの色で塗りつぶされます（Unity 4.5.0では、テクスチャのシフト座標）。 これは、UV座標がメッシュに与えられなかったためです。これを修正しましょう。 DoRefresh（）メソッドを次のテキストに再度置き換える必要があります。





これで、マテリアルに画像が添付されている場合、長方形全体に拡大されます。 しかし、まだリアリズムに欠けています。 リアリズムを追加するには、イルミネーションを考慮する必要があります。そのためには、法線を作成してメッシュに追加する必要があります。 特定のケースでは、これは簡単です。 メッシュはXOY平面に描画されます、つまり、Z軸に垂直で、法線のz座標を決定するために残ります。 法線は、頂点から表示される半空間（三角形の前面の半空間を意味する）に到達する必要があります。 DoRefresh（）メソッドを再度編集します。





これで、光源の強度、照明の方向を変更すると、すぐに長方形の結果を見ることができます。



シムの場合、私はお辞儀をします。記事はかなり大きいことが判明しました。通知されたすべてのエラーおよび不正確な情報を送信する要求。



PS：アーティストは私からは弱いので、回路図の描画は完全には明らかではないことが判明しました。また、プロジェクトは商用であるため、建物の建設の完全なソースコードを公開することはできません。