4/28にさいたま勉強会に参加してきました。今回は「エフェクトの作り方」として手描きアニメーションによるエフェクト作成の基礎みたいなものを発表させてもらいました。参加者はプログラマばかりなのであまり目に触れる機会のないものだったかと思いますが、単純に見て楽しい内容に映ったようなので良かったかなと思います。
さいたま勉強会はどんな内容でも発表して良いよというものなので、何が発表されるか毎回ドキドキなのですが、今回もかなりバリエーションに富んだ内容でした。
今回のおしながきは以下のとおり。
・@dsgarageさん Arduino×Unity
ArduinoをUnityからコントロールしようというお話。シリアル通信で制御可能なはずとのことですが、一からコードを作るのがなかなか困難とのことで、uniduinoというアセット($30)の紹介とともに制御の方法について解説しておりました。Arduino Esploraというゲームパッド型のArduinoがあるそうで、それも気になります。
・@k_katsumiさん SECoreTextView
SECoreTextViewという岸川さんの自作ライブラリの紹介。URLやTwitterのユーザー名、ハッシュタグ、画像などが含まれたリッチテキストの表示を簡易に行うためのライブラリです。かなり応用範囲が広そうな便利なものと感じました。また発表ではどうやって実装しているかの細かい話まで聞けてものすごく濃かったです。
・@ajinotataki(私です) エフェクトの作り方
ゲームにおけるエフェクトはどういうものがあって、どうやって作られているかを軽くおさらいした後に手描きエフェクトの基礎の紹介。その後はリクエストに従って手描きをライブでやりました。細かくは後述します。
・@akisutesamaさん Parseでガチャ回すお
Parseという簡易サーバーサービスを使っていわゆるガチャをどうやるかについてを例に使用方法を紹介。データベースとしては設計を先にしなくてもデータ優先で作っても自動的にサーバーができていく点は良い。しかしサーバー側で実行するコードがJSでデバッグがしづらいなど、そちらの面は難ありとのこと。小規模開発やプロトタイプで使用する分にはいいのではとのことでした。
・@yoichinejiさん Logic Proの活用と耳コピについて
Logic Proを買ったもののどう使って良いかという状況に光を当てる発表。耳コピについてはWaveToneというアプリが非常に便利そうでした。
さて、エフェクトの発表についてですが、当日のスライドはこちら。PDFはこちら。
で、手描きの基礎に入るわけなのですが、以下の2つがわかればなんとかなるかなと思って紹介しました。
1つは、「移動の錯覚」で、以下のような点の後に線が表示されることで点が移動して見えるというもの。
それをディテールを整えると以下のようになります。
もう1つは「送り」で自然現象は繰り返し出てくるパターンが移動していくように見えることが多いのですが、それを意識して絵を描くということ。
こんなのも「送り」に含まれると思います。
で、ディテールを整えると、以下のようになります。
という感じに紹介しました。
その後は会場のみなさんにリクエストを貰ってその場で描きました。
以下のは電撃での攻撃。パズドラみたいに手前から奥に攻撃するイメージ。
これ描いてる時の録画を岸川さんがやってくれたのですが。それはこちら。
以下のは水属性の攻撃。これも同様に手前から奥に攻撃するイメージ。
以下のは召喚的なイメージ。何かが現れた感じですね。
これ描いてるのを、これまた岸川さんに録画していただいたのですが、それはこちら。
以上でした。
ここで紹介したアニメ素材については自由にしてもらって構いません。
ではではー。
あ、当日のツイートまとめはこちら。
2013/01/15
ライトマップのシェーダーをMac, iOSで両立するには
先日の記事でライトマップを別シーンで使うために、自前のライトマップシェーダーを用意して行うようにしてましたが、いざそれをiOSへ持っていくとそのままだと問題がでることがわかりました。
ま、絵が出ないってことなんですけどね。
Unity標準のライトマップシェーダーもそうなっているそうですが、LightModeの設定にライトマップ方式がいくつかあるのには理由があるらしく、環境によって有効な設定が違うようです。LightMode=VertexLMRGBMはMacならばOKですが、iOSでは何も出ません。逆にLightMode=VertexLMの場合はiOSはOKですが、Macでは何も出ません。という感じです。
てなわけで、どうするか。
UnityのShaderLabにはSubShaderというタグがありまして、それを使うと有効なシェーダーが実行時に選ばれるというものがあります。これを使えばいいんじゃない?とすると、以下のようになります。
ところがこれではダメで、LightModeでどうなっててもどうやらSubShaderレベルでは有効なシェーダーとして判別されてしまうようです。なので、やるなら以下のように1つのSubShaderの中に2つをいれてしまいます。
こうすると片方は何も描画しないのでうまくいくようです。たしかに実際にうまく表示できました。使わない方のPassのオーバーヘッドが無いのかどうかについては調べきれてないです。GLSL化された後のコードを見れば分かるとは思うんですけどね。
参考1:Alpha-VertexLit.shader
http://dorumon.googlecode.com/svn/trunk/pwars/Assets/Standard%20Assets/DefaultResources/Alpha-VertexLit.shader
参考2:Multiple target platform lightmap shader
http://forum.unity3d.com/threads/75487-Multiple-target-platform-lightmap-shader
ま、絵が出ないってことなんですけどね。
Unity標準のライトマップシェーダーもそうなっているそうですが、LightModeの設定にライトマップ方式がいくつかあるのには理由があるらしく、環境によって有効な設定が違うようです。LightMode=VertexLMRGBMはMacならばOKですが、iOSでは何も出ません。逆にLightMode=VertexLMの場合はiOSはOKですが、Macでは何も出ません。という感じです。
てなわけで、どうするか。
UnityのShaderLabにはSubShaderというタグがありまして、それを使うと有効なシェーダーが実行時に選ばれるというものがあります。これを使えばいいんじゃない?とすると、以下のようになります。
SubShader {
Tag { "LightMode" = "VertexLMRGBM" }
}
SubShader {
Tag { "LightMode" = "VertexLM" }
}
ところがこれではダメで、LightModeでどうなっててもどうやらSubShaderレベルでは有効なシェーダーとして判別されてしまうようです。なので、やるなら以下のように1つのSubShaderの中に2つをいれてしまいます。
SubShader {
Pass {
Tag { "LightMode" = "VertexLMRGBM" }
}
Pass {
Tag { "LightMode" = "VertexLM" }
}
}
こうすると片方は何も描画しないのでうまくいくようです。たしかに実際にうまく表示できました。使わない方のPassのオーバーヘッドが無いのかどうかについては調べきれてないです。GLSL化された後のコードを見れば分かるとは思うんですけどね。
参考1:Alpha-VertexLit.shader
http://dorumon.googlecode.com/svn/trunk/pwars/Assets/Standard%20Assets/DefaultResources/Alpha-VertexLit.shader
参考2:Multiple target platform lightmap shader
http://forum.unity3d.com/threads/75487-Multiple-target-platform-lightmap-shader
2013/01/12
Unityのライトマップを別のシーンで使う
Unityではライトマップはシーンデータに固定されて、他のシーンで使用することが出来ないというのが仕様ですが、他で使用するための方法を考案しました。最初は適当にライトマップを貼れるシェーダー書けばいいんでしょって思ってましたが、どのあたりに制約があるのかわかりました。
てなわけで、まずはモデルへの焼付けを行います。通常通りモデルやライトをstaticにしてLightmapウィンドウにて焼き付けます。今回はキャラにトップライトを設定して、主にオクルージョンの焼付けをメインにしたような調整で行いました。こうするとある程度キャラに動きが入ってもそこそこ見た目が破綻しないので。
こんなかんじになります。わかりにくいですが、エプロンの下に影が落ちています。トップライトの影とオクルージョンが入っている感じです。エプロンを腰の後ろで縛っている部分にもオクルージョンが入っていますね。
試しにこれで動かしてみたら、以下のようになります。(なんか色が違ってますけど、細かいことは気にしないでください。テストレンダリングなので微妙に設定違いだったりするからです)
で、これを別のシーンにもっていくわけですが、普通だとunity_LightmapSTという値がシーンで管理されているために、正しい描画結果になりません。ライトマップがずれて表示されたりします。このunity_LightmapSTっていう値はどこにどう設定されているのかということですが、LightmapウィンドウのObjectタブを見ると焼き付け後には値が入っていることが分かります。
下の方にある、Tiling X, Tiling Y, Offset X, Offset Yがそれです。このそれぞれの値がunity_LightmapST.xyzwに入るようにUnityのシステムからシェーダー側へuniform変数として受け渡されます。これを元にシェーダー側ではUV2のスケーリングとオフセットを行なってズレを修正するので、ライトマップが正しく貼れることになります。
さて、では自前のシェーダーでライトマップ用UV2のズレを修正するには上記の値を何らかの状態で保持しておいてシェーダーに伝達すればいいので、マテリアルのプロパティとして値を追加して持って行く事にしました。以下の用に設定します。(注、自前シェーダーのプロパティなので、普通のシェーダーにはありません)
ちょっと図が細かいですけど、先ほどの値をマテリアルのLightmapSTのVectorへセットしてあります。ちなみにシェーダーコードは以下の様な感じです。HalfLambert + Lightmap + Ambientにしてあります。
描画結果はどうなるかというと、以下の様な感じです。ライトマップ焼付けが白のトップライトだったのですが、下の図では横からの赤いライティングでベースに緑が入っているのがわかります。横からの赤いライトがDirectionalLightでHalfLambertになってます。ベースの緑はAmbientですね。ライトマップの影響はほんのりと分かる感じになってます。
シェーダーコードのことで注意ですが、LightModeはVertexLMRGBMを選択しないと正しくライティングできません。LMRGBMじゃないとライトマップのデコードが出来ないみたいです。とはいってもシェーダーコードの中では特にライトマップとして扱ってるわけでもないんですけどね。謎です。なお、今回はライトマップを1枚で焼き付けましたけど、Dualの場合にはVertexLMを選択することになるみたいです。細かいことは以下を参考に。
http://docs.unity3d.com/Documentation/Components/SL-PassTags.html
とはいえ、unity_LightmapSTに縛られたくない場合には、他の方法も考えられます。
1,ライトマップの焼付けを3dsmaxやSoftimageなどのDCCツール側で行う。UV2も自前で展開してね。
2,Unityでライトマップ焼付けた後にunity_LightmapSTの補正をスクリプトで計算して、UV2へ書き戻してしまう。これならunity_LightmapSTの値がシーン違いで失われても問題ありません。マテリアルもモデル毎に増えないしいいかもしれない。
以上です。
てなわけで、まずはモデルへの焼付けを行います。通常通りモデルやライトをstaticにしてLightmapウィンドウにて焼き付けます。今回はキャラにトップライトを設定して、主にオクルージョンの焼付けをメインにしたような調整で行いました。こうするとある程度キャラに動きが入ってもそこそこ見た目が破綻しないので。
こんなかんじになります。わかりにくいですが、エプロンの下に影が落ちています。トップライトの影とオクルージョンが入っている感じです。エプロンを腰の後ろで縛っている部分にもオクルージョンが入っていますね。
試しにこれで動かしてみたら、以下のようになります。(なんか色が違ってますけど、細かいことは気にしないでください。テストレンダリングなので微妙に設定違いだったりするからです)
で、これを別のシーンにもっていくわけですが、普通だとunity_LightmapSTという値がシーンで管理されているために、正しい描画結果になりません。ライトマップがずれて表示されたりします。このunity_LightmapSTっていう値はどこにどう設定されているのかということですが、LightmapウィンドウのObjectタブを見ると焼き付け後には値が入っていることが分かります。
下の方にある、Tiling X, Tiling Y, Offset X, Offset Yがそれです。このそれぞれの値がunity_LightmapST.xyzwに入るようにUnityのシステムからシェーダー側へuniform変数として受け渡されます。これを元にシェーダー側ではUV2のスケーリングとオフセットを行なってズレを修正するので、ライトマップが正しく貼れることになります。
さて、では自前のシェーダーでライトマップ用UV2のズレを修正するには上記の値を何らかの状態で保持しておいてシェーダーに伝達すればいいので、マテリアルのプロパティとして値を追加して持って行く事にしました。以下の用に設定します。(注、自前シェーダーのプロパティなので、普通のシェーダーにはありません)
ちょっと図が細かいですけど、先ほどの値をマテリアルのLightmapSTのVectorへセットしてあります。ちなみにシェーダーコードは以下の様な感じです。HalfLambert + Lightmap + Ambientにしてあります。
描画結果はどうなるかというと、以下の様な感じです。ライトマップ焼付けが白のトップライトだったのですが、下の図では横からの赤いライティングでベースに緑が入っているのがわかります。横からの赤いライトがDirectionalLightでHalfLambertになってます。ベースの緑はAmbientですね。ライトマップの影響はほんのりと分かる感じになってます。
シェーダーコードのことで注意ですが、LightModeはVertexLMRGBMを選択しないと正しくライティングできません。LMRGBMじゃないとライトマップのデコードが出来ないみたいです。とはいってもシェーダーコードの中では特にライトマップとして扱ってるわけでもないんですけどね。謎です。なお、今回はライトマップを1枚で焼き付けましたけど、Dualの場合にはVertexLMを選択することになるみたいです。細かいことは以下を参考に。
http://docs.unity3d.com/Documentation/Components/SL-PassTags.html
とはいえ、unity_LightmapSTに縛られたくない場合には、他の方法も考えられます。
1,ライトマップの焼付けを3dsmaxやSoftimageなどのDCCツール側で行う。UV2も自前で展開してね。
2,Unityでライトマップ焼付けた後にunity_LightmapSTの補正をスクリプトで計算して、UV2へ書き戻してしまう。これならunity_LightmapSTの値がシーン違いで失われても問題ありません。マテリアルもモデル毎に増えないしいいかもしれない。
以上です。
2012/07/01
さいたま開発勉強会4回目で発表しました。シェーダーについてGLSL, cocos2d, UnityのShaderLabまで
6月30日に久しぶりにさいたま開発勉強会が行われましたので、蕨の商工会議所まで行って来ました。遅刻遅刻〜ってタクシーで急いで会場まで乗り付けたんですけど、どうやら会場があいて無くて入れない様子。会場代払ってるのに管理者が来なかったみたいです。なんということ!
急遽隣の区民会館に部屋を借りて勉強会を行うことになりました。プロジェクターが無くてスライド共有に苦労しましたけど結果的にはうまくいってよかったです。
さて、当日の発表内容は以下のとおり。
・@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_さん:10時間で!無料で!アプリプロモーション
スライド:http://www.slideshare.net/AsamiNagasaki/10-13490251
・@yoichinejiさん:cocos2d-x + ○○でどうにかしてこれしたい
スライド:なし、tweetで発表でした。
急遽隣の区民会館に部屋を借りて勉強会を行うことになりました。プロジェクターが無くてスライド共有に苦労しましたけど結果的にはうまくいってよかったです。
さて、当日の発表内容は以下のとおり。
・@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_さん:10時間で!無料で!アプリプロモーション
スライド:http://www.slideshare.net/AsamiNagasaki/10-13490251
・@yoichinejiさん:cocos2d-x + ○○でどうにかしてこれしたい
スライド:なし、tweetで発表でした。
私は、先週のcocos2d勉強会に続き、シェーダーを掘り下げた内容の発表を行いました。
おおまかな流れとしては、
・シェーダーとは何か、概念的な説明
・シェーダーを使って何ができるかの実例
・OpenGLESでのシェーダーを使うための流れ
・それを踏まえてcocos2dでシェーダー使用の流れ
・cocos2dでオリジナルシェーダーを使うための改造ポイント
・cocos2dでのシェーダーデモ
・Unityでシェーダーを使うために
・ShaderLabの基本的な説明
・VertexShader, FragmentShaderを内包する場合の例
・SurfaceShaderを使う場合の例
という感じです。
前の発表会ではそもそもシェーダーに対しての事前知識が無い受講者に対していきなりコア部分の話をしてしまってよくわからないという事態を引き起こしてしまったので、反省して、今回はシェーダーとは何かという部分にページを割いて概念としての説明を丁寧にやってみたつもりです。
他の発表者さんでは@tmokitaさんの発表内容が良かったです。1問1答形式でTIPSをバンバン紹介していく感じで、あまり知られていない内容のものもちょこちょこあり非常に為になりました。
@nun_さんの発表は時間の都合で割愛されてしまったようで残念でした。
で、我らが@yoichinejiさんのネタですけど、今回はプロジェクターが無いことでいつものようにネタを展開することができなかったようで、ネタバレにならないようにtweetを駆使してやる感じでしたね。
開発言語がC++であるということが共通項となるので、Kinect + cocos2d-xというのを組んでみたという発表でした。まだ未完成ではあるそうですけど、Kinect関連で画面描画するのはなかなかとっつきにくいらしいので、cocos2d-xを使用出来ればいいんじゃないかとのことです。
以上でした。
2012/06/22
cocos2d勉強会2回目で発表しました
●スライドはこちら
●サンプルソースはこちら
内容としては以下の様な感じです
・シェーダーとは何か
・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が並行開発出来ない時点でフレームワークとしてどうなのよと言われたら言い返せませんよね。
短かったですが、なかなか興味深い勉強会でした。
ではまたー。
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を使った方が色の再現性がいいかもです。そのうちやってみます。
●パフォーマンスはどうかな?
●以前のアイデア
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なども書かれていますので、複雑なプロジェクトの場合には影響があるかと思います。
ではー。
登録:
投稿 (Atom)