2012/05/13

cocos2dでパレットっぽいことをしてみたい その2

以前書いていたエントリーの続きです。その時はシェーダープログラムが全くわからない状態だったので試さなかったのですが、cocos2d 2.0がRC1になったこともありますので、シェーダーに手を出してみました。ここ最近やってるUnityでのシェーダー入門がうまく役に立っているってのもありますね。ちなみにシェーダー入門にUnityは向いているような気がします。すぐに絵を出せますからシェーダーコードに注力できます。とはいえShaderLabという特殊な記述方法となるのでOpenGL ESでGLSLを使うのとは若干違いますけど。まぁ考え方は一緒です。

●以前のアイデア
1,テクスチャ書き換え
2,白い素材を用意し、マテリアル色指定
3,シェーダーでリアルタイム書き換え

 というアイデアを出していました。2までは前回達成しています。1はバッチが効かず、メモリ圧迫も多いため事実上使わないほうがよい手法でした。2については前回のレベルでは限界値で、ぎりぎり実用レベルだった感じです。
 さて、今回は3を実装しました。

●前回の評価を考えなおす
 前回は以下のように3を評価していました。

 利点:テクスチャが共通なので省メモリ
 欠点:僕はシェーダー作ったこと無い。OpenGLES2に対応したcocos2d2.0のベータ版を使わないとならない。描画が遅いかもしれない。シェーダーに渡すパラメータが色ごとに変化するので、CCSpriteBatchNodeで処理させるには難しいかも?

 最初の欠点は今では問題ないです。個人的に。
 2番目はcocos2d 2.0 RC1となったので問題ないでしょう。
 3番目はやってみないとわからない。
 4番目はバッチ処理するためのいい方法を考えましたので、次項で説明します。

●バッチ処理のために
 cocos2d 2.0のソースを見ていると、cocos2dの描画に必要な基本的なシェーダーが全部用意されています。その中身を読んでいくとスプライトの色を設定してもバッチ描画を可能にするための技を確認できました。
 通常OpenGL等では、いわゆるマテリアル(テクスチャ)が違うものはバッチ処理ができないものですが、頂点座標、頂点カラー、頂点UV値、オブジェクトのTransform情報については違っていても1つのDrawコマンドで描画することができます。Transform情報についてはcocos2dの内部で1オブジェクトとなるようにバッチノードに登録されたすべてのスプライトを1つのバッファに入れ込んで参照しているからですね。その他のパラメータは頂点に備わっている情報なので、1つながりのバッファにしてしまえば1度に送れます。
 というわけで、cocos2dでは1.0の時からそうだったようですが、スプライトの色は頂点カラーへセットすることでバッチ描画を可能にしてたんですね。これを使わない手はありません。
 シェーダーでパレットチェンジするための色変化情報は頂点カラーへもたせましょう。頂点カラーはRGBAの4チャンネルしかないので1枚のスプライトのなかに持てるパレットインデックスは4種類しか持てなさそうです。その中でアルファにはスプライトの透明度が入っているので使えないでしょう。ということでRGBのチャンネルに色変化情報を与えてやって1枚のテクスチャにつき3色変更可能というようにしました。

●パレット処理の仕様
・テクスチャのRGBをそれぞれ好きな色に変更可能
・変更後の色は頂点カラーRGBへ3色セットする(Rが1色目、Gが2色目、Bが3色目)
・セットする色はビット圧縮をかけて入れる(RGB=3:3:2bit)
 ビット圧縮で8bitに収めたのはccColor3BでCCSpriteを継承したクラスに色をセットしたり、cocos2d通常の描画ルーチンを流用するためです。ビット圧縮はHSVとかYUVを使った方が色の再現性がいいかもです。そのうちやってみます。

●パフォーマンスはどうかな?
上:cocos2d 1.0 白テクスチャに色設定して重ねたもの


左:cocos2d 2.0 白テクスチャに色設定して重ねたもの
右:cocos2d 2.0 でシェーダーで色変化させたもの

 3つテストしました。
 前回作成した上のものは、アイドル時には60FPSが出ることもありましたが、画面がスクロールすると描画される頂点数が変化して頂点バッファを作り直すのに時間がかかるようで、最低では25FPSまで下がるようです。
 左のものは、同じソースをcocos2d 2.0で動作させたものです。60FPSから落ちることなくスイスイ動いています。これでいいんじゃないかという気もします。cocos2d 2.0からはフレームレート表示に上から、ドローコマンド数、処理時間、FPSの3つが表示されます。バッチが効いているのでドローは3(背景、キャラたち、ラスター線)です。処理時間はアイドル時0.007で、画面スクロール時には0.017までかかります。
 右のものは、パレットチェンジシェーダーで表示したものです。これも60FPSから落ちることはありません。バッチ描画ができているのでドロー数もかわりません。処理時間はアイドル時0.004で、画面スクロール時には0.017までかかります。
 というわけで、なかなかの好成績です。結論から言うと通常描画が速いのでシェーダーでやらなくてもいいかもという気もしなくもないですw cocos2d 2.0は描画が速いですね。

 今回は以上です。
 今度6/21に行われる予定のcocos2d bootcampでcocos2d 2.0のシェーダーについてのLTをたぶんやるとおもいますので、もしよろしければ聞いてください。

2012/05/12

cocos2d 2.0への移行


●ライブラリの移行
 既存のcocos2d1.0系プロジェクトを2.0へ移行するのはとても簡単です。基本はlibsグループ以下に登録されている各種cocos2dのソースを一旦削除して、2.0系のものを入れなおすだけです。これは今までのcocos2dのバージョンアップでも同じですね。
 
 1.0系ですと、大体以下のものが置かれてます。
 ・cocos2d
 ・CocosDenshion
 ・cocoslive
 ・FontLabel
 ・TouchJSON
 
 これを2.0にすると以下のようになります。
 ・cocos2d
 ・CocosDenshion
 ・kazmath

 kazmathは見慣れないものですけど、中身をみるとベクトル・マトリクス演算系のライブラリだということが分かります。OpenGLES2.0ではマトリクス演算が弱くなるので、そのあたりを補完するためにはいっているのだろうと予想します。
 
●その他の設定
 さて、上記入れ替えと、いくつかProjectのBuild Settingsに値を変更しないといけません。
 
・Header Search Pathsの指定
 なぜかkazmathへのパスが通らないことがありますので、以下のような感じで設定しておきます。
 $(SRCROOT)/../cocos2d-iphone-2.0-rc1/external/kazmath/include/
 
・コンパイラの変更
 Apple LLVM compiler 3.1 にします。

・PreprocessingへDefineを追加
 Apple LLVM compiler 3.1 - PreprocessingのReleaseへ値を追加します。
 NDEBUG
 NS_BLOCK_ASSERTIONS=1
 以上の2つです。別にこれがなくても困りませんが、cocos2d 2.0のテンプレートでプロジェクトを生成すると上記の設定が行われるので、やっておいたほうがいいでしょう。

●初期化周りのソースの修正
 cocos2d 2.0では1.0系と違ってglViewの生成に関する部分が大きく変更されていますので、AppDelegate.mとかを2.0で生成したプロジェクトのソースをコピペして少し整える必要があります。あと、いままで使用していたRootViewController.mは必要なくなるので、削除します。cocos2dのフレームバッファ初期化部分をカスタムしていない人はそれほど大変な作業ではありません。カスタムしてトリッキーなことをさせていた場合には何がどうなっているか理解してから修正しましょう。
 あんまり簡単に修正できたので、僕の認識では、libsだけ入れ替えたら普通にビルドできましたよーとか勘違いしてましたが、初期化部分はソースの修正必要です。


 以上で移行完了です。普通にビルドも通るとおもいます。ひょっとしたらフレームワークが足りないことがあるかもしれませんが、怪しいところはGameKitくらいですかね。
 公式の移行ガイドがここにありますので、参考にしてみてください。変更になったAPIなども書かれていますので、複雑なプロジェクトの場合には影響があるかと思います。
 
 ではー。

2012/05/10

Unity ShaderLabでのあれこれ

 最近Unityを触っています。ShaderLabでiOS向けシェーダーを書いているのですが、その中で気づいたことなど書いてみます。

●モバイル向けシェーダーの心得

 各種Unity勉強会に出ましたけど、iOS等モバイル向けシェーダーではリアルタイムライティングはご法度ということ。普通はバーテックスシェーダー内でライトマップを参照したり、ライトプローブを参照して色を取ってきてフラグメントシェーダーで色を載せるということをやるようです。
 いい例となるのがShadowGunのシェーダーサンプル。このアプリではリアルタイムライティングは完全に行っていませんでした。背景など動かないものはライトマップの参照がメイン。カメラからの相対ベクトルでの擬似スペキュラーライティングを若干与えているので、これについては平行光源での頂点ライティングと同じくらいの処理負荷はかかるものと思われます。キャラでは、ライトプローブ参照と擬似スペキュラーライティングでした。
  iOSでのシェーダーサイクルは以下の数値。(PVRUniSCoEditor調べ)

背景用シェーダー
 vert cycles: 72
 frag cycles: 6

キャラ用シェーダー
 vert cycles: 86
 frag cycles: 28

 となっています。背景のフラグメントシェーダーが軽いことがよく分かります。6cyclesという数値はUnity標準のMobile/Unlit(Support Lightmap)での7cyclesよりも軽い数値なのが驚きです。

 速いシェーダーを書くには、なるべく演算精度を下げるのが良いです。floatなんで言語道断。halfもかなり絞りたいです。fixedがほとんどになると思います。あとは、あたりまえですけど、演算コード量を減らすことですね。
 さらに、コツとしてフラグメントシェーダーは描画面積に対して掛け算で重くなっていくので、バーテックスシェーダーで事前に処理出来る部分はなるべくそっちで計算させておくというのもいいです。ShadowGunのシェーダーでバーテックスシェーダーのサイクル数が多めなのはそのせいですね。
 ちなみに、バーテックスシェーダーで事前計算した値はもちろん頂点毎の情報となりますが、フラグメントシェーダーへ値が受け渡された時点で頂点間で値が補間されますので、まあまあ良い感じになりますよ。


●Unityでのバッドノウハウ

 ライティングがご法度ということでなるべくライティング計算を行いたくないのですが、ライトカラーだけは参照してどうにかしたいとか、ライトベクトルだけ参照して良い感じに使いたいとかあると思います。
 で、普通はSurfaceシェーダーを使ってライティング計算を書くわけなんですけど、Unity内部で何が行われているかわからないので、無駄を省くのが難しいとかありますよね。

ライトカラー参照
 てなわけで、以下のようなコードで直接参照したくなります。

SubShader {
  Pass {
    Lighting Off
  }
  CGPROGRAM
  #pragma vertex vert
  #pragma fragment frag
  #include "UnityCG.cginc"
  struct v2f {
    float4 pos : SV_POSITION;
    fixed2 uv : TEXCOORD0;
    fixed3 col : COLOR;
  }
  v2f vert(appdata_base v) {
    v2f o;
    頂点演算は省きます。
    o.col.rgb = _LightColor0.rgb;
  }
  フラグメントシェーダーは省きます。
  ENDCG
}

 でも、なんかライトの色が取得できないことがありますね。Lighting Offが効いているみたいです。 というわけで、一応ライティングしますよって宣言してやらないと色が取れないみたいです。Passの前にTagで指定します。
Tag {
  "LightMode" = "Vertex"
}

 みたいにやります。すると色がちゃんと取れます。ちなみに、unity_LightColor[0].rgbでも取得できます。cgincを読むとこっちのほうが後々まで使用できる宣言みたいですお。

ライトベクトルが取りたい
 はい。これなんですけど、公式ドキュメントに書かれている_ObjectSpaceLightPosが宣言されていないらしく、一見取得出来ないように見えます。なので、しかたなくSurfaceシェーダーでやるしかないかなぁとか思うのですけど、unity_LightPosition[0].xyzで行けます。

実機でGLSLコンパイルが通らない!
 なんかね、Unity上では正しくシェーダーがコンパイルできて表示も問題なくても、XCodeで実機ビルドすると実機での実行時にGLSLが正しくコンパイルされないことがあるんですよ。原因はバーテックスシェーダーでのVaryingパラメータの命名が同名にされてしまうことがあるということ。
 現象としては、このコミュニティでの記事と同じです。xlv_という変数が大量に宣言されちゃうみたいなんですね。
 これを解消するには、struct v2fでの中身にsemantic nameで何らかの指定をつけておくと良いというもの。
struct v2f {
  float4 pos : SV_POSITION;
  fixed2 uv : TEXCOORD0; <これとか
  fixed custom : TEXCOORD1; <これとか
  half4 custom2; <これはだめ
}

 みたいな感じです。カッコ悪いしなんだかなぁと思いますけど、これで実機実行時には、xlv_TEXCOORD1とかで参照されることになって名前がかぶらなくなるわけです。…ひどい。ひどすぎるぜUnity!

実機だと描画結果が違う!
 MacとかでUnity Editor上でみてる描画結果と実機での描画結果が違うことがあります。特にfixed変数を使っているところで。まあ、これは普通にGLSLを書いてOpenGLESでやってるときにも起こることですけど。
 この場合は、fixedの部分をhalfに置き換えていくと描画結果が一致します。どこを戻さないといけないのか試して少しづつやるといいです。なるべくfixedを使ったほうが軽いですから。
 ちなみに、GLSLベタ書きの場合は、lowpが問題になってます。mediumpに変えていくと直ります。同じ事ですね。


 以上です。最近苦労してたことが大体わかってきたので、まとめておきました。Have a nice shader life!