JOGLを使ってJAVA+OpenGLによる３Ｄアプリ製作

切羽詰った状況だったので更新が止まってました。申し訳ありません

JOGLプロジェクトページ（英語）

最近リアルタイムで３ＤＣＧを計算処理させるとなるとDirectXやOpenGLなどのライブラリを扱うほか無いんですが、CUDAやClose to Metalが登場してさらに環境依存が酷くなりそうです。OpenGLはGLUTなどがあるため、他と比べるとそこまで酷くは無いんですが、やはりCやC++での開発は結構つらいものがあると思います。

対してマルチプラットフォームをターゲットとしているJavaで３ＤＣＧの計算処理はあまりよくないと思ってたのですが、どうもOpenGL2.0のAPIをJavaにラップしたJOGLというライブラリがあるみたいです。
OpenGL2.0といえばGLSLのサポート。と言うことはシェーダー言語が使えますが、GLEWがないとドライバの関係でGLSLが使えないみたいです。が、どうやらJOGL自体にGLEWが含まれているらしく、他の人のBlogなどでJOGLでGLSLが使えたという記事も見られます。

GLSLが使えるとなると、かなり処理に余裕がでるんじゃないでしょうか。少なくともシェーダー言語内の記述はGPUが処理するので、ビデオカードがサポートしていれば頂点の座標変換やピクセルシェーディングなどの処理はハードウェアで処理されます。
何か急にJavaを使うメリットが出てきたような気がします。私はDirectXの上C++を使ってプログラミングをしているので、実行速度はさすがに速いですが、コードの管理に関してはものすごく頭が痛くなりました。
環境依存によってプログラムがまったく動かない状況もあって、何回も泣きを見ました。

C#もManaged DirectXはフェードアウトしてXNAになるみたいですし、（XNAの仕様はまさにマゾヒスト）今後ＧＰＵを使ったプログラミングは面倒になるんだなぁと思ってたので、良い傾向かもしれません。
でもJOGLを使うかはまだ決めていません。まずJavaプログラミングの方法自体忘れてます。

GPUプログラミングの時代？

最近DirectXの仕様がコロコロ変わるせいで、DirectX10をビデオカードを新たに買ってまでやろうという気力がありませんでしたが、１年前になりますがよさそうなニュースがあったのでネタにしてみます。

CUDA Zone
※英語サイトなので注意。

雑に読むと、DirectXなどのライブラリを介さずにGPUネイティブコードのプログラミングができるそうです。Ｃ言語がベースみたいなので、知識のある方は困らないと思います。面白いのがMATLABのプラグインを備えてるみたいです。MATLABの計算処理にGPUを使う形になってるのかな？
実際３ＤＣＧはベクトル幾何や線形代数の塊なので、物理計算などはお手の物でしょう。
CUDAはnVidia Geforceのみで、さらに8xxxのビデオカードでないと対応しないみたいです。PC買い換えなきゃ…

ただ関数セットなどをチェックしてないので、付属のライブラリでどこまでできるかはまだ把握していません。
これだったらDirectXを一から勉強するよりずいぶんとましだと思いますが…

作ったモノへの評価の難しさ 反省編

　前回からずいぶん間が空いてしまいましたが、反省をしてみたいと思います。とりあえずダメだった（ダメになってしまった）部分を列挙。

・構想があったものの、その構想を絞って限定的なものにしてしまった。
・内部仕様を作ってる途中で（何度も）変更した。
・GUI部分とソフトのコア部分を切り分けずに作ってしまった。
・System.Windows.Formの理解が浅かった。

　さて、一つ一つ見ていきます。まず一つ目。構想があったというのは、アニメを作りやすい環境を作るということです。絞って限定的なものにしたというのは機能を妥協して自分がプログラムしやすいものに変更した点に問題がありました。
この場合は自分のスキル不足が関係していて、理解できる範囲で作ろうとした事に原因があります。しかし理解せずにプログラムを組むことは不可能であって、それを補うためのブラックボックス的なライブラリがあったとしても、ブラックボックス部分を知らないとどちらにしろ満足に扱えず、バグを生んでしまうという危険があります。
　二つ目。これはメモリ（バッファ）への一時格納と、独自ファイル拡張子での保存を考えてたら、理解できる範囲でアレコレやってたら、それ以外の機能の内部仕様を弄くることになりました。このせいで実装したかった機能が詰めなかったという結果になりました。メモリ圧迫を無視した場合、何百メガのメモリを食う結果を見てしまい、焦って実装したのが悪かったのかもしれません。
　三つ目。GUI部分はあくまで処理（イベント）を起こさせるだけのものなので、GUIに依存させないためにプログラムのコアを分けて作るべきでしたが、問題なくスラスラ書けてしまったために後でGUIの変更をしたくてもできなくなってしまいました。まったくもって間抜けでした。
　四つ目。三つ目に関係しますが、Formの挙動を理解していなかったのが今回最も反省するべき点です。今回DIBを使って前後のレイヤーと下絵を表示しているのですが、これが遅くて遅くて…。メモリ圧迫を無視して作るならDirectXを使うことを考えていたのですが、どうにも面倒で仕方なかったのでかなりやっつけで半透過表示を実装したのが逆にパフォーマンスの低下を促してしまったのかもしれません。

今回まともにFormを使ったプログラミングだったのですが、使っていくうちにボロボロになってしまいました。一応例外落ちやバグは出ないつくりにはなってると思いますが、確証は取れないのが痛いところです。Fixしようとしても一から作り直したほうが早いという結論があります。
とりあえず作ってる最中は夢に見るまで悩むことが多いので、これがなくなればもうちょっと楽にプログラミングできるのではないか？と思います。

＃夢にまでプログラミングする事が出てくるのは寝てるのに休んでる気がしない…

作ったモノへの評価の難しさ

衝動的に『○○が作りたい！』と思うのは自分の悪い癖だと思いますが、これが今後の糧になる場合も多いので、よっぽど変な事以外は即実行に移ってます。その一つが今回自分で作ったアニメ作成支援ソフトだったりします。

そのソフトの主な機能は下のとおり。
・画像を複数枚扱え、連番になっているためパラパラ漫画風に絵が描ける。
・線の太さは調整できるが、黒の単色しか扱えない。消しゴム機能使用可能。
・アンドゥリドゥを実装している。
・独自形式でファイル保存可能、連番の画像として一般の画像形式で出力可能。
・前後のレイヤーを透過表示できる。
・下絵が透過表示できる。

という具合に、フォトショップ並の機能は到底ありません。
最低限の機能に便利な機能をつけたつもりだったんですが、これが作った後に実際に自分で使ってみて評価をすると実に使えないことが判明。
前後フレームの透過表示や下絵の透過表示にはかなり頭を捻ってコードを書いたのですが、パフォーマンスがでるように作ったのはいいものの、結局は全フレームが透過表示できたほうが便利という結論に届きました。
そうなるとプログラムの仕様が大きく変わるどころか、雛形まで変更する羽目になるのでほぼ一からのコードの書き直しになってしまいます。
メモリ管理もメモリを食わないように処理をしたり、独自ファイルに使う容量も減らすなどの処理をしているのですが、評価した時の結論でこの処理がほぼ使えなくなります。
かなり機能限定して洗練したつくりにするつもりだったのですが、こうなってしまうとWindowsのペイントよりも機能的に劣ってしまうことになります。

改めてモノづくりの難しさが身に堪えた感じがします。今回はC#の内部ライブラリだけ使っていますが、今回の失敗から考えるとDirectXなどのハードウェアを扱うライブラリを使うか、全く独自のコードで機能を実装するかになりそうです。
とりあえず実験的な試みは終わったので、今回弄るのはここまでにしようと思います。

ゲームを作りたい。 その２

さて、ゲームを作りたいという考えが未だに残ってるので、諦めが付くように色々とまた調べてみました。その中でXNAをもう少し調べてみると意外と面白そうだということが分かりました。
まずは下のリンクを・・・ってManagedDirectXを知らないと分からないかも。
http://www.microsoft.com/japan/msdn/directx/xna/migration.aspx

C#をターゲットにすると、ManagedDirectX（以下MDX)が3Dコンテンツを使うとき中心となるライブラリなのですが、XNAはMDXを基本としていまして、設計部分は似通った部分があります。ただしMicrosoftの性質上、「過去遺産は基本的に使えない」というのが根底にありまして、似てるとは言ってもそのまま使えるはずも無く、結局覚えなおしが多い部分も否定できません。
ただ、プログラミングの流れは変わらないので、MDXを使っていた方ならすんなりXNAを扱えるようになれるのは間違いないと思います。

前置きはさておいて、上のリンクを斜め読み気味に読んでみますと、

・固定シェーダーが消えて、すべてプログラマブルシェーダーで処理させること。
・関数の記述方式が変わり、ゲーム作成に必要な関数セットが減った。
・名前空間の変更
・メッシュとアニメーションのセットが削除。該当するものが無い。

大きな変更点としてはこのへんですかね。2番目と3番目はいつものことですが、XNAとMDXで大きな違いは1番目と4番目でしょうか。
1番目はリンク先だとメリットのように書きますが、シェーダープログラミングをするまでもない場合（試作段階のプログラムや簡単な設計にしたいときなど）が大きな問題となります。ただ、BasicEffectという固定シェーダー風に扱えるクラスがありますので、回避は出来そうです。
4番目は大問題です。多分バージョンアップで付くとは思いますが、現時点では自分で実装しないといけないのでかなり労力が食われると思います。

とまぁ、落とし穴が多そうなのが現状です。初期化が更に簡単になったのは評価すべき点でしょうか。
まだまだ調べる必要がありますね。

ゲームを作りたい。

腹が決まったので、やることもだいぶ絞れてきました。・・・かといってそれほど暇になったわけでもありませんが、またゲームを作りたい病にかかったのでいろいろと下調べしています。
最近ゲーム開発系の記事を見てるのですが、コンシューマーはやはりいまだにC言語が主らしく、C++やその他の言語は殆ど使わないというのが現状らしいです。ただXBOX360だけは別らしく、C#?を使っているのか開発が楽だそうです。
PCゲームだと言語はC++がメジャーでそこからさらに3D系のゲームはDirectXやOpenGLのライブラリを使うのが定石となっています。
DirectXなら研究で作ったアプリでも最低限レベルで使っているので少しは理解できると思いますが、それ以外だとどんなつくりになっているのかまるっきり不明です。

ホットな話題だとXNAといってXBOX360機上で動くように設計したライブラリパッケージがあるそうですが、アマチュアが気軽には扱えないようなものらしく、有料のライセンスを買う必要があるみたいです。
作るのには問題ないらしいのですが、今のところ個人ユーザーのゲームが出揃うまで様子見といった感じでしょうか。

XNAを使う以外にも簡易ライブラリやHSPやLGPなどのゲーム作成などを重点においてる中間言語を使ってゲームを作るという手もありますが、ちょっと心細いといった感じでしょうか。
LGPは触ったことがあるのですが、オブジェクト指向言語でないのと、変数が独自のものなので使うのは諦めました。

どの方法を取るのが良いのかというのはゲームの規模にも依りますが、ゲームの基礎中の基礎のPongやSTGを作っても受けが悪いんでしょうね・・・

スパゲッティコードその２

　気づいたら日数経っちゃいます。雑談気味に更新したほうが良いって事に気が付いていますが、良い内容が無いので前回に続いた内容の更新を致します。
　今回の内容は自分がプログラムを作っていくときに、プログラムがスパゲッティコード化している時に引き起こすことの例を書いています。他人のソースコードを読む時は大体どのプログラムもスパゲッティコードに見えますので・・・

-------------------------------------------------------------------
　スパゲッティコードについて前回説明したので、今回はスパゲッティコードは実際にはどんな問題を引き起こすかについて。スパゲッティコードは基本的にプログラムを作った本人が生み出すものなので、以下のことは自分でプログラムを作っていく時に起こる事を書いています。

・分からない（忘れた）命令をたどっていくと、命令間をたらい回しにされる。
スパゲッティコードの中でも一番良くあるパターンだと思います。自分が分からない（忘れた）命令のひとつを辿っていくうちに、元々何やってたか分からなくなるぐらい命令の移動をするプログラムを作ると起こります。

・命令を使おうと何度も試みるが、失敗（命令がちゃんと扱えない事）を繰り返す。
ちゃんと命令の入出力の理解をしっかりしていれば失敗は殆ど出ませんが、命令に対して例外処理を行っていなかったり、使う時の規則が複雑だと起こります。また汎用性を高めるために命令が処理できるデータの型を必要以上に緩くしてたりすると逆に命令の失敗を生み出す原因になったりします。

・命令に指定したはずのデータがうまく処理されない。原因が特定できない。
上の項目に似ています。大抵は一つの命令がプログラムエラー無しに誤作動を起こしているのが原因ですが、命令が複雑に多くつながっていると原因になってる命令が特定できない状態が起こります。一番頭を悩ませる例がこれです。

・データが収束できない。
特殊な型のデータを出力する命令をたくさん作った場合に、その違う型のデータ同士を収束させようとすると、さらにデータを収束するための命令を作る必要が出てきます。これはプログラム全体の見通しを悪くすることがあります。

・プログラム中に使っている変数を一つ弄ったらエラーが十数個出てくる。
これはスパゲッティコードには依存しない場合が殆どですが、相当酷い時の事例としてあげてみました。値の変更ができるはずの変数の値を弄ったらプログラムがまともに動かなくなるということがあります。

---------------------------------------------------------------------
スパゲッティコードが起こす恐ろしい事は大体こんなところです。
実際はまだまだありますが、起きやすい例をまとめると上のようになります。

今回もこれぐらいで・・・

スパゲッティコードその１

はい、ネタが無いんでまた前回と同じような感じです。今回もまたCGの話は一切出てきません、残念。
まず先にタイトルがその１になってるのは、何回かに分けないといいたいことが分かりにくいようなので、
章じゃありませんが、事例を追いながら書いていこうかと思います。

---------------------------------------------------------------------------
スパゲッティコードとは・・・という話はGoogleなどで検索してもらったら分かりますが、プログラミングを
してない人には理解し辛いと思います。この時点でスパゲッティコード化が起こってると言えます。
まずはスパゲッティコードが何であるかというのを分かりやすく考えてみましょう。

スパゲッティの麺を一本ずつに考えると、麺の長さが分かると思います。
この長さをプログラムの行数と考えてみましょう。単位はセンチでもミリでも良いです。
例えば長さ20センチの麺が作れるとします。本当は1000センチ分ぐらい無いとお腹が膨れないとします。
さて、長さ20センチのスパゲッティの麺でどうやったらお腹が膨れるでしょうか。

答えは簡単、20センチの麺を50本用意すれば1000センチ分になり、お腹をいっぱいにできます。
この麺をゆでて食べるようにします。茹で加減を調べたいので、パスタレードルを使って『一本だけ』味見用に
引き上げてみようと試みます。結果的に十数本の麺がすくい上げられました。
これがスパゲッティコードの状態です。

「パスタレードルじゃなくて箸を使えよ！」という声が挙がってきそうです。その通りだと思います。
これから分かるのは、一つは『スパゲッティコード』という言葉を作ったのは日本人じゃないということです。
もう一つは、プログラミングには箸のような便利な道具が無いということです。

これを芋に例えると分かりやすくなります。ジャガイモでもサツマイモでも良いですが、
栽培した芋を収穫する時に、茎を持って引き上げようとします。自分は1個の芋だけで良いとしても、
ズルズルと長い茎とたくさんの芋がくっついてきます。

----------------------------------------------------------------------------
スパゲッティコードの説明は分かりましたか？
私はスパゲッティコードという言葉自体がまわりくどくて理解し辛いと思います。

前置きで終わってしまいましたが、今回はこれぐらいで・・・