2008年12月30日
レイトレ開発日誌 (2) 一応レイを飛ばしてみた
レイトレのお勉強は、ちょこっとずつ進行中です。
前回はただのGUIプログラムでレイトレしてませんでしたが、今回は一応レイトレ。
有名な Cornell Box の形が見えるところまでできました。
まだ光の明るさの計算は全然していないので、のっぺりとしたつまらない絵ですが、ちゃんとレイを飛ばして描画しています。
目標は、下の画像のようなやわらかい陰影の絵を描画することなんですが、遠い道のりだなぁ。
気が遠くなる。
投稿者 sike : 23:31 | コメント (0) | トラックバック
2008年12月27日
レイトレ開発日誌 (1) はじめの一歩
ゲームプログラマーもレイトレやんないとダメかなーってことで、OoOというイベントに行ってきました。
そこで感化されてレイトレプログラム書いてみようという気になりました。勉強中だった Haskell はとりあえずほったらそう。
言語はやっぱりC++。言語仕様が複雑すぎるとか、生産性が悪いとか、悪口を言われがちな彼ですが、なんだかんだいって使われているし、仕事で使って慣れてるから。
C# もいいんだけど、レイトレとか速度を求めるアプリケーションではちょっと不安。
(言語の問題じゃなくてGUIライブラリの問題かもしれないけど、 .NET のプログラムって動作がもったりしてるよね)
C++で問題になるのは、標準ライブラリでGUIやベクトル演算をサポートしていないことです。
どのライブラリを使ったらいいのか迷うんよねー。そもそもWindowsでGUIのコードはあまり書いたことがないのです。
wxWidgets とか ATL/WTL とか見てみたけど、どれもよくわからん。MFCは偏見でなんとなく嫌いなんだけど、レイトレを書くのが目的なのにGUIで悩んでいてもバカバカしいので、t-potの人のこれをまねっこしました。
とりあえず、レイトレはまだやってないけどGUI上に絵が出るよ、ということろまでで本日は終了。
投稿者 sike : 22:59 | コメント (0) | トラックバック
2008年12月15日
モナド
Haskell の本をだいぶ読んだ。
モナドの定義はわかるんだけど、まだ自分の血肉になっている感じがしない。
いろいろプログラムを書いてみればなじんでくるのだろうけど。
あと、IOモナドがうさんくさい。
IOモナドによって副作用なしに入出力が行われるってのは詭弁じゃねーの？
出力はともかく、入力を副作用なしにできるとは思えないのだけどなー。
IOモナドで入出力を行うところは、純粋関数型じゃなくて、手続き型っぽい処理になっている気がするのは気のせいなんだろうか？
いまいちしっくりこないので、おもわずモナドの歌を作ってしまったら、頭の中で無限ループしはじめて大変なことになった。
あいおーもなど！めいびーもなど！もなど、もなど、も・な・ど！（＊）
（＊）を無限に繰り返す
投稿者 sike : 23:49 | コメント (0) | トラックバック
2008年12月10日
Haskell 勉強中
本屋でふつうのHaskellプログラミングという本をたまたま見かけて、なんとなく買って、ただいま Haskell のお勉強中。
普段使っている C++ とか ruby とは全然違うので面白い。
代入もループもなかったり、無限の長さのリストが扱えたり、すごく変！
遅延評価すげー。でも、頭こんがらがる。
学生時代にちょっとかじった Lisp とか Prolog とかを思い出す。
リスト構造は Lisp のまんまな感じ。
Haskellのような純粋関数型言語が将来のゲーム開発で使われると言っている人もいるけど、正直これでゲームのコード書いたり、デバッグしたりするのはしんどい感じがするなー。
うまいこと、扱いやすい手続き型言語と組み合わせて適材適所で使う感じになるのかな？
投稿者 sike : 23:54 | コメント (0) | トラックバック
2008年10月18日
processing 始めました
processing ってのは、お手軽に使えるプログラム言語みたい。画像やアニメーションを扱うプログラム、インタラクティブなもの(ゲームとか)がわりと簡単に書けるようです。
ここからダウンロードして、展開(解凍)して、processing.exe をダブルクリックするだけで、プログラムを書いて実行する環境のできあがり！
のはずだったのだけど、いろいろ罠が...
1. 非ASCII文字を含むパスに置いてはいけない
デスクトップにある download というフォルダにダウンロードして、
そのままそこに展開(解凍)したら、processing.exe が正常に起動できませんでした。
スプラッシュウインドウは表示されるのですけど、その後何も起きない。
パスに含まれる "デスクトップ" という文字がまずいみたい。
英数文字のみのパスに移動したら起動できました。
2. 環境変数 CLASSPATH と PATH に注意
processing.exe は起動できたんだけど、サンプルソースを実行しようとすると、
ウインドウの下の領域にエラーが表示されました。
ずらずらと長いエラーが出てたのですけど、最後の部分はこんな感じ。
java.lang.NoClassDefFoundError: C:\Program Caused by: java.lang.ClassNotFoundException: C:\Program at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) Exception in thread "main" ERROR: JDWP Unable to get JNI 1.2 environment, jvm->GetEnv() return code = -2 JDWP exit error AGENT_ERROR_NO_JNI_ENV(183): [../../../src/share/back/util.c:820]
検索したら、こんなのが見つかりました。
「環境変数 CLASSPATH や PATH にスペースが含まれていると問題が起きることがある」
「環境変数 CLASSPATH や PATH に ダブルクォート(") が含まれていると問題が起きることがある」
ということっぽい。
僕の環境の場合、Path に "C:\Program Files\Subversion\bin" ってのが入っていたのが問題だったようで、ダブルクォート(")を取り除いたらうまく動きました。
スペースは何もしなくても問題ありませんでした。
とりあえず、なんとか動いたよ。
投稿者 sike : 11:50 | コメント (0) | トラックバック
2007年07月25日
スケジュール
仕事の並列度が上がってきて、スケジュールを意識して立てないと厳しくなってきた。
「スケジュールを立てる」って仕事は、必要性を頭では分かっていても、やったところで現実の残作業が減るわけではない割には時間がかかるし、真っ当なスケジュールが立てられたためしがなく、無力感が増すばかりで気が進まない。
でも、そうも言ってられない気がする。
そして、なんか少しは上手く出来そうな気がちょっとだけした。（ほんとか？）
みんなキッチリスケジュール立てて仕事してるの？
投稿者 sike : 23:14
2007年01月04日
遭難
もう一度物理シミュレーションのお勉強をしてみようと思っていろいろやってたら、わからんことのハイパーリンクでどんどん脱線していった。
数値積分でオイラー法を使うと誤差が大きいんだよなー。
ルンゲクッタ法ってのを使ったなー。どもそれってどういうの？
微分方程式の近似解を数値計算で求める方法らしい。
微分方程式と物理シミュレーションの数値積分と何の関係が？
そもそも微分方程式って何？学校でやったような気もするが…
姿勢を表わすクォータニオンの微分ってどうやって求めるんだっけ？
というかクォータニオン自体ちゃんと理解していないんだよなー。
球面線形補間って何？
なぜかGoogleで球面調和関数のページがひっかかったぞ。
気がつけば、最初の目的なんか全く忘れて数学の海で遭難してた。
知らないことが多すぎて絶望する。
投稿者 sike : 03:22 | コメント (0) | トラックバック
2006年12月14日
三角関数の多項式近似の係数
コンピュータで sin の計算をするときって、テイラー展開を低次の項で打ち切った多項式近似って感じの計算をしてるわけなのですが、その係数の求め方がよくわからん。
sin を テイラー展開（マクローリン展開？）すると、こんな感じになるでしょ。
sin(x) = x - x3/3! + x5/5! - x7/7! + x9/9! - ...
で、newlib の sinf の実装を見てみると、９次の項までを使った多項式近似になってて、こんな係数を使ってるんよね。
static const float r[] = {
-0.1666665668, /* -1/3! = -0.1666666666... */
0.8333025139e-02, /* 1/5! = 0.8333333333...e-02 */
-0.1980741872e-03, /* -1/7! = -0.1984126984...e-03 */
0.2601903036e-5 /* 1/9! = 0.2755731922...e-05 */
};
コメントに書いたのがテイラー展開したときの係数なのだけど、実際に使われている値と違うでしょ？多分、精度を上げるためにこんな係数を使っているのだと思うのだけど、どうやってこれを求めたのかが良く分からない。最小二乗法とかで求めるの？誰か知らない？
投稿者 sike : 01:43 | コメント (2) | トラックバック
2006年11月27日
flickr 始めました
何かのきっかけで見つけたこの飛び猫写真がラブリーすぎて、影響されたというのが一つの理由。
flickr は外部アプリケーションから使用できるインターフェースがそろってて、プログラマー的にそそられるというのがもう一つの理由。
例えば、flickrの写真をダウンロードして表示するスクリーンセーバー、 slickr とか Loopy とか。
例えば、絵を描いてflickrの画像を検索するシステム、 retrievr 。
おもしろーい。
投稿者 sike : 23:18 | コメント (3) | トラックバック
2006年06月01日
C++の例外を使う理由と使わない理由
Effective C++を読んでいると、普通に例外の話が出てくるんだけど、例外ってちゃんと使ったことないなー。 例外ってイマイチ旨味がわからんのよねー。 なので、少し調べてみた。
とりあえず箇条書き。 まずは、ネットで誰かが言ってたり、自分で調べてるうちに気づいた例外の旨味。
- コンストラクタの致命的エラーは例外でないと検出できない
- 例外クラスを派生させることでエラーの分類によるエラー処理ができる
- 深いところからエラーを呼び元に伝えるのが簡単になる
そして逆に、例外を使用しない（ほうが良いと思う）理由。
- コードサイズが大きくなる
- 例外安全なコードを書くのは難しい
- 自分の仕事（家庭用ゲーム機のプログラム）では致命的なエラーはほとんど起きない
よくわかってないので、必ずしも正しいわけではないと思います。鵜呑みにしないでくださいね。
詳しい話はまた今度。
投稿者 sike : 01:29 | コメント (2) | トラックバック
2006年05月01日
Google Maps API が楽しそう
Google Mapが面白いんで、Ajax にちょっと興味が出てきました。Google Map のサービス開始やWeb2.0ブームからだいぶ時間がたっているし、興味持つの遅すぎですよね。
でも、JavaScript だの DHTML だの、なんか面倒くさいでしょ？ブラウザによって異なる挙動を気にしながらプログラミングするなんてやってられないですよ。
そんな理由で、今まであんまりやる気が起きなかったのですけど、はてなマップとかDAILY ARCHIVEとか見てたら、なんだかウズウズしてきました。
とりあえず、参考になりそうなサイトのメモ。
Google Maps を使ったプログラムを作るための公式ドキュメント。
自分のサイトで Google Maps を利用するためのアカウントの発行もここでする。
・Web::Blogoscope: Google Maps API解説
Google Maps API の日本語による解説。
・Prototype JavaScript Framework: Class-style OO, Ajax, and more
Ajax 方面でよく使われるライブラリ、prototype.js の公式サイト。
こういうのを利用して、なるべく楽して作ろう。
prototype.js の日本語による解説。
2006年02月11日
物理シミュの実装は難しい
「Springheadのソースを見ながら自分なりの実装ができるくらいには理解できたと思う」とか書きましたが、全然ダメだった…。締め切りまでに出来上がりそうにないので、Featherstone法はあきらめました。
論文が理解できるという段階と、実際に動くものが作れるという段階では、大きな開きがあるということを思い知りました。
物理シミュレーションの実装の困難さの一つの理由に、うまく動かないときに原因を探すのが難しいという事があります。
特に、連結剛体のシミュレーションの場合、複数の物体の相互作用により式が複雑になり、式の構成要素の意味があいまいで、その値を見ても正しいのか間違っているのか判別が難しいです。
また、本来連続的な時間の流れを、飛び飛びの時間の流れで近似しているため、プログラムにバグがなくても、パラメータ次第で不安定な動作になることもあります。
今回の仕事ではまともなデバッガが使えないので、いわゆる printf デバッグになっているのも、より状況を困難にしています。
パラメータを観察しながらステップ実行していけば5分で簡単に見つかるようなバグが、printf を仕込み再コンパイル→実行 を何度も何度も繰り返し、数時間かかってしまいます。
全員に一本くれとは言いませんが、チームに一本くらいデバッガを買っておいて欲しいものです。
今度、別の仕事するときは絶対そう主張しようと固く誓うのでした。
投稿者 sike : 23:47 | コメント (0) | トラックバック
2006年02月06日
256b
うそだー。256bytesでこんなの出来るわけねー。
どういうカラクリ？
ftp://ftp.jp.scene.org/pub/scene/parties/2005/function05/256b/exd-hell.zip
他にもいろいろあるみたい。
投稿者 sike : 02:03 | コメント (0) | トラックバック
2006年02月05日
物理シミュのお勧めテキスト
Brian Mirtich の論文、"Impulse-based Dynamic Simulation of Rigid Body Systems" の４章(Featherstone法の説明の章)のみ読了。確かにこれはわかりやすい。
本質的な部分を正しく理解できたかというと怪しいが、Springheadのソースを見ながら自分なりの実装ができるくらいには理解できたと思う。
それと、基礎に立ち戻って、ジョイントなしの剛体の運動についてもおさらいしてみた。
David Baraffの Siggraph Course Notes (SIGGRAPH'97 course) を読んだのだが、これが素晴らしい。今まで物理シミュレーションの本をいくつか読んで勉強してきたのだけど、それらの本が曖昧にしていたことが丁寧に説明されている。英語なんで読みづらいかもしれないけれど、一通り他の本で勉強した後なら大体何の話をしているかは分かると思うので、おさらい用としてお勧め。
投稿者 sike : 18:18 | コメント (0) | トラックバック
2006年01月30日
物理シミュの道は険しい
仕事がうまく進まない…
物理シミュレーションっぽいコードを書いているのですが、単一の剛体をゴロゴロ転がすのはそれなりに動くのですけど、ラグドール（人形を放り投げたような動き）が全然ダメ。
紆余曲折あって、インチキ手法でやっているのですが、インチキであるがゆえにいろんな所に綻びが出そうな気がする。まともに理論に従って書いたほうが楽に書けたんじゃねーの？
ということで、とりあえずメモ書き的にいろいろリンク張っておく。
（主にジョイントで接続された剛体を動かすための資料。）
日本人が書いている物理シミュレーションライブラリ。コメントも日本語なんで読みやすかもしれないが、やっぱり理論がわからないとコードの意味がわからない。
ジョイントで連結した剛体を動かすアルゴリズムの論文を書いている人。
Springhead ではこの人の手法を使っている。
・Impulse-based Dynamic Simulation of Rigid Body Systems
この論文には Featherstone のアルゴリズムがわかりやすく書かれているらしい。
ちょうど読み始めたところ。
・Practical Physics for Articulated Characters
Sony Computer Entertainment America の人が GDC 2004 で発表した論文だと思う。
ゲーム開発者向けの論文なので役に立ちそうと思ったのだけど、全然意味わからん。擬似コードでアルゴリズムの説明が書いてあるのだけど、これだけじゃ理論を理解できなくてちゃんとしたコードは書けないと思う。（単に英語力の問題だったらカッコわるー）
しかし、物理シミュレーションについていろいろ調べていて思うのは、自分はトレンドに乗るのが遅いなーってこと。検索して出てくる情報はもう数年前のものなんだよね。
今、ゲーム系プログラマーの流行って何なんだろう？
マルチコアのプロセッサによる並列プログラミングとか？
投稿者 sike : 23:56
2006年01月18日
ここに物理あれ！
hirax.net を見てたらこんなもの発見。
何なのか手っ取り早く知りたいなら、このビデオ（WMV 20MB)を見るとよい。英語でしゃべってるけど、英語わからなくても問題なし。
ペンで書いたものが動き出す様は天地創造のようで楽しい。「ここにボールあれ！」「ここに重力あれ！」
驚いたことに、これのソースコードが公開されてるらしい。今ちょうど仕事で剛体シミュレーションっぽいプログラム書いてるので、興味津々です。後で見てみよう。
ちなみに、これはタブレットPC用のソフトだけど、普通のWindows XPでも動くので、ぜひ試してみてください。（詳しくは最初のリンク先で）
似たもので MathPad2 ってのもある。（ビデオ WMV 48MB）これもステキ。
ゲーム開発者がこんなの見たら、絶対 Nintendo DS でこんな感じのゲーム作ること考えそうだなー。
あるいは、もう誰か作ってるかも。あるいは、すでに売られてたりして。
よく知らないけど、キャッチ！タッチ！ヨッシー！ってこれに近いのかな？
投稿者 sike : 03:01
2005年12月30日
次世代機向けのコーディング術
Writing Efficient Game Code for Next-Gen Console Architectures
- キャッシュミスのペナルティが大きいのでデータを小さくする
- 分岐予測ミスのペナルティも大きいので分岐を使わないコードを書く
- コプロセッサのレイテンシーが大きいので複数のデータの演算を連続して行ってスループットを高める
アセンブラによるカリカリチューンの低レベルプログラミングの時代は終わり、高速化はプロセッサやコンパイラの性能にまかせ、高級言語による頑健性や保守性を重視するプログラムの時代になったと思ったら、またハードウェアを意識したプログラムを書かされるのですか？
ゲームプログラミングは他の分野に比べ速度を重視する傾向があるので、ある程度はしょうがないんですけどね。 チューンの必要があるのはボトルネックになっている部分だけだと思うし。いわゆる８０：２０ルールってやつ。
しかし、いくらなんでも、分岐を避けるためにこんな書き方はしたくないなー。
if( ptr != 0 ) ptr->next = prev; // 分岐あり（低速）
*( ptr != 0 ? &ptr->next : &dummy ) = prev; // 分岐なし（高速）BASIC で IF は遅いから論理式を使いなさい、とか言われていた遥か遠い時代を思い出してしまった。
「良いコンパイラなら、if で書くより速いコードを生成する」と言ってるけど、本当に良いコンパイラならどっちで書いても分岐命令を使わないコードを生成してほしい。 こんな単純なコードならそれくらい可能でしょ？
投稿者 sike : 18:04 | コメント (0) | トラックバック
2005年10月28日
ワンダと巨像（ニャンダと俺）
投稿者 sike : 23:14 | コメント (0) | トラックバック
2005年09月16日
TGS2005
ゲームショウに行ってきました。
自分が開発しているタイトルも出展してたのですけど、試遊台のあるところがすごく分かりにくくてびっくり。
今回のイチオシはSCEJのLocoRoco。
かわいい。きもちいい。たのしい。
PSP買っちゃいそう。
こういうシンプルで楽しいゲームを見ると、XBOX360 や PS3 のキレイな映像のゲームって、かけた製造コストにみあう楽しさがないなーって思う。なんか虚しくなる。
そんな意味で任天堂のRevolutionの変なコントローラーにも期待。(動画)
投稿者 sike : 23:02 | コメント (0) | トラックバック
2005年08月30日
台本を半自動生成せよ
開発中のゲームのボイスデータの収録のため、台本を作る作業をしている。
膨大な数のボイス（おそらく万の単位）があり、手作業で台本を作るのは考えられないので、ゲームで使用するシナリオデータから半自動で台本を作る台本コンバーターを作ることになったのだが、問題は台本のファイルフォーマットを何にするか。
満たすべき条件としては、
・縦書きが可能
・画像が使用可能
・台本らしいレイアウトが可能
といったものがある。
以前開発したゲームでは、Wordで作っていたようだが、Wordのデータを出力するプログラムを作るのは難しい。
ファイルフォーマットがオープンではないし、Wordデータ出力ライブラリの類もないようだ。（探し方が足りないだけか？）
Word と VBA で作るという手もあるのだろうけど、VBAでWordをいじった経験はないし、VBAというプログラム言語にもなじみがなく、開発時間がかかりそうだ。だいたい会社で使用している Word は、いまどき普通使ってないだろっていう Word 95。現在の主流は Word 2000 以降だろうから資料が少ない。十年前のソフトって…。
最初は出力の簡易さから、HTMLでの出力を考えた。Windows の Internet Explorer なら、"@MS 明朝" というフォント指定をすれば縦書きにできるし、画像も使用可能。テーブルタグで、台本的レイアウトもできるように見えた。
ところが、印刷しようとすると、ページの区切りが意図どおりにいかない。
A4の用紙サイズに合わせて、CSSによりミリ単位のレイアウトを指定しているつもりなのだが、だんだんずれていく。
そもそも数百ページにわたるHTMLをブラウザで開くのも印刷するのもぞっとする。
というわけで、HTMLは没。
さて、ページを意識したレイアウトが出来てプログラムで出力できるフォーマットというと、思いつくのはPDFくらいだ。
TeX ? そんなのもう忘れたよ。
続く…（かも）
2005年08月07日
影描画方法メモ
ゲームで使われる影の描画方法はいろいろあるのだけど、その名前と処理内容をイマイチ把握しきれていなかった。
同居人が買ってきたグランディア３を見て影の話になったので、良い機会だと思い、改めて調べてまとめてみた。
■プロジェクションシャドウ（投影テクスチャマッピング)
光源方向から影を落とすオブジェクトを描画し影絵の影のようなテクスチャを作る。
影が落とされるオブジェクトに対して、その影テクスチャを光源方向から投影するようにテクスチャマッピングする。
影が落とされるオブジェクトを、落とす影の分だけ描画する必要があるので、複雑な形状のオブジェクトに対して影を落とすのは負荷が高い。
セルフシャドウ表現は不可能。（だと思う）
PS2でも可能でよく使われる。
グランディア３は多分これ。負荷軽減のため、影が落とされるオブジェクトは、実際の描画用のモデルと影投影用の簡易モデルと２種類用意しているようだ。階段状の地形なのに斜面のように影が落ちているところがあった。
■ステンシルシャドウボリューム
影を落とすオブジェクトの光源方向からみた輪郭辺を計算で抽出し、輪郭辺を光源と逆方向に引き伸ばしたポリゴンメッシュをシャドウボリュームと呼ぶ。シャドウボリュームの中は影になる空間である。
Zテストとステンシルバッファを使って影のステンシルを作る。
影が落とされるオブジェクトを描画した後、ZテストON,Zバッファ更新なしでシャドウボリュームの表と裏をステンシルバッファに描画する。表を描画するときにはステンシルに＋１、裏をかくときにはステンシルに－１する。影が落ちるピクセルはZテストにより表しか描画されないので、影になるピクセルはステンシル値が1となる。（この記事に図解がある）
プロジェクションシャドウと異なり複雑な形状のオブジェクトに対しても一定のGPU負荷で影が落とせるが、影を落とすオブジェクトが複雑だと輪郭抽出のCPU負荷が高い。(最近はGPUでも輪郭抽出できるようだ）
セルフシャドウ表現も可能。
PS2には純粋な意味でのステンシルバッファがないが、簡易的にそれっぽいことは可能。
「ジャック×ダグスター」は地面に沢山生えている細かい草のポリゴンにも影が落ちていることから、ステンシルシャドウボリュームを使っているのではないかと思う。
■シャドウマッピング
光源方向から見たシーンを描画して光源方向から見た深度テクスチャを作り、通常カメラからのシーン描画時に「光源方向からのピクセルの深度値（Ａ）」と「そのピクセルに投影される深度テクスチャの深度値（Ｂ）」を比較して、Ａ＞Ｂなら影とみなす。（この文章だけではわからないだろうな…）
セルフシャドウ表現が可能。
普通にやろうとするとピクセルシェーダーが必要（だと思う）なのでPS2では難しい。
が、トリッキーなことをすればPS2でもできるという話もある。
参考
・3Dゲームファンのための「3DMark 05」講座
・DOOM3の影生成について考察する
投稿者 sike : 21:18
前に聞いていたとおりフレームレートが低い。でも、あんまり気にならない。
それも味のような気がしてくる。フレームレートの低さが巨像の重厚感を引き立ててるような感じ？
プレイしてるとき、うちのニャンダ（チビ猫）がまとわり付いてきて、自分が巨像感覚だったよ。