月別アーカイブ: 2006年10月

Nike + iPod 買いました

28日に発売された Nike + iPod 買いました。
http://www.apple.com/jp/ipod/nike/

靴にセンサーをつけておくだけで、走行距離や速度、消費カロリーが iPod nano
に表示されます。

一見音楽プレイヤーとはあんまり関連性が無いように見えるけど、音声で現在の
状況などを報告してくれるのです。いちいち画面を見なくても大丈夫。

まだ試しに少し歩いた程度ですが、何も設定していないのに距離や速度の表示が
結構正確に出ます。キャリブレーションもできるけど、他の万歩計等と違って
わざわざ歩幅を はかって入れなくてもいい。
ずっとこの点だけが面倒だと思っていたのですよ>万歩計の歩幅設定

で、これ走行状況が逐一 iPod に記録されておりロガーとしても機能します。
iTunes 経由で Nike+ のサイトに情報が送られて、時間軸とともにグラフ表示
できたり、他のランナーの状況と比較できたりするから結構楽しい。
これを見るためにもう少し走ってみよう、という気になります。

まだ登録数も少ないので、数キロ程度の距離でも日本ランク 700位程度。
走らなくても大丈夫。まだまだウォーキングでもいいポジション狙えます。

足につける無線のセンサーといえばポラールを思い出すわけですが、Nike + iPod
はここまで本格的ではありません。
http://www.polar.jp/html/segments/Running.html

もっと気楽にはじめられて、ネットに登録するのが楽しみで、はまりそうな予感。

だけどやりこんだら心拍計もほしくなるだろうなあ・・というわけで
ハートレートモニタつきの上位機種が出てほしいです。

または、ポラールやガーミンあたりも対抗してオンラインサービスはじめてくれると
面白いんだけど。ネットワーク対応のサイクルコンピュータなんてのも出てほしい
ですね。

Direct3D のボトルネック

コンシューマ系の組み込みハードと PC の Direct3D では、気をつけなければいけ
ない点が異なっています。思わぬボトルネックが発生します。

とあるメーカーが開発した PC 向けのタイトルのサンプルで、非常に動作が重い
ものがありました。しかもモデルデータのせいで処理が重いので、データを軽く
して欲しいとの話でした。またデータのせいで使えるビデオカードにも制約が
出てしまうとの指摘でした。

画面は 3D のフィールドを表示するシンプルな画面で、背景もキャラクタもごく
普通のモデルデータです。

ところが非常に要求スペックが高く、ためしに起動した PC では 1fps も出てい
ない状況でした。

大体予想がつきましたが、おそらく GPU ではなく CPU の方で処理が落ちている
のでしょう。見たところデータフォルダ内には細切れになったテクスチャが大量
に入っていました。

PC の場合、Direct3D の描画 API の呼び出し回数によって速度が大幅に変わります。
そのためエンジン設計の第一歩は Draw の回数を減らすことからです。

描画はできるだけまとめてばらばらのオブジェクトも一回で描画できるようにします。
Draw 呼び出しの内部ではマテリアルやレンダーステートを切り替えられないので、
マテリアルの数がそのまま描画回数の増加につながります。

テクスチャはできるだけシートにまとめ、マテリアルパラメータは可能ならば頂点
に埋め込みます。

マテリアルやシェーダーの切り替えも負荷になるので、切り替えを最小限にするため
には描画の前にソートしておく必要があります。

また ShaderModel3.0 や、ATI RADEON の ShaderModel2.0 では、ジオメトリ
インスタンシングを使うことができます。頂点ストリームにジオメトリやマテリアル
を書き込んでおくことで、一度の描画呼び出しで大量のオブジェクトを描画可能です。

つまり、描画時には必ずこのような描画を減らす工夫が必要だということです。
そうでないと描画呼び出し API の実行だけで CPU サイクルを消費してしまいます。

コンシューマ系の組み込みハードウエアでは、描画 API の Call はそれほど負荷に
ならず、テクスチャの変更もほとんどサイクル数を消費しないものがあります。
そのためつい同じような考えで描画パイプラインを設計してしまうと思わぬ
ボトルネックに苦しむことになります。

WindowsVista + Direct3D10 では、ステート等のバッファを VRAM 上に確保できる
など、より負荷を軽くするためのさまざまな工夫が施されているようです。

Draw 呼び出し回数の次に考えられる CPU のボトルネックはバッファの lock です。
例えばキャラクタのスキニング等で頂点バッファを lock して書き換えると、GPU
との同期待ちで CPU が無駄に待っている可能性があります。

シェーダーで演算すれば解決なのですが、どうしても CPU で書き込みを行う場合は
フレームバッファと同じように頂点バッファを複数持つ必要があります。頂点バッ
ファを POOL 化して、書き換えた頂点を発行するたびに使用するバッファを切り
替えていきます。

このあたりのボトルネックは、今では PIX 等の解析ツールを見れば一目瞭然で
しょう。

WZ Mobile 用の Emacs もどき定義ファイル更新

新たに複数の文書(TAB)間移動を割り当ててみました。

外付け USB キーボード向けの定義なので、内蔵の QWERTY キーボードでは入力
できないコマンドがあります。エディタのみ考慮しているので、メール等他の機能
では操作しづらくなる可能性があります。

・「ESC + 文字」系の操作は IME を off にしておかないと使えないので注意です。
・「C-X + 文字」系の操作は「Ctrl-X F」「Ctrl-X Ctrl-F」どちらでも構いません。
・「ESC + 記号」は残念ながら定義できないようです。

C-A  LTOP 行頭
C-B  LEFT カーソル左移動
C-D  DELEET 1文字削除
C-E  LEND 行末
C-F  RIGHT カーソル右移動
C-G  UPPG ページアップ
C-H  BS BackSpace
C-I  TAB TAB
C-J  ENTER ENTER
C-K  DEREAR 行末まで削除
C-M  ENTER ENTER
C-N  DOWN カーソル下移動
C-P  UP カーソル上移動
C-Q  CTRL 制御コード挿入
C-R  REDO Undoの取り消し
C-S  SEARCH 検索
C-U  UNDO Undo
C-V  DOWNPG ページダウン
C-W  CUT 選択範囲切り取り
C-Y  PASTE 貼り付け
C-\  IMESW 漢字変換ON/OFF
C-SPACE  SEL 範囲選択開始

C-X C  MDICLS 現在の文書を閉じる
C-X F  OPEN 新規ファイル読み込み
C-X N  WINNXT 次のタブに切り替え
C-X P  WINPRE 前のタブに切り替え
C-X S  SAVE 保存
C-X U  UNDO Undo
C-X W  COPY 選択範囲コピー

ESC N  END ファイルの終端へ移動
ESC P  TOP ファイルの先頭へ移動
ESC V  UPPG ページアップ

以下の内容を win.key ファイルに上書きすると有効になります。

WZ モバイル β2

ダイアログやメニューなど、前回かなり遅かった部分が早くなりました。
メニュー操作も [←] でキャンセルできるなど自然な感じで操作できる
ようになっています。

ダイアログを閉じるときも、右下に「×」が表示されていてソフトキー2で
閉じるんだとはっきりわかるようになっています。

修正のペースからもいかにも最後の追い込みといった感じです。

USBの外付けキーボードで、メモや議事録のテキスト入力用として使っている
自分にはもう十分な感じです。こんな特殊な用途ですが PWZ3 + patch から
改善されるのは以下の点でしょうか。

・改行、TAB、全角空白などのマーク表示が VGA 画面に合わせたハイレゾになる
・メニューやメニューバーのフォントも VGA サイズで小さく細くできる
・メニューなどの操作が片手だけでできるようになる

これ以外は PWZ3 で満足していたので・・全然使いこなしてないですね

Direct3D の Shader と HDR のさわり

DirectX は当初ものすごい勢いでバージョン番号が更新されていきました。
途中 X4 が抜けているものの、DirectX2~7 までがわずか 4年。
ところが Shader が登場した DirectX8 以降はそのペースが落ちます。

特に DirectX9 は 2002年に登場してから 4年間も使われていることになります。

以前はリアルタイム3Dのテクノロジの更新が API に直結しており、ハードウエアの
進化や新機能の追加は Direct3D API の刷新が必要でした。

ところが今では D3D API ではなく、シェーダー機能の拡張そのものにハードのパワー
が注がれるようになっています。

「シェーダーが必要なわけ」
でも書いたように、もはや 3D アルゴリズムの進化とハードウエアの拡張は別物です。

ソフトウエア技術者はシェーダーという自由の中で、アクセラレータの恩恵を受け
つつさまざまなアルゴリズムを開拓することができます。

そしてハードウエアメーカーは GPU の汎用的なシェーダーパワーの拡充に専念する
ことができるわけです。

もうすぐ Direct3D10 とともに ShaderModel4.0 が登場します。

ハードウエアの都合に強く依存していたシェーダーの仕様は、徐々にその影響力を
弱めています。ますます汎用的になっています。

レンダリングのアルゴリズムは、ハードウエアロジックではなくプログラマに委ねら
れているわけです。さらに近い将来、プログラマではなくグラフィックデザイナー
範疇に含まれるようになるかもしれません。

一般的に画像データは RGB の各色を 0~255 の 256段階で持ちます。RGBがそれぞれ
256段階なので、256×256×256 = 16777216 のおよそ 1677万色の表現が可能です。
これを 24bit カラーといったりフルカラー画像と呼ぶことがありました。

フレームバッファも最終的には 24bit カラーなので、リアルタイムレンダリングの
ピクセルカラー演算も 0~255 の 8bit 整数が使われていました。

ShaderModel2.0 以降、PixelShader 内部は 24~32bit の浮動少数点演算に拡張され
ています。モニタへの出力は 1677万色なので、色数を見たらフルカラーを超えて
おりオーバースペックです。

PixelShader の演算はベクトルや座標値など、もはやカラーの値だけでは済まない
からです。

またカラー値そのものも HDR で持つことが多くなりました。演算中は自然界の数値
を模した高いダイナミックレンジを保っておき、最終的にモニタに出力する直前に
人間の可視範囲で切り取るわけです。

3D のワールドマップ上でキャラクタやオブジェクトを動かしておき、任意のカメラ
で見える範囲をレンダリングするのに似ています。

自然界の微弱なものから強烈な光まで、幅広い光の中から任意のカメラで好きな
部分を「可視可能な領域」としてレンダリングできるようになります。