さいたま開発勉強会４回目で発表しました。シェーダーについてGLSL, cocos2d, UnityのShaderLabまで

６月３０日に久しぶりにさいたま開発勉強会が行われましたので、蕨の商工会議所まで行って来ました。遅刻遅刻〜ってタクシーで急いで会場まで乗り付けたんですけど、どうやら会場があいて無くて入れない様子。会場代払ってるのに管理者が来なかったみたいです。なんということ！
急遽隣の区民会館に部屋を借りて勉強会を行うことになりました。プロジェクターが無くてスライド共有に苦労しましたけど結果的にはうまくいってよかったです。

さて、当日の発表内容は以下のとおり。

・@ajinotataki：シェーダーしよっ☆ GLSL, cocos2d, UnityのShaderLab
　スライド：http://www.slideshare.net/xionchannel/lets-play-shaders
　サンプルコード：http://xionchannel.no-ip.org/cocos2d_shaderTest.zip

・@tmokitaさん：iPhone開発 超超初心者Tips50 (寝たければ寝てね！)
　スライド：http://www.slideshare.net/tmokita/saitama-beginner-tips50

・@f_megmeg5さん：Androidクラスタの私がcocos2d-xでマルチディスプレイ対応してみた
　スライド：http://www.slideshare.net/megmegfive/vol4-13446073

・@shun_nakaharaさん：iOSのGCDについて
　スライド：http://www.slideshare.net/shunnakahara/gcd-13499796


・@nun_さん：１０時間で！無料で！アプリプロモーション
　スライド：http://www.slideshare.net/AsamiNagasaki/10-13490251

・@yoichinejiさん：cocos2d-x + ○○でどうにかしてこれしたい
　スライド：なし、tweetで発表でした。

私は、先週のcocos2d勉強会に続き、シェーダーを掘り下げた内容の発表を行いました。

おおまかな流れとしては、

・シェーダーとは何か、概念的な説明

・シェーダーを使って何ができるかの実例

・OpenGLESでのシェーダーを使うための流れ

・それを踏まえてcocos2dでシェーダー使用の流れ

・cocos2dでオリジナルシェーダーを使うための改造ポイント

・cocos2dでのシェーダーデモ

・Unityでシェーダーを使うために

・ShaderLabの基本的な説明

・VertexShader, FragmentShaderを内包する場合の例

・SurfaceShaderを使う場合の例

という感じです。

前の発表会ではそもそもシェーダーに対しての事前知識が無い受講者に対していきなりコア部分の話をしてしまってよくわからないという事態を引き起こしてしまったので、反省して、今回はシェーダーとは何かという部分にページを割いて概念としての説明を丁寧にやってみたつもりです。

他の発表者さんでは@tmokitaさんの発表内容が良かったです。１問１答形式でTIPSをバンバン紹介していく感じで、あまり知られていない内容のものもちょこちょこあり非常に為になりました。

@nun_さんの発表は時間の都合で割愛されてしまったようで残念でした。

で、我らが@yoichinejiさんのネタですけど、今回はプロジェクターが無いことでいつものようにネタを展開することができなかったようで、ネタバレにならないようにtweetを駆使してやる感じでしたね。

開発言語がC++であるということが共通項となるので、Kinect + cocos2d-xというのを組んでみたという発表でした。まだ未完成ではあるそうですけど、Kinect関連で画面描画するのはなかなかとっつきにくいらしいので、cocos2d-xを使用出来ればいいんじゃないかとのことです。

以上でした。

cocos2d勉強会２回目で発表しました

今日はcocos2d勉強会２回目がGREEさんの会場にて行われました。そこで、cocos2d（ver2.0系列）でオリジナルシェーダーを使うための方法について発表したので、以下に資料とか置いておきます。

●スライドはこちら
●サンプルソースはこちら

内容としては以下の様な感じです
・シェーダーとは何か
・OpenGLでのシェーダーを使うための基本的な流れの紹介
・それを踏まえてcocos2dではどの部分を修正すれば良いかを紹介
・実際のデモ
という感じでやりました。
twitterの発言の様子を後から見るとついてこれなかった方多数のようでしたので、申し訳ないです。先にデモをしたほうが良かったのでは？とおっしゃってくれた方もいらっしゃいました。

来週末のさいたま勉強会vol4でも同じ内容を多少詳しくしたものと、Unityでのシェーダーの記述方法について発表しますので、質問がある方はそちらに来てもらえると良いかと思います。また、twitterやメールでもご連絡いただければ答えさせて頂きます。

とはいえ確かにシェーダーを記述したり利用するのはハードルが高いし、そもそもcocos2dのような2Dライブラリで本当に必要なのかといえば、まず必要にならないので技術デモのような感じだったかと思います。逆にUnityではシェーダーは無くてはならない要素だったりするのでそちらの方が親和性が高いかもしれないなと思った次第です。

他の方の発表は以下のとおりでした。
・@Seasonsさんがこれまでのcocos2dの流れや海外の様子の紹介

・Walzer WangさんがSkypeを使用してのcocos2d-xの紹介

・@torotitiさんがOpenOfficeをレベルエディタとして使用してcocos2dで絵本を作ったという事例紹介

・@splhackさんがOpenfeintをアップグレードするとGREEになるよという話

OpenOfficeをレベルエディタに使用した話は非常に興味深かったです。OpenOfficeの保存ファイルはxmlと画像リソース等をzipで固めた形式なので、Rubyで展開してパースするのに便利だったということで、コンバートしたデータをcocos2dで再生するように環境を整えたとのことです。これは何かに使えそう！

そういやPSSSDKは地雷という話を懇親会で聞きました。まあiOSが並行開発出来ない時点でフレームワークとしてどうなのよと言われたら言い返せませんよね。

短かったですが、なかなか興味深い勉強会でした。

ではまたー。

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

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

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

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

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

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

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

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

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

●パフォーマンスはどうかな？

上：cocos2d 1.0 白テクスチャに色設定して重ねたもの

左：cocos2d 2.0 白テクスチャに色設定して重ねたもの

右：cocos2d 2.0 でシェーダーで色変化させたもの

　３つテストしました。

　前回作成した上のものは、アイドル時には60FPSが出ることもありましたが、画面がスクロールすると描画される頂点数が変化して頂点バッファを作り直すのに時間がかかるようで、最低では25FPSまで下がるようです。

　左のものは、同じソースをcocos2d 2.0で動作させたものです。60FPSから落ちることなくスイスイ動いています。これでいいんじゃないかという気もします。cocos2d 2.0からはフレームレート表示に上から、ドローコマンド数、処理時間、FPSの３つが表示されます。バッチが効いているのでドローは３（背景、キャラたち、ラスター線）です。処理時間はアイドル時0.007で、画面スクロール時には0.017までかかります。

　右のものは、パレットチェンジシェーダーで表示したものです。これも60FPSから落ちることはありません。バッチ描画ができているのでドロー数もかわりません。処理時間はアイドル時0.004で、画面スクロール時には0.017までかかります。

　というわけで、なかなかの好成績です。結論から言うと通常描画が速いのでシェーダーでやらなくてもいいかもという気もしなくもないですｗ　cocos2d 2.0は描画が速いですね。

　今回は以上です。

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

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
　以上の２つです。別にこれがなくても困りませんが、cocos2d 2.0のテンプレートでプロジェクトを生成すると上記の設定が行われるので、やっておいたほうがいいでしょう。

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


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

Unity ShaderLabでのあれこれ

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

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

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

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

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

　となっています。背景のフラグメントシェーダーが軽いことがよく分かります。６cyclesという数値は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!

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

　こんな感じに同じキャラなんだけど色違いのキャラをいっぱい出したい場合、2D表現が主流だった頃はパレットの色を変更することで実現するということがメジャーでした。しかし今の主流はテクスチャを使用した画像処理なためパレットの効果を入れるにはちょっと大変です。cocos2dもOpenGLベースなので条件は同じですね。ということで実現するには…と考えてみた。

●アイデア
１，テクスチャ書き換え
２，白い素材を用意し、マテリアル色指定
３，シェーダーでリアルタイム書き換え

　１と２の方法は「cocos2d for iPhone 1 Game Developer Cookbook」に処理の紹介がありますので、そちらがわかりやすいです。



１，テクスチャ書き換え
　肝はCCTexture2DMultableというテクスチャ書き換え機能のついたCCTexture2Dクラスを使うことですね。これはOpenGL側で管理しているテクスチャメモリを書き換える為のメソッドが追加されたCCTexture2Dだと思えば良いです。

　利点：元になるテクスチャが何色でもOK。

　欠点：色変更後のテクスチャはそれぞれ別にメモリに載るので不経済。テクスチャが共通じゃないのでCCSpriteBatchNodeが使えない。そのため描画が多少遅い。



２，白い素材を用意し、マテリアル色指定
　これは元の絵のなかの色を変えたい部分だけを切り分けた別レイヤーとして素材を用意し、白で描いておく。これを使ったCCSpriteを色指定することで色を載せるというもの。cocos2dの基本機能だけで実現できます。

　利点：テクスチャが共通化するのでCCSpriteBatchNodeが使え、描画が高速なはず。省メモリ。

　欠点：色を変えたい部分を分けた素材を用意するのが手間。



３，シェーダーでリアルタイム書き換え
　OpenGLES2以降であればピクセルシェーダが使えるので、描画時にリアルタイムに色変更して表示することができるはず。

　利点：テクスチャが共通なので省メモリ。

　欠点：僕はシェーダー作ったこと無い。OpenGLES2に対応したcocos2d2.0のベータ版を使わないとならない。描画が遅いかもしれない。シェーダーに渡すパラメータが色ごとに変化するので、CCSpriteBatchNodeで処理させるには難しいかも？



　以上が考えられるなぁと思いました。

　まずはお手軽なところからと、１の案をテストしたのが冒頭の画像です。iPhone4での表示ですが、１キャラあたり６レイヤーつかっていて、５０体表示という状態です。これで60FPS出ているので処理能力的には十分かもなぁという印象。ただし、MacBookPro上でシミュレーターでの実行結果は30FPSしか出ませんでした。CCSpriteBatchNodeは使ってません。
　cocos2dのcookbookで紹介されているままの方法では、色変更後のテクスチャはCCTextureCacheへ乗らず、同じ色変更を何度も指定すると同じテクスチャが量産されてしまうコードだったため、その部分は自前でキャッシュへ載せて共用するように直しました。

　次は２のアイデアを試そうと思ってます。そのためには絵素材を色別に分離して別々のテクスチャに分配する必要がありますが、手作業でやるのめんどい…。２の方が処理が速いのであれば、最終的には絵素材の分離ツールを作らないとだなぁとか思ったり。

●追記
　２のアイデアを実装して試したところ、CCSpriteBatchNodeの威力もあるだろうが１００人出しても60FPSラクラク回ってました。１レイヤー（というかCCSprite）には１色しか指定できないので、色分だけ枚数が増えてますがそんなの全く影響が見られないですね。下図は１キャラ１１レイヤー使ってます。ちなみに、CCSpriteのcolorプロパティで色を設定するとその色が乗算されるので黒の輪郭を色変更せずにそのまま残したいという場合は、どこかのカラーのスプライトに入れ込んでしまってもOKです。黒なので他の色を重ねても黒以外になりませんから。