世界に人が降り立ちました。

空を水色で塗りつぶしました。

土地と空の境界を溶かしました。

今日は”土地”の描画です。昨日のインスタンシングを利用して、立方体を画面下部に敷き詰めました。

“自分の土地”は、基本 7 * 7のサイズがあります。”お隣さん”を含めると21 * 21 のサイズになります。

立方体を 21 * 21 個描画すると、インスタンシングを利用して7,392バイトとなります。

現状、高低差がないので立方体である必要はなく平面を描画すれば十分なのですが、将来的に高低差が付く可能性があるので立方体にしておきます。

最終的に立方体である必要がなければ、最適化してメモリサイズを削減します。

今回は インスタンシング(drawElementsInstancedANGLEのAPI)を利用してテクスチャ付きの立方体を描画した場合、どのくらいメモリ使用量が削減出来るかを確認しました。

比較対象は、昨日の GL_TRIANGLE_STRIP の描画データです。

結果は次の通りです。

単位：バイト

立方体の数	GL_TRIANGLE_STRIP	インスタンシング
1個	336	352 (104.76%)
10個	3,432	496 (14.45%)
100個	34,392	1,936 (5.63%)

インスタンシングの場合、ベースの立方体のデータ336バイト(GL_TRIANGLE_STRIPで1個の立方体を描画した場合と同じデータ量）に加えて、1つの立方体に付き位置情報(x, y, z)3 * 4バイトと種別(今回は画像の通りテクスチャを変化させました。4バイトの型を利用しました) を指定することで、ベースデータを流用してメモリ使用量を抑えつつ、同じ形をいっぱい描画することが可能です。

1つの立方体の場合は336 + 12 + 4 = 352バイト、10個の場合は336 + (12 + 4) * 10 = 496バイト、100個の場合は336 + (12 + 4) * 100 =1936バイトとなります。

比べるのも馬鹿らしくなるくらいメモリ使用量が減りました。

(♡ >ω< ♡)

アプリ作成の下準備として、描画方式によるメモリ使用量の比較を行いたいと思います。

今回は WebGL 1.0 の GL_TRIANGLES と GL_TRIANGLE_STRIP でテクスチャ付きの立方体を描画した場合、どのくらいメモリ使用量に差が出るか確認しました。

以下が結果です。

注意：この表を鵜呑みにしないで下さい。私の想定(立方体に対して自由にテクスチャを貼るとか)に縛られた部分で最適化出来ずにバイト数が大きくなってしまっている部分があります。

単位：バイト

立方体の数	GL_TRIANGLES	GL_TRIANGLE_STRIP
1個	864	336 (38.89%)
10個	8,640	3,432 (39.72%)
100個	86,400	34,392 (39.81%)

情報としては、頂点座標(float型*4バイト3)とテクスチャ座標(float型4バイト*2)を使用し、頂点数分のインデックスバッファ(unsinged int型 4バイト*頂点数)を使って描画(drawElementsのAPI)した場合を計算しています。

GL_TRIANGLESは独立した三角形を組み合わせて立方体を描画した場合で、1つの立方体を描画するのに12の独立した三角形の情報が必要です。

1つの三角形を描画するのに必要なバイト数は、頂点 (x, y, z)*3 + テクスチャ座標 (x, y) * 3 + インデックスバッファ * 3 = (9 + 6 + 3) * 4 = 72バイト

1つの立方体を描画するのに12の三角形が必要なので、72*12 = 864バイトとなります。

GL_TRIANGLE_STRIPは同じく三角形を組み合わせた描画ですが、2つ目以降の三角形は、1つ前の三角形と辺を共有しています。このリンク先のイメージを見てもらうとわかるのですが、立方体が14の頂点情報で定義できます。ただし、立方体と立方体を離れた別の場所に同時に描画する際、繋がらないように縮退三角形を利用する必要があり、2個以上の立方体を1回のドローコールで描画する場合は、2個目以降の立方体に対して2つの余分なインデックスバッファ(unsinged int型 4byte * 2)を使う必要があります。

1つの立方体を描画するのに必要なバイト数は、(3 + 2) * 14 * 4 + 14 * 4 = 336バイト で、2個目以降は 344バイトです。

結果の表を見てわかる通り、2倍以上の差が出ました。かなり大きな差なのではないでしょうか。

明日はインスタンシング(drawElementsInstancedANGLE)を利用して更に削減します。

昨年から今年にかけて、デアゴスティーニ商法作業管理法という、デアゴスティーニ商法に習って作業を細切れにする開発手法を独自に編み出して(?)実践しました。

すると、毎日少しずつですが確実に作業を進めることに成功して、Lifegame Lightningアプリを無事リリースすることが出来ました。

Lifegame Lightningアプリはおかげさまで好評のような気がします。たぶん。怖くてまだ売上本数を確認していませんが。どこかの国で売れに売れまくっているのではないでしょうか。1億本くらい。たぶん。

ㅤ○○○
○ ･ω･ ○ がおー
　○○○
c(_ｕｕﾉ

というわけで本題です。

次にリリースするアプリの構想とタイトルが決まったので、本日からデアゴスティーニ商法作業管理法によるアプリ開発第2弾をスタートしたいと思います。

今回制作するのはハイクオリティ(自分の中では)3DグラフィックMMOで、タイトル名は「隣の田所さん」です。

毎週月曜日に、その週に実施する作業計画を立てます。無理はしません。毎日サクッと終わる分量にします。デアゴスティーニ商法ですから。

1日目(9/3火)：立方体の描画方式によるメモリ使用量の比較 — GL_TRIANGLES、GL_TRIANGLE_STRIP
2日目(9/4水)：立方体の描画方式によるメモリ使用量の比較 — drawElementsInstancedANGLE
3日目(9/5木)：土地の描画 その1
4日目(9/6金)：土地の描画 その2
5日目(9/7土)：プレーヤーの描画 その1
6日目(9/8日)：プレーヤーの描画 その2
7日目(9/9月)：予備日(次の週の予定を立てる)

もう一度書きます。タイトル名は「隣の田所さん」です。