宇宙を僕の手の上に　～gltest開発blog～

大きなサイズのファイルを探すPerlスクリプト

最近動画などを編集していて、 HDD が圧迫されつつあるので、要らない巨大ファイルを発見するためのスクリプトを書いてみた。

ディレクトリツリーを再帰的に辿ってツリー全体のサイズを集計する機能と、ディレクトリツリー内でトップ20までの大きさのファイルをリストアップする機能がある。

動画を編集していると中間ファイルもやたらとデカいので、GB単位で空き容量が消えていく。中間ファイルは最終的には必要ないので消せば良いのだが、消すことを忘れていたり、消していいファイルであるか否かを忘れていたりする。そんな中でディスクを多く消費しているファイルからチェックしていけば作業効率が良いので、こんなものを作ってみたわけである。

コマンドライン上で引数を与えないとカレントディレクトリを、引数を与えるとそのディレクトリをチェックする。深いディレクトリツリーの探索にはそれなりに時間がかかる。また、最後にサイズでソートするので処理中にはアウトプットされず、終了時にまとめてリストが出力される。

例：
perl lif.pl
perl lif.pl C:\some\directory\path

出力例：

Directory list in perl:
       0.434:   perl/sucren.pl
       1.752:   perl/lif.pl
       2.918: d perl/.svn
       5.104: d .

Top 20 largest single files:
       0.002: perl/.svn/format
       0.232: perl/.svn/all-wcprops
       0.434: perl/sucren.pl
       0.434: perl/.svn/text-base/sucren.pl.svn-base
       0.521: perl/.svn/entries
       1.729: perl/.svn/text-base/lif.pl.svn-base

尚、単位はKBである。

Windows では動作したが、他のプラットフォームでどうなるかはテストしていない。
Perl のバージョンは 5 以上。

書きなぐったスクリプトなので実行効率の点ではあまりよくないかもしれない。もし使う上で気に入らないなら、スクリプトなので好きなようにいじっちゃってください。あと、使ったために起こった損害については責任持てませんよ。
続きを読む

定点カメラで微速度撮影のテスト

ブログの趣旨とはかなり離れるが、ふとやってみたくなったので微速度撮影（正確な呼び方はよくわからないけど、英語では time lapse というらしい）してみた。

こういう動画は高価な専門の機材を持っていないとできないものと思っていたが、意外と簡単にできておもしろい。

使ったカメラは安物のwebカメラとコンパクトデジカメの2つだ。

4番目の動画まではwebカメラで撮ったものだが、さすがに画質は良いとはいえない。

5,6番目の動画はデジカメでインターバル撮影して連結したもの。最後の動画はのHD相当(1280x960)のピクセル数だ。残念ながら明瞭に撮れる天候のコンディションではなかったが、コンパクトデジカメでHD動画が撮れる可能性を示した面白い結果だ。

動画は「続きを読む」で。

続きを読む

標高データを2次元スプライン補間

前回で取り上げた地形のハイトマップ（標高データ）は、解像度が約100mで
あり、人間スケールのオブジェクトを置くには少々粗い。そこで、頂点を補完することを考えてみた。

単なる線形補間だと、曲率の高い地点で不自然な「折れ曲がり」が見えてしまうので、スムーズな補間を行いたい。この要求を満足するものに自然スプライン補間があった。

理論的なところは全くフォローできていないが、下のページなどを参考にして２次元スプライン補間を実装することができた。

http://next1.cc.it-hiroshima.ac.jp/MULTIMEDIA/numeanal1/node16.html

これは補間を行いたい区間の両端と、その一つ外側のデータ点のみがあれば補間できるため、動的LODによってポリゴンを削減した部分まで計算に入れる必要が無く、比較的高速にオンメモリで計算できるという利点がある。ただし、地形のような莫大な数の点を補間するとなると計算のオーバーヘッドも無視できなくなってくるので、オフライン計算やキャッシュが有効であろう。

1枚目の画像はSRTM3をデータ源としてレンダリングした富士山頂付近をキャプチャしたものの補間前と後の比較である。画像では補間は16分割して行ったが、理論上はいくつにでも分割できる(厳密に言うと、ピラミッドバッファのサイズから上限が決まってくる)。

なお、実際の富士山頂にも登ってみたが、2枚目の画像のような光景だった。

リアルの地形データからなめらかな地形を描画したいときには、有効な方法ではなかろうか。

続きにスプライン補間のソースを掲示する。

続きを読む

全世界ハイトマップの応用

以前から北米のハイトマップは手にしていた（グランドキャニオン）が、今回はより身近な地形データを使ってみた。

今回のデータソースもやはり NASA のプロジェクトになる。
Visible Earth の BMNG Raw Topography というコンテンツだ。

http://visibleearth.nasa.gov/view_rec.php?id=8391

これは全世界を約500mのメッシュで区切ったラスタデータで、 86400ｘ43200 の解像度を持つ。ダウンロードしたZipファイルを展開すると 7GB にもなる膨大なデータだ。標高データはメートル単位で記録されている。

これさえあれば、地球上のどの点でもそこそこの正確さで再現できるが、あまりにも重いのでメインメモリに乗りきらないのが難点である。
少し気になるのは、ビッグエンディアンと説明には書いてあるのだが、実際にはリトルエンディアンであることだ。 Intel で読み込もうと思ったらバイトオーダーの変更が必要になる。

このデータは SRTM30 と RAMP2 という二つのサーベイの結果を合成したものらしい。それぞれ赤道周りと極地方を計測したものだ。どちらもレーダー衛星であるが、これだけの分解能をもつレーダー測地はなかなかすごい技術だと思う。

１枚目の画像はこの膨大なファイルをピクセル間引きして表示しているところ。

2枚目の画像は富士山付近を切り取って表示したものである。

他に日本の標高データソースとしては国土地理院の電子地図があるが、CD媒体で7500円もする。

http://www.jmc.or.jp/data/gsi.html

これに対し、以下のようなオープンな利用規約でデータを提供してくれるところは、さすが NASA といったところか。

NASA Terms of Use

For all non-private uses, NASA's Terms Of Use are as follows:
The imagery is free of licensing fees
NASA requires that they be provided a credit as the owners of the imagery

Visible Earth Addendum

Beyond the NASA Terms, the Visible Earth team requests, but does not require:
The Visible Earth be provided a credit as the location that the imagery was found at
A URL be provided, either to the Visible Earth (http://visibleearth.nasa.gov/) or to the page providing the link to the used image.

Windows+OpenGLで日本語を表示する方法

今まで特に不便を感じていなかったのでトライしていなかったが、 OpenGL を扱う上で大きなハードルになっている多バイト文字の描画について、今回は実験の結果をまとめる。（尚、 DirectX の言語対応についてはよく知らないが、世の中には右手系の座標空間で日本語を使いたい人もいるはずだ！）

長いので全文は「続きを読む」で。
続きを読む

ビリヤードゲーム作ってみた

更新がご無沙汰になっているが、blog管理人がついに就職したのが原因だ。

社会人になると、時間や自由のように失うものもあるが、得るものもある。給料が出ると色々とツールを買うことができる。その一つが初任給で買ったデジカメだ。

買ったのはリコーのCX1というデジカメだが、こいつの機能に傾き補正というやつがあって、斜めから撮った平面を補正して垂直方向から見たかのように画像変換することができる。テクスチャ素材を
集めるにはうってつけだ。

それとは別に、ビリヤードの物理をやってみたくなったので作ってみた。素材は早速デジカメで撮ったものを使っている。

ビリヤードボールの形状は剛体シミュレーションには非常に適したものであるが、接触時の挙動はそれほど簡単ではない。ボール同士にも、ボールと台との間にも、クッションに対しても摩擦があり、単純な完全弾性衝突とはみなせない。そうでなければボールは全く回転しないのであるから、あたりまえといえばあたりまえだ。
実際のビリヤード台は湿度で挙動が変わったりもするという。現実味のある挙動をとらせるには、パラメータ調整に時間をかける必要があるだろう。

ビリヤード台のモデリングは意外と面倒なので、今は平面的になっている。

3枚目の画像は素材に使った簡易ビリヤード台の写真である。

RTS化計画

そろそろ基本機能も固まってきたので、ゲームとしての方向性を決めたいと思う。

地上の現象のシミュレーションは完成度を上げるのが難しいので、ひとまずジャンルを宇宙系リアルタイムストラテジーとする。

フル 3D 宇宙系 RTS といえばなんといっても Homeworld シリーズが元祖には違いないが、最近で言うと Sins of a Solar Empire というタイトルにシステムは近いものになると思う。

本ゲームがユニークであると思われる点は、スケールに関するリアリティになる。前に述べた2タイトルは宇宙を題材にしてはいるが、距離感よりもゲーム性に重きを置いていて、宇宙の広大さに関してリアリティを追究しているわけではない。これに対し、本作では天体運動の実時間シミュレーションを行いながらゲームする。モデルは現実の太陽系で、実際の天体の運動を参考にしている。

さまざまな天体を巡る軌道上で自軍のユニットを操作し、太陽系内をワープしながら資源を探し、敵を殲滅するといったゲームになる。

前にネットゲーム化計画に関して書いたが、いまのところネットゲーム化するには難しすぎる点が多いため、とりあえずシングルプレイヤーゲームとしてリリースしてから、ソースを C 言語から C++ に移行してネットワーク対戦に取り掛かるつもりだ。

NLIPS

NLIPS(Non-Linear Inverse Perspective Scaling) とは、 Homeworld というゲームのシリーズで、カメラをズームアウトしたときに小さな宇宙船が見えなくなってしまうのを防ぐため、描画時の大きさを変えるというテクニックである。

モニタの解像度は高が1000ピクセル程度と知れているので、あまり小さなものは1ピクセルにも満たず、見つけることができなくなってしまうので、宇宙を舞台とするような広大なスケールダイナミックレンジを持つゲームでは必要になることが多いと思う。

近くに見えているときに拡大してしまっては、元から大きい船にしか見えなくなるため、カメラから遠ざかったときに効果を強くするような式が必要になる。 gltest では下のような式を使ってスケールを決定してみた。

scale *= 1. + fov * g_nlips_factor * VECDIST(pos, view);

ここで、 fov は視野角(Field of View)のコサイン値であり、 g_nlips_factor は効果の強さを調整するコンソール変数、 VECDIST(pos, view) は視点と描画対称の位置の直線距離を計算する関数となっている。

銃火器のリコイル（反動）のシミュレーション

人体モデルに銃火器を持たせる上で、リアル系FPSばりにリコイルを表現してみたくなった。

ランダムで照準をずらして、連射時に目標を狙いつづけるのが難しくなるようにしてみた。

話の上で、照準のずれ量 a （角度）とその変化速度 ω （角度/秒）を定義する。ピッチとヨーの2軸についてこの値が2次元平面を張ると考えることができる。

基本的には、射撃によって ω が瞬間的に変化するようにし、 a がゼロに近づいていくように制御すればよいのだが、ここで問題になるのは、 gltest のようにシミュレーションステップの時間幅が可変の場合、差分法による求解では、描画時のフレームレートによって挙動が異なってしまうことである。悪い場合には発振や発散にも至る。

そこで、一次のフィードバック系の解析解である指数関数を使って、フレームレートに関わらずリコイルの挙動が決まるようにした。

ソースや動画は「続きを読む」で。

続きを読む

人体モデルとその応用（歩兵）

前回に引き続き、今回もblog休止期間の開発状況についてである。

人体モデルの導入にはずいぶんと苦労した。統合されたモーションエディタとモデリングツールが手元になかったため、前の動画でVF-25のモーションを作るときに使った自作のモーションエディタを流用した。他にもテクスチャが貼れないとか、スキニングができてないとか、色々と問題があった。

とりあえず人の形に見えるようにはなったので、何種類か武器を持たせてみた。一人称視点で操作することもできる。

スクリーンショットでもわかるように、あからさまなローポリゴンモデルだが、多量に表示することになるので細部を作りこむ予定はない。

スキニングに関してはいまだにできていないのだが、この様子だと必要ないのかもしれない。

宇宙を僕の手の上に ～gltest開発blog～