進捗日誌

おひさしぶりです！
今日は今の会社の忘年会で、ビンゴ大会があって僕は景品としてPSVitaを供出したのですが、僕が出したVitaはこの人に当たりました…



…もうVita自分で買ってるじゃん！

まあありがちなネタですけど…

単位軸(X,Y,Z)周りに角度Aの回転を表すクオータニオン(Qx,Qy,Qz,Qw)はB=A/2として(XsinB,YsinB.ZsinB,cosB)となります。

C=B/2として、まずW成分から求めます。これは半角公式からcosC = sqrt( (1+cosB) / 2 ) = sqrt( (1+Qw) / 2 )とあっさり求めることができます。

次にXYZ成分ですが、sinBやsinCを計算する必要はありません。実際に必要なのはXYZ成分をスケールするための係数r=sinC/sinBなのですが、これは半角公式sinC*cosC = sinB/2からr = sinC/sinB = 1 / (2 * cosC)となりcosCから直接求められるからです。

さらに通常は平方根より平方根の逆数を求める方が高速なので、cosCを先に求めるよりrを先に一気に求めてそこからcosCを計算する方が高速になります。この場合、r = sinC/sinB = 1 / (2 * cosC) = rsqrt( 2 * (1 + Qw) )を求めてからcosC = 0.5/r を求める形になります。

注意しなければいけないのは、Qwが-1に近い場合、つまり回転角Aが±360°に近い時に精度がガタ落ちすることです。そういう回転角が来ないと分かっている場合は上記の方法でかなり高速に求められると思います。

先週は以前の会社で同僚だったデザイナさんがアメリカに転職するということで、大阪で開かれた送別会に参加してきました！が、他にも色々用事を入れたので相当な強行軍に…

9/18
18:00〜20:00 横浜でガンバ戦観戦
20:30〜23:00 新幹線で大阪に移動
23:30〜25:30 梅田で焼肉@情熱ホルモン

9/19
02:00〜06:00 梅田でカラオケ
06:15〜06:45 梅田でサウナ@大東洋
07:00〜12:00 梅田の漫喫で仮眠
12:30〜12:50 梅田でカレー＠インディアンカレー
13:00〜14:00 阪神電車で神戸に移動
14:00〜21:00 神戸で送別会
21:30〜23:30 神戸でカラオケ
23:30〜25:00 車で梅田に移動

9/20
02:00〜05:30 梅田でカラオケ
06:00〜08:30 新幹線で東京に移動
09:15〜09:45 会社でシャワー
10:00〜20:00 仕事

時間は適当です。いやー懐かしい方々に会えて凄く楽しかったのですが、さすがに疲れましたね…一つだけ心残りなのは阪神梅田駅でミックスジュースを飲むのを忘れたことですが、まあ次の機会ということで。

僕が以前やった仕事では、プランナーが仕様を管理するためのExcelファイルにVBAを仕込んでそこからXMLを出力→バイナリ変換をしていました。これだと仕様と実データがズレないし余計な仕事も発生しないのでお勧めです。プランナがマクロボタンを押し忘れたりサブミットし忘れたりしなければですけど。

あとやったことないですが、VBAで実機と通信してExcelをフロントエンドとして使えたりしないかなと。入力支援機能は腐るほど付いてるし、アーティストがいくらでもカスタマイズ可能だし、シリアライズはセーブロードするだけ。シートは実機側のコアのコードだけ上手く作れば、特に苦労せず用意することが出来ると思います。

僕の経験上、物事を理解するにはそれに関する全ての情報が頭の中に入っていることが大事で、全ての情報を頭の中に入れるにはそれらが同時に視界に入る状況を作ることが大事、だと考えています。

なので僕は大規模なソースを解析するときは、色々な情報が同時に目に入るようにExcelを使って似非のクラス図や関数のコールツリーを書いたり、時には色んなケースのコールスタックをデバッガからコピペして並べたりしています。こういうのを作っておくと漫然とソースを読んだりデバッガで追いかけたりするより理解がずっと早くなります。

ソース解析でお困りの方はぜひ試してみてください。

CEDECのレポートに関しては特に何も言ってなかったんですけど、とりあえず強制では無いものの、業務時間外に書いて提出してもらうことにしました。僕の独断で。

諸事情で行ける人数が限られているので、今後はみんなにフィードバック出来る人から優先してそういうセミナーに割り振って行きたいと考えています。GDCとかもね。まあGDCは英語出来る人が優先ですけど…

なので無理に書かなくてもいいのです。

すごくどうでもいいことなんですけど、僕はクラスのメンバ変数でboolとかの「〜かどうか」っていう変数の名前の先頭に(m_)Isって付けるのが多くて、さらにその変数のアクセス関数にGet/Setを付けることが多いので、

bool GetIsHoge() const;
void SetIsHoge(bool hoge);

とかになるんですけど、M下君に「これはおかしくないですか？」と言われて止めました…

慣れると統一感があっていいと思うんですけどね…

今年は自分の会社からの参加じゃないし、他のスタッフにできるだけ譲って最悪行けなくてもいいかなと思っていたのですが、蓋を開けてみると全コマ参加することになりました…ふしぎ！

調整の結果、僕の予定はこんな感じになりました。

9/6

２体から４体！？ 〜鉄拳タッグトーナメント２における描画システムと負荷削減について〜

Mathematics for the Game Industry: ゲーム・仮想現実における物理モデルシミュレーションと数値解析

データに学ぶプロシージャルアニメーション　〜データ駆動型技術の実用化に向けた試み〜

ユークスにおける物理シミュレーションとアニメーションの融合における取り組み

テクニカルアーティストラウンドテーブル2011： プログラマー編

9/7

ショートセッション： リアルタイムCG技術の先端

物理エンジンを利用したクリーチャーのプロシージャルアニメーション

フルボディIKエンジンの作り方

Augumented Reality

9/8

"情報処理学会グラフィクスとCAD研究会・発足３０周年記念〜 CGリサーチフォーラム: 『計算錯覚学』への招待"

ゲームにおける破壊

超シンプル物理！〜「ドラゴンズ　ドグマ」での衣服／髪シミュの秘密＋剛体／ラグドールへの拡張〜

NVIDIA PhysX バージョン３とAPEXのご紹介

DirectX最新グラフィックス技法のご紹介

1．OS依存の型をそのまま出力しない

例えばsize_tなどは32bitと64bitで値が違うことがあります。そういう型をそのままバイナリ出力するのは止めましょう。その代わりにuint32_tやuint64_tなどを使いましょう。

２．実行時アドレスをそのまま格納しない

当たり前のことですが、バイナリ出力時のアドレスと読み込み時のアドレスは異なります。読み込んだ後にアドレスを変換すれば使えないことはないですが、ファイルを出力する度にイメージが変化する可能性があり、バージョン管理に支障をきたします。素直にオフセットを使いましょう。

３．パディングされていない構造体をそのまま出力しない

構造体メンバ変数の合計サイズと構造体のサイズは異なる事があります。そのさい構造体の末尾のメモリは通常初期化されず不定なので、そのままバイナリ出力すると出力する度にイメージが変化する可能性があり、バージョン管理に支障をきたします。コンストラクタで常にクリアするか、パディング用のメンバ変数を追加して明示的に値を代入しましょう。

４．初期化されていないメンバをそのまま出力しない

構造体にメンバとして定義されているものの常に初期化されないメンバ変数が存在する事があります。例えば16byteアライメントされている３要素ベクトルのw要素などです。こういう要素をそのままバイナリ出力すると出力する際にイメージが変化する可能性があり、バージョン管理に支障をきたします。こういう場合は最後の要素の代わりに固定値を出力する関数を作りましょう。


以上は新人研修でやるような内容ですが、結構なお値段の有償ミドルウェアのコンバータに上記の４つ全てが含まれていたので書いてみました。ちなみにソースが公開されていたので自分で修正しようかと思ったのですが、修正箇所があまりに多いので断念しました…

あまりにガンバの試合で点が入るのでグラフにしてみました。

うける

みなさまおひさしぶりです。TwitterでIKの話を出したのでそのネタでブログを更新してみます。

僕が初めてIKで足接地の処理を書いたのはもう10年以上前のことで、いやー大変でしたね。周りに経験者はいないし、続編でモーションは１作目の使い回しだったので足接地のことは何も考えてないし（構えが超低くて足を大きく開くとか）、背景デザイナは仕様で決めた傾斜の上限を守らないし…

難しいのは谷側の足がどうしても浮いてしまうんですよね。逆に山側の足は違和感が出にくいです。で色々模索した結果、傾斜の大きさに合わせて�@腰の高さを下げて、�A足幅を狭くすることによって谷側の足を浮きにくくすることにしました。傾斜の大きさはコリジョンの法線から直接取るとエッジで急に変化するので工夫がいりますけど。

こう書くとすごい簡単ですけど、足幅を狭くするって考えはなかなか出てこなかったんですよね（汗）。他にも色々やったんですけど、あそこまで極端なモーションじゃなければ必要ないんじゃないかと思います。

僕が今まで犯した最大のバグは一年目の新人の時でした。

僕の作った処理を何回か通るとそれ以降ずっと２Dキャラクタのパターンが崩れるというもので、一旦それが起こると何と電源を切ってもそれが続くのです！セーブも何もしてないのに。

何が起きたか想像できますか？

その時は結構大きい構造体の配列を使っていて、それに対する無効なインデクスとして0xFFFFを使っていたんですけど、僕がノーチェックで０ｘFFFFで配列にアクセスすることによってマップされたRAMの領域を飛び出してROM領域に書き込みに行っていたんです！

ですが普通はそんなことをすれば例外で止まるはずなんですけど、その開発環境ではそうではなく、さらに開発機でフラッシュROMを焼ける機能が付いていたためにそのままROMにその値を書きこめてしまったのです！

いやあれは本当に焦りました…今思うとよく上の人が許してくれたなと思います。

を引っ張り出して読んでいます。LCP（linear complementarity problem：線形相補性問題）のLemke法の説明が具体例を挙げながら説明されていて分かりやすい。LCPも色々派生形があったりするのでちゃんと勉強するにはガッツリ専門書を読まなきゃ駄目なんでしょうけど。何かいい本あったら教えてください！

Game Physics, Second Edition
Morgan Kaufmann
David H. Eberly


Amazonアソシエイト by

http://www.gamba-osaka.net/news/news_detail.php?id=2949

ううう行きたいけど、次の週に万博で同じカードがあるんですよね…中止にならなかったらですけど。そっちに行きたいと思っているので、今回は見送って個人で募金しようと思います。

関西在住の方、僕の代わりに行ってきてください！

母親が紛失したソフトバンクの携帯が見つかったので、停止手続きを解除したいのだがサポートセンターに全く繋がらない。２４時間受け付けというが２４時間繋がらない。しかも解除は９時から２０時しか受け付けない。そもそも他のキャリアはパソコンから手続き出来るのにソフトバンクは電話でしか受け付けない。しかもそれが繋がらない。その間も基本料金はおいしく頂きます。この間の地震の時もソフトバンクユーザーだけ電話も掛かりにくいしメールも時間がかかっていた。ソフトバンクは駄目だ。

情報を遮断してＢＳ朝日で観戦していたんですけど、負けてしまいましたね…

天津は守備が整備されていてガンバ対策がちゃんと出来ていた感じでしたね。奪われた後の守備への切り替えやバランスの良さとかは天津の方が一枚上手でした。

攻撃に関しては前線のアルゼンチン人ＦＷがキープ力があって、右サイド？の中国人のドリブルがちょっと怖い程度でそんなに迫力はなかったのですが、一点目はＧＫ藤ヶ谷の、二点目はＤＦ高木のイージーミスで点を取られてしまいました。

先に点を取られしなければ引き分けを念頭において精神的に有利に運べたと思うのですが、一試合に二回もあんな点の取られ方をしたら流石に厳しいと思います。

ガンバは全体的にコンディションが悪かったと思うのですが、途中で入った高木と佐々木は今シーズン初試合で、はっきり言ってボロボロでした…まあしばらく中断するので、頑張って調子を上げていって欲しいと思います。

しかし中国の観客のマナーは相変わらずですね…物は投げるし選手にレーザー光線向けるし。試合前の黙祷だけはちゃんとやっていたみたいですけど。

東京は揺れの激しさはそこまででもなく、モノも殆ど落ちませんでした。震度４の地震を何回か体験していますが、その時の方が落ちていました。

ただ振幅が大きくて時間が長く、揺れが大きくなったり小さくなったりを何回も繰り返したので、いつ収まるかが全く分からないのが怖かったです。

報道の通り、揺れそのものによる被害は殆どなかったのですが、電車が全て止まって帰れなくなる人が大量に出ました。ただ、浦安とかでは液状化現象が起きてライフラインが止まったり、車が立ち往生したりしている様です。

あと、携帯の電話やメールは殆ど機能していませんでしたが、ツイッターは殆ど影響を受けていませんでした。

今は実家にいます

行列をメモリに格納する場合、２通りの方法があります。ゲームでよく使うＲＴ行列に関して、２次元で右手系の3x3行列の場合を考えます。

このとき反時計回りにθ回転、平行移動量が（Ｘ、Ｙ）とすると、この行列は一般的にRow-majorと呼ばれている方式では、メモリに次の順番に格納されます。

(cosθ, -sinθ, Ｘ, sinθ, cosθ, Y, 0, 0, 1)

一方、一般的にColumn-majorと呼ばれている方式では次の順番になります。

(cosθ, sinθ, 0, -sinθ, cosθ, 0, X, Y, 1)

ただし僕はこの呼び方があまり好きではありません。なぜかというと、行列の要素を表記上どう並べるかは縦と横が逆の２通りのやり方があって、特に「子行列×親行列」や「ベクトル×行列」の順番を採用している場合はどちらも使われるケースがあります。で、この順番を採用しているDirectXがこの呼び方を使用していることが更に直感的に話を分かりにくくします。

そこで僕は最近よく使われるＡoS(Array of Structure)とSoA(Structure of Array)という呼び方をお勧めします。ＡｏＳ=Column-majorでSoA=Row-majorです。僕の覚え方としては、Column-majorの（X,Y,1）がstructureでそれがarrayの一部になっているからＡｏＳ、ＳｏＡはその逆です（汗）…詳しい説明は他に良いページがあると思うので調べてみてください。

今日の英語教室の後にそんな話が出たのですが、僕としてはやっぱり餓狼伝説かなと。ステージ曲でいうとテリーとかビリーとかクラウザーとか凄く特徴的で大好きです。

でもタイトルデモでいうと断然KOF98ですけどね！

http://www.youtube.com/watch?v=gUbo9pnUf5s

バンバンバンババーン！燃えるッ！！