プログラミングの最近のブログ記事

（前回の記事の続きです）

さて、自作のWebGLのゲームをenchant.jsベースで作り直そう、とした場合にですね。
問題となってくることがあると書きました。

それはなにかというと、enchant.jsのWebGLプラグインである「gl.enchant.js」を使うべきか否かという問題です。
gl.enchant.jsはenchant.jsのお作法ベースで簡単にWebGLの機能が使えますよ。という、いわばシーングラフベースに近い3Dライブラリなんですが、
これがまた自由度が低い低い、非常に割り切った設計になっています。

（以下はgl.enchant.jsのバージョン0.3.7の仕様）
・プリミティブの形式はgl.trianglesのみ（ストリップとかファンとかは使えない）
・デプステストやカリングの有無を切り替えられない（有効で決めうちされている）
・自前のシェーダーが使えない（gl.enchan.js内部で独自のシェーダーが使われている）
・ライティングが標準で有効（オフにできない）
・シェーダーを切り替えられないので、マルチテクスチャとか当然できない。

ほんとに、「ボク３D初めて！」な人向けのライブラリですね。
glコンテキストを取得すれば、色々できるのでしょうが、glコンテキストを引き渡してくれるメソッドも無い模様。

一応、任意形状のポリゴンを描画する機能はあるようですが、いかんともしがたい作りです。

とはいえ、改造してしまえばそれなりに便利そうなんじゃないかというのも事実。
というか開発した人が「そういうことやりたかったらぜひ改造してください」的なノリみたいなw

gl.enchant.jsの補助プラグインで、MMDプラグインとかCOLLADAプラグインとかあるしなー。これらの中身まだちょろとしか見ていないんですが、
これらがちゃんと動いているのは、gl.enchant.jsのドノーマルの機能を使っているのではなく、
実際、gl.enchant.jsのメソッドを上書きして、シェーダーをプラグイン独自のものに切り替えたりとかして、色々やっているわけです。

正直、enchant.jsベースにしつつも3D描画についてはglコンテキストを抜き出してgl直打ちした方が自由度は高いんでしょうけども、
gl.enchant.jsベースにすれば、コーディングの作法がenchant.jsベースの作法に統一できるし、シーングラフベースのAPIはいろいろ楽なことも確かです。

問題はパフォーマンスと細かい制御なんですが、
・前者については、作ろうとしているゲームが、FPSやアクションみたいに、べらぼうにシビアな描画パフォーマンスを要求するようなゲームではない。
・後者については、gl.enchant.jsを改造すればいいんじゃね？　もしくは機能を上書きするプラグインを開発すればいいんじゃね？

ということで、検討を重ねた結果、gl.enchant.jsベースでやってみようかという方向に傾き中です。

しかしなー。どうなんだろうなー。エフェクトツールの「BISHAMON」がそのうちWebGLランタイムをリリースするらしいし、
そうしたら多分、絶対glを直接いじらないと使えないようなランタイムだろうから、
gl.enchant.jsと併用するには、BISHAMON.gl.enchant.jsみたいなプラグインを自作しないとダメだろうなw

うーん。色々大変になりそうだ……。この判断が吉と出るか凶と出るか……w

っと、その前にまだこのことをbeiさんと相談していないんだった（汗）
こういうことはちゃんと話し合った上で決めないとダメだよな^^;

前回の記事で、WebGLによる３D描画と、enchant.jsによる2D描画を組み合わせることを検討しているという話をしましたが、一つ問題があります。

ゲームループの問題です。

現在、私のWebGLゲームプログラムはrequestAnimationFrameによる自前のループを持っています。まぁゲームなんだから当然ですよね。

で、2D描画をenchant.jsにやらせようと、enchant.jsを軌道（game.start()）すると、そう、enchant.jsのゲームループ（requestAnimationFrame）も回るのです。

つまり、ゲームループが２重に発生してしまう。

以下の清水氏による記事では、
http://d.hatena.ne.jp/shi3z/20130521/1369101883

< 引用ここから>

enchant.jsはフレームワークとライブラリの間にあるギリギリの線を狙っている。
　enchant.jsはしかし厳密にはライブラリである。

　なぜかというと、

enchant();

window.onload=function(){
core = new Core(320,320); //ここでコアを初期化する
}

　このように、ライブラリの導入からコアの起動までをユーザが記述する必要があるからだ。
　純粋なフレームワークなら、window.onloadの処理は隠蔽する。

< /引用ここまで>

厳密にはライブラリ、とのことで、その思想含め、「なるほどなぁ」と思いましたが、
やはりenchant.js自身でゲームループを管理している以上、「やはりフレームワークなんじゃないか」という気もするわけです（笑）

で、解決方法ですが、考えられるのは以下の二つですね。

A) enchant.jsを改造して、自前のゲームループを使わせるようにする。
B) 思い切って、ゲームループはenchant.jsに任せてしまう。

いろいろ考えたんですが、A)の改造をした場合、enchant.jsのバージョンアップのたびに改造しなきゃなりません。（いっそゲームループ関連をカスタマイズできるようにしたものをPull Requestしてしまうという手もありますが……多分絶対はねられると思う）

B)の場合、それならもう全部enchant.jsベースでゲームを作り直した方がいいんじゃね？　という話にもなります。

実際、enchant.jsはプラグイン含め、日を追うごとにどんどん高機能化・多機能化しており、乗っかってしまった方が、ゲームに求められるもろもろの諸機能を自作するより開発効率は間違いなく上がるでしょう。（パフォーマンス面はちょっと気になるんですけどね）

なので、今のところ、ゲーム全体をenchant.jsベースに作り直してしまおうという方向に傾きつつあります。

ただ、これはこれでまた別の気になる問題があります。それについてはまた後ほど……。

WebGLでのゲーム開発。ぼちぼちと進んでいます。

ゲームのジャンルは何かというとRPGなのですが、最近のRPGといえば、キャラクター同士の会話シーンがありますね。ノベルゲームとかADVゲームみたいなゲームによくある、キャラクターの立ち絵があって、画面下にメッセージボックスがある感じの。

ああいうのは、WebGLで描画するより、2D Canvasで描画する方がいろいろとやりやすいです。

とはいえ、それでも2D Canvasを直に触るのもめんどいので、enchant.jsを採用しました。enchant.js、そういうノベルゲームを簡単に作れるプラグインがありますし（そのプラグインまで実際に採用するかは別にして）

最近のenchant.jsは、デフォルトではDOMベースではなく、Canvasベースの描画システムです。

さてさて、本題はここから。
WebGLは、jpgやpngといった画像ファイルだけでなく、2D Canvasもテクスチャとして利用できるのです。

ということは、enchant.jsで描画した2D Canvasを、WebGLのテクスチャとして利用できるはずなのです。

実際に、こちらのサイト様のコードをベースに、実験してみました。
http://edotprintstacktrace.blogspot.jp/2012/01/html5-canvas-2d-context-webgl.html

実験結果がこちらの動画。
http://www.screencast.com/t/P6rMKeKn

通常のテクスチャ（犬の画像）に、マルチテクスチャでenchant.jsで描画したCanvasテクスチャ（クマ）を合成しています。

enchant.jsのCanvasの中で、描画していない部分（クマの周り）は、アルファが0なので、アルファ抜きもできているわけです。
試してませんが、当然アルファブレンディングもできるはずですね。

というわけで、WebGLと2D Canvasの描画の使い分け、おすすめです。

WebGLであるゲームの開発をやっているんですが、テクスチャ関連で以下のエラーが出てくるんですよ（ちなみにブラウザはChrome）。

RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering or is not 'texture complete'

もうね。何かと思って。テクスチャサイズは256x64だし、フィルタリングの指定も間違ってないし。色々ググったり試行錯誤して辿り着いたオチが……。

「テクスチャ画像の読み込みが完了していない状態でレンダリングを行ったから」

あー、たしかに or is not 'texture complete' って書いてあるけどさ……。
ふつー、non-power-of-2の方に注目しちゃうだろ。
おいら、まさかなーあるわけないよなーとか考えながらも画像サイズを256x256に変えてみたりとかアホみたいなことしちゃったじゃまいか。

何が ~ or ~ だ。どっちの原因なのかそこまでちゃんとチェックして、適切にエラーを出せ、と。

WebGLの画像ファイル読み込みは非同期なので、ちょっと横着して、テクスチャの読み込みが完了する前に描画命令しちゃうのはよくある事だと思うのですよ。

そういうケースも考えて、シンプルに「まだロード完了してないよん」とか言ってくれればいいのに、「non-power-of-2」とかいうからもう誤解しちゃったじゃんよ。

こういう「原因は〜〜〜かもしれないし〜〜〜かもしれません」的なエラーって設計した人はどういうつもりで作ったんだろう。
仕様的に判断が難しいというのは考えづらい気がするんだよなー。

OpenGLとOpenGL ESが今後統合される可能性が出てきたそうで……。まだ確定ではないですが。
もしそうなった場合、モバイルGPUはサポートしなければならない機能が底上げされるわけで、なかなか面白いことになりそうな予感。
http://www.4gamer.net/games/107/G010729/20130324001/

まぁそれはそうと、もっと個人的に気になっているのはnvFXの方かな。
OpenGLの世界では、cgfxを除いて、DirectXであった便利な「エフェクトファイル」の仕組みがありませんでした。
その福音となりそうなのがnvFXです。
http://masafumi.cocolog-nifty.com/masafumis_diary/2012/10/nvfx-4556.html

ライセンスは何になるか不明ですが、ApacheとかMITライセンスあたりになってくれると、かなりいいんだけどな。

しかし、Githubのリポジトリは未だにReadmeくらいしかなく、かなりお寒い状況。

Sorry for postponing again : I need to wait for the legal Department of
NVIDIA to give me the green light on publishing the source code.
January should be ok.

とのことですが、大人の事情ですか。内部ではちゃんと開発進んどるんだろーな。
一応、スライドで正式に発表したんだし、オイラ期待しちゃうんだからね！！

追記(2012/03/27)：どうやら、NVIDIAの開発者イベントGTC 2013で、nvFXのセッションがちゃんとあった模様。開発は続いているみたいね。よかった。
https://registration.gputechconf.com/form/session-listing&doSearch=true&queryInput=&topic_selector=Computer+Aided+Design&type_selector=none

（この記事でいう「CG技術」とは「CG制作ソフトの使い方・ノウハウ」ではなく、「CG理論・プログラミング技術」を指します）

こないだ、ある人から、「ゲーム作りとかに興味があって、CG技術を効率的に学んでいきたいんですけど、どう手を付けたらいいですかね」と聞かれました。
「他にやることもあるんで、できるだけ無駄なくいきたいんですけど」と。

学問に王道なしとはいうけれど、たしかに社会人で勉強となると、できるだけ無駄なく効率的にやりたい、という要件は切実だと思います。
なので、私なりの考えを助言してみました。

例の、OpenGL（C言語）の課題を教えてくれと言ってきた学生さんですが、その後の話……ていうかついさっきの話です。

課題の〆切が過ぎたようなので、参考にこちらのソースコードを送ってあげたのですが、
「最後にお願いがあります。
プログラムの
・プログラムの概略
・プログラムの操作説明書
・プログラムの実行過程に関するできるだけ詳細な解説書
を書いてください。何度もすみません。」

どうやら、自力では課題をクリアできずに、期限延長で提出しないといけないようで、私のプログラムをそのまま提出しようとしているようです（しかも、提出用のドキュメントまで私に作らせようという……）。

おまい、俺が言った説教を忘れたのか、と。
あれだけ自力でやるのが大事だと言ったのに、何を言っているのか、と。
そんな不正を平気でする子に育てた覚えは無いっ！（違

ちょっと、真面目に叱ろうと思います。

ホント、どこの大学か割り出して担当の先生に通報してやろうかしら……？（笑）

前回の書き込みしかり、最近、メールで知人や知らない人からプログラムの質問を受けることがよくあります。

ちょっと面白かったのが、Web開発初心者の方で、「ネットに公開しているWebアプリなんですが、プログラムミスにより、パスワードのハッシュが外部から見れる状態になってしまっていました。」
「でも、ハッシュだから、パスワードそのものでないし、大丈夫ですよね？」

思わずのけぞってしまいました。まぁ、初心者さんだとセキュリティの勉強まであまり手が回らないのかもしれませんが。

当然のことながら、パスワードハッシュが漏れるのは、かなり危険です。

ハッシュ化につかった関数が何かバレてしまえば、パスワードの総当たり式で次々にハッシュを作成して、漏れたハッシュと一致するものが見つかれば、それがユーザーが使っているパスワードということになります。

また、総当たり式にしなくても、レインボーテーブルと呼ばれるものを利用することで、もっと高速にパスワードを特定することも可能です。

まぁようするに、ハッシュを見た人間が悪意をもっていて多少の知識があれば、簡単にパスワードがバレてしまうのです。

ということで、その人にはパスワードを再設定するよう、伝えておきました。

実は、かくいう私も、
セキュリティの勉強、まだまだ不十分です。
大々的に宣伝をしていないとはいえ、私もあるWebノベルツールをはじめとしたWebサービスを開発・運用しているので、こうしたことに関しては常に勉強を続けなければなりません。

まー、あまりやってて楽しい分野ではないんですけどねw

なんか、mixiで知らない学生さんからこんな頼み事をされた。
「OpenGL(C言語）の課題を出されたんですけど、わかりません！　教えてください！」
しかも、「今週の水曜日までにお願いします！」という期限付きｗ

普通の人なら怒るか無視するけど、私はお人好しなのでちょっとアドバイスしてあげた。
ちなみに、その課題とは以下のようなもの。
・適当に直方体の領域を作る
・その内部で適当に跳ねまわる球体を複数個配置する
・初期位置は領域内、初速は適当に設定してよい。重力方向、重力加速度も適当でいい。
・球体と外壁、球体間の接触判定を行い、適切に跳ねかえるようなプログラムを作成する。
・球体の数を動的に増やせるようにする。同時接触が起こった時の挙動がちゃんと動くプログラムであること。

なんというか、OpenGLというより高校物理の問題ですなこれは。
運動量保存則と反発係数の式を使えば楽勝です。（ただ、ちょっと面倒なのはめり込んだボールを引き離す処理ですね）

で、ちょっと面白そうだったのでちゃちゃっと作ってキャプチャしてみました。
http://screencast.com/t/VLewd0EpM0i
（キャプチャソフトの仕様でカクカクしてますが、実際はもっとなめらかです）

この課題、学生用に球体に限定しているので簡単なんですが、これが一般形状だったら、本格的な剛体物理シミュレーションが必要になってきますね。

作ったソースコード、今すぐその学生さんにあげちゃうと勉強にならないので、課題の締め切りが過ぎた後に見せてあげる予定です。

まぁ、こういう学生さん、非常識ではあるけど、こういう無鉄砲さというか、なりふり構わず、という姿勢は実は嫌いじゃないです。
スティーブ・ジョブズとか、こういうなりふり構わず、身もふたもない行動で成功をつかみ取っていますからね。まぁ、周りにすごい迷惑はかけますけどｗ

プログラミングコーナー「Web Programming」にて、
「heroku postgresのDBにローカルPCから遠隔アクセスする」を公開しました。

HerokuというPaaS（クラウドサービス）は、Web開発者の間ではかなり人気の開発プラットフォームなんですが、そのHerokuでメインで使われているDBはPostgreSQLです。
このHerokuサーバー上のPostgreSQLのDBに遠隔アクセスする方法を記事にしてみました。

以前は、この方法が分からずにDBデータをいったんローカルにダウンロードして、ローカルで編集して、サーバーにアップロードする。というやり方でしかメンテナンスできないでいました。
今回のこの方法で、ようやくHerokuサーバーのDBを直接メンテナンスできるようになり、いやー気分がスッキリしましたw

やっぱり、GUIのDBクライアントを使ってメンテナンスできるのは便利だよね。

って、はい。今回もほとんどの人にとっては意味不明な記事でしたねw

気にしないでください……orz