編み枝細工のフェンスの陰、またはアダムジェンセンの25のクリスマスツリー

居心地の良い2次元ゲーム開発の範囲を超えることなく、美しい3次元の影を作成しようとした方法と、その結果。

背景

次のLudum Dareに備えて、さまざまなジャンルのいくつかのゲームをスケッチしてみることにしました。 私は通常、ゲーム開発の経験がないため、2DゲームとPhaser.jsエンジンのみを検討しました。 1つのアイデアは2Dステルスです。 そしてステルスがどこにあるのか、光と影の作品があります。 少しグーグルして、ところで、Habréでこのような良い記事を見つけました（ 1回と2回 ）。Illuminated.jsライブラリ（OpenGameArt.org からのランダムなアセットセット）を取り出し 、すぐにこの写真を取得しました。









私は絵が好きだった。 光と影のおかげで、一定のムードと深みがすぐに現れました。 唯一の動揺は、影がまったく自然に見えなかったことです。 また、illuminated.jsは純粋な2D環境（読み取り-上面図または側面図）で動作し、ここでは擬似3D（正面図/上面図）を使用しているため、当然です。 そして、無限の影（光源が高い場合）ではなく、有限の影が欲しいので、光がフェンスのスロットを通過するようにします。 一般的に、美しくなるために。



合計すると、問題のステートメントは次のようになりました。

• 描画されたスプライトのセットがあります（これは重要です。私自身は描画方法を実際には知らず、ソースマテリアルから画像を生成するのが簡単だからです）
• パースペクティブ-上部/前面、擬似3D。 単純に上/側面からの場合、illuminated.jsと上記のメソッドが適しています。
• この2Dエンジンで。 それでも、ロジックは2次元で行う方が簡単で、レベルは構成しやすいです。ツールがあります。Ludumにとって、これはすべて非常に重要です。

ソリューション1.素朴なレイキャスティング

（ 例へのリンク ）



頭に浮かんだ最初の方法はレイキャスティングです。 つまり、シーンの各ピクセルから光源まで線を引きます。 途中に障害物がある場合、ピクセルは影の中にあります。









明らかに、javascriptを実行する価値はなかったため、WebGLフラグメントシェーダーが助けになりました。 フラグメントシェーダーは、描画されたポリゴン（この場合、ゲームキャンバスのサイズの長方形）内の各ピクセルに対してビデオカードによって実行されます。これは目標とちょうど一致します。 シェーダーに光源と障害物に関する情報を送信するために残っています。





光源が多かれ少なかれはっきりしている場合、障害物を3次元に移動する必要があります。 16x16のツリーは、ベース半径が8で高さが16の円錐のようなものになるはずだとしましょう。このような円錐は、元のスプライトを回転させることで取得できます。 そして、フェンスは2〜3ピクセルの厚さを追加するのに十分です。



その結果、使用されたすべてのスプライトは、テクスチャの形式で作成された3Dモデルになりました-1スプライトあたり16イメージ、各高さのスライス。 あなたはそれをボクセルモデルと呼ぶことができますが、その時には私はそのような言葉を知りませんでした:)









シェーダーは、このテクスチャと、スプライトが描画されたマークが付いたシーンマップを受け取りました（スプライト番号は色分けされています）。 その結果、アルゴリズムは次のように要約されました。

現在のポイント（x、y、z）を取得します。ここで、z == 0（地面） 光源の方向を決定します。 このベクトルを正規化して、どの方向にも1ピクセルだけ移動しないようにします。 光源に向かってNステップを実行します。 各ステップについて： マーク付きのテクスチャを見てください。 現在の（x、y）座標にスプライトがあることに気づいた場合、その番号を取得します。 それ以外の場合、ポイントは空です。移動を続けます。 このスプライトのボクセルモデルを見てください。 現在の（x、y、z）に不透明なピクセルがある場合、停止し、ピクセルがシェーディングされていることに注意してください。

奇妙なことに、すべてがすぐに始まり、そのような写真が得られました：



全体として、悪くはありません。 しかし、オブジェクト自体に十分な光/陰影がないことは明らかです。 光源の「下」にあるクリスマスツリーが実際に私たちの近くにあり、隠す必要があるとしましょう。 右側のツリーは半分点灯しているはずです。 そして、右側のスクリーンショットの墓石は、フェンスで部分的に隠されている必要があります。



両方の問題を一度に解決してみましょう。 シェーダーでは、常に地面からビームを投げます。 ただし、スプライトの3Dモデルがあり、どのスプライトポイントがどの高さにあるかがわかります。 この知識を使用します。

まったく別の問題。



私たちの影は非常にシャープであることに気づくかもしれません-「ピクセル化」のために地面とオブジェクト自体の両方に。 また、私はこれに注意を向け、別の種類の問題に出くわすまで、この問題を解決する方法を考え始めました。









すでにシェーダーコードを調べている人はすぐに多くの問題に直面したと思います。

• ネストされたループ（最初に光源、次にレイキャスティング時の「ステップ」による）
• テクスチャのカスケード呼び出し
• 多くの条件ステートメント（if）

そこで、2番目のソリューションが登場しました。

解決策2：改善されたReykasting

（ 例へのリンク ）



テクスチャへのカスケードアピールを排除するために、全世界の3Dマップで1つのテクスチャを作成することが決定されました。 私たちのモデルは、16〜32ピクセルの高さではありません。 額の解決策は、世界の32の「スライス」を作成し、それらを1つの画像テクスチャに次々と配置することです。 しかし、これは機能しません。640x640のワールドサイズでは、テクスチャのサイズが32倍大きくなり、WebGLはそれほど消化しません。 むしろ、私が疑うように、OS /ブラウザ/ビデオカードの組み合わせによっては消化することもできますが、頼りにしない方が良いです。



まあ、あなたはそれをすべて絞る方法について考える必要があります。 一般に、ピクセルの色に関する情報は必要なく、特定のポイントでの存在/不在のみが必要です。



WebGLでは、テクスチャをロードするときに、そのフォーマット（整数の色成分、または浮動小数点の場合、アルファチャネルの有無）を指定できます。 しかし、以来 デフォルトではシングルバイトの色成分を使用するPhaserを使用します。 ピクセルごとに3色のバイトがあり、それらに24ピクセルに関する情報を収めることができます。 この方法で「高さ」に詰め込む場合、世界の2倍の大きさのテクスチャが必要です。0〜23の高さの半分と24〜31の高さの半分です。または、簡単にするために、16未満とそれぞれ16以上。











このようなマップをjavascriptで作成することは、ビットごとの操作があるため、特に難しくありません。 しかし、待ち伏せはシェーダーで待っていました。









何もする必要はありません-計算を行う必要があります。 実際、1つの操作だけが必要です。ビットが正しい位置に設定されていることを確認します（位置= z座標）。 ビット演算では、これはANDマスクされるため、この関数を記述する必要がありました。

float checkBitF(float val, float bit) { float f = pow(2., floor(mod(bit, 16.))); return step(1., mod(floor(val/f),2.)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

人間の言語に翻訳した場合（まあ、少なくともjs）、これが起こることです：

  function checkBitF(val, bit) { f = Math.pow(2, bit % 16); //  f = 1 << bit; f1 = Math.floor(val / f); //   , f1 = val >> bit if (f1 % 2 < 1) return 0; else return 1; //  ,  1.  0. }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、シェーダーのmodが常に整数を返すと突然考えた場合、これはそうではありません。



組み込み関数-ミックス、ステップ、クランプを使用して、条件ステートメントを取り除くことができます。 GPUを使用することで、コードをより最適化できます。





結果の画像は以前のソリューションと大差ありませんでしたが、fpsはすでに1.5〜2倍大きくなっています（詳細な計算は記事の最後にあります）。







この時までに、私はすでに順番にシャドウについて読んでいて、3Dの世界ではほとんどの場合シャドウマッピングと呼ばれる方法を使用していることがわかりました。 その本質は次のとおりです。

• まず、光源の視点からシーンを構築し、各三角形の各ピクセルについて、そこから光源までの距離を記憶します。
• 次に、観察者の視点からシーンを構築するときに、取得したシャドウマップを使用します。 各三角形の各ピクセルについて、シャドウマップ上の対応するポイントを確認します。 光源の近くにピクセルがある場合、ピクセルは影の中にあります。

これが正常に機能するためには、正直な3次元ポリゴンでモデルを作成する必要があります。ここではピクセルテクスチャを使用できません。 Phaserは、2D向けに強化されたエンジンであり、頂点シェーダーを操作する機会を提供しません。 しかし、それはそれ自体に任意のキャンバスを描くことを可能にします。 したがって、3Dシーンを個別に構築し、シャドウのみを描画してから、2Dシーンの上に描画することができます。

解決策3：3Dシャドウ

（ 例へのリンク ）



3次元オブジェクトを操作するために 、 three.jsを使用しました。これは、webglを直接操作するのにかなり時間がかかったためです。



まず、スプライトを3Dメッシュに変換する必要がありました。 その瞬間、私はMagicaVoxelツール（ボクセルを操作するための優れたツール）に精通し、objファイルにエクスポートする方法を見て、最初から変換を繰り返すことにしました。 アルゴリズムは次のとおりです。

• ボクセルモデルを取得します（そして、私はすでにそれを構築する方法を知っていました）
• ボクセルごとに、表示される面、つまり 他のボクセルに接しないでください
• 顔ごとに2つの三角形と色情報を記述します。 three.jsでは、THREE.BufferGeometryはカスタムジオメトリに適しています。 実験のために、私はすべてのボクセルをシングルピクセルキューブ（THREE.BoxGeometry）としてシーンに追加しようとしました...一般に、これを行わないでください。

楽しみのために、私は木を回し、三角形の数を数えました。 16 x 16 x 16ピクセルの小さなクリスマスツリーでは、約1000個の三角形が必要であることが判明しました。 その後、友人からこのリンクが提供されました-http ://www.leadwerks.com/werkspace/topic/8435-rule-of-the-thumb-polygons-for-modelscharacter/-人気ゲームの一部のキャラクターのモデルのサイズが示されています。 そこで見つけた：









さて、私のクリスマスツリーの25から、アダムジェンセン全体を収集できます！



その結果、「ボクセル」でステージをスキップして、スプライトの変換をやり直しました。 （クリスマスツリーのような）回転図形は、より丸みを帯び、少し自然に（または不自然に-円錐形のクリスマスツリーに対するあなたの意見に依存します）照らされました。 ポリゴンの数を減らすために、各ポリゴンの色に関する情報の保存を停止しました（つまり、隣接するポリゴンを1つに結合できました）。代わりに、元のスプライトをマテリアルテクスチャとして追加し、このテクスチャのポイントをポリゴンで参照しました（いわゆる。uv-mapping）。



これにより、三角形の数が2倍に減少しましたが、興味深いことに、パフォーマンスにはまったく影響しませんでした。 この決定のパフォーマンスは、まったく異なるものの影響を受けました。



私のレイキャスティングよりも悪いことではありませんが、ソリューションは機能し、さらには影を描きます。









もちろん、今ではクリスマスツリーは「上から」描かれています。 影を作成するために、これが正しい位置であり、2次元バージョンの「魔法」を部分的に失いました...しかし、この問題も解決できます。



three.js（または3Dエンジンかもしれませんが、私はまだ強くありません）1つのオブジェクト（メッシュ）を描画するには2つのことが必要です。

• ジオメトリ-フォームに関する情報（読み取り-さまざまな属性を持つ三角形のセット-法線ベクトル、テクスチャのUV座標、色など）
• マテリアル-マテリアルに関する情報（読み取り-マテリアルのプロパティに基づいて、シェイプの描画、シャドウの適用、ハイライトのペイントなどの頂点/フラグメントシェーダーのセット） Three.jsにはいくつかの素材があり、外観、特定の機能のサポート（たとえば、すべての人が影を描くことができるわけではありません）、およびパフォーマンスが異なります。

したがって、特定のレンダリングでは、マテリアル、またはそのシェーダーに責任があります。 マテリアルを取得し、頂点シェーダーを調整して、モデルが回転して描画されるようにすることができますが、すべての計算（影、照明）は、まるで回転していないかのように適用されます。



その結果、シーン内のすべてのオブジェクトを取得し、頂点シェーダーの最後に次の行を追加しました。

 gl_Position.z = gl_Position.y; gl_Position.y += -position.y/${size/2}. + position.z/${size/2}.;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どこで

• size-ワールドのサイズ（gl_Positionには-1から1の座標が含まれている必要があり、ポイント（0,0,0）はシーンの中心です）
• position-図形内のポイントの相対位置、頂点属性。

同時に、フラグメントシェーダーに渡されるさまざまな変数には触れませんでした。 したがって、フラグメントシェーダーは、オブジェクトが回転していないかのように、古い方法で照明と影を適用しますが、回転して表示されます。

まとめ

3つのオプションすべてがどのように見えるかを見てみましょう。

素朴なレイキャスティング	レイキャスティング	3D

そして、さまざまなオプションのパフォーマンスを比較します。



パフォーマンスを評価するために、私はPhaser.jsで考慮されているFPSメトリックを使用しました。 結果を読むとき、Phaser.jsには60を超えるFPSが表示されないことに注意してください。正直に修正方法を見つけようとしましたが、成功せず、スコアを決めました。











あなたの目を引くもの：FFでは、3DバリアントはRCバリアントよりも悪いことを示しています。 どうやら、問題はこれです：









結果は、FFのこのバグのようです： canvasを使用したtexImage2Dの低パフォーマンス 。



残念ながら、これはまさに私が使用するシナリオです。最初にキャンバスにシーンthree.jsをレンダリングし、次にこのキャンバスをフェイザーテクスチャとして使用します。 残念ながら、まだ回避策はありません。 （three.jsでシーン全体、実際にゲーム全体を構築する場合を除き、これは設定された条件と矛盾します）。



クロムでは、3Dバージョンはレイキャスティングよりも平均で2回優れています。 ただし、レイキャスティングの速度は、シーンのサイズ（または、表示される部分のサイズ）に大きく依存することを理解する必要があります。 たとえば、より小さなテクスチャ（たとえば、2倍小さい-4分の1の光線を減らす必要がある）に影を構築することができ、ブラーは影の品質を低下させる欠陥を隠します。 同様に、3Dバージョンでは、シャドウマップテクスチャのサイズを変更できます-デフォルトでは512x512です。

結論

• 「ナイーブ」レイキャスティングは、トップエンドのマシンでのみ良好なFPSを提供し、ビデオカードをひどく加熱しました
• 「改善された」レイキャスティングと3D-以下の条件下で、テストされたすべてのマシンでChromeに少なくとも40 FPSを与えました。
  
  
  • -1つの光源
  • -4つの光源+ 2xテクスチャ/シャドウマップの削減
  
  
  
• これまでのFFでは、すべてが悲しい
• レイキャスティングの場合、影が動くオブジェクトを投影するときに問題が発生します。このため、3Dマップを再描画し、各フレームのシェーダーに送信する必要があります。
• three.jsによる3Dソリューションの場合、ライブラリの機能に大きく依存しています。 影を青くできないとしましょう（理由はわかりません）。 そして、「床」（GGの下の明るいスポット）の光源からのまぶしさは、私がまだ取り除くことができませんでした。

以上です。 お役に立てば幸いです。



LDの同僚であるRuslanとTolaがテストに協力してくれたことに感謝します。