進捗日誌

昨日の記事http://forte.at.webry.info/201205/article_2.htmlの続きです。

実は間違いがあって、子の移動量は親のスケールの影響を受ける必要があります。その移動量をt_s = Ps * t とすると子のワールドマトリクスは以下のようになります。

Cw = Pt*Pr*Ct_s*Cr*Cs = Pt*Pr*(Ps*Ps^-1)*Ct_s*Cr*Cs = Pw*Ps^-1*Ct_s*Cr*Cs

ここでマトリクスの性質上、 Ps^-1*Ct_s = Ct*Ps^-1なので、求めるべき新しいローカルマトリクスは以下のようになります。

Cl = Ps^-1*Ct_s*Cr*Cs = Ct*Ps^-1*Cr*Cs

これだと親のスケールの逆行列が間に入ってきてしまいますが、「左側からスケールマトリクスを掛けるんだけど移動量には掛けない」ような関数を作れば昨日の記事と同じ様な考え方でいけます。

ここまで書いといてあれですが、Ｔ中さんにＭａｙａのＡＰＩドキュメントを教えていただきました。ここに式が載っています。
http://docs.autodesk.com/MAYAUL/2013/ENU/Maya-API-Documentation/index.html?url=cpp_ref/class_m_fn_ik_joint.html,topicNumber=cpp_ref_class_m_fn_ik_joint_html

で、ここからは今の仕事に固有な話なのですが、そもそも今使っているモーションエンジンにはスケールアニメーションの機能が無くて僕がカスタマイズして入れているので、エクスポート時に子の移動量が親のスケールに影響されて移動量アニメーションとして吐き出されているんですね。なので今の仕事の場合は昨日の記事の式じゃないと逆に上手くいかない、ということになっています…

に対応しました（今更）。要するに親関節のスケールを子関節に引き継がせないようなスケーリングです。腕が伸びるみたいな。実装は至極簡単なのでちょっと書いてみます。

マトリクスを親*子の順番で書くとすると関節のローカルマトリクスはMl = Mt*Mr*Msとなります。

セグメントスケールが入っている場合、親のマトリクスをP、子のマトリクスをCで表すとすると、親と子のワールドマトリクスは以下のようになります。

Pw = Pt*Pr*Ps
Cw = Pt*Pr*Ct*Cr*Cs = Pt*Pr*Cl

大抵の場合、子供のワールドマトリクスCwは親のワールドマトリクスPwから求めたいので、Pwを含めた形にCwを書きかえると以下のようになります。

Cw = Pt*Pr*(Ps*Ps^-1)*Cl = Pw * Ps^-1*Cl

ここでPs^-1*Clを新しい子のローカルマトリクスだと定義すれば、上の式は通常のワールドマトリクスの求め方と同じになります。言いかえると、通常のローカルマトリクスClを求めた後、（普通にスケールを掛けるのとは）逆側から親のスケールマトリクスの逆行列 Ps^-1を掛けて新しいローカルマトリクスを作ればいいわけです。当然ですが、スケールマトリクスの逆行列は超簡単に求められます。

小難しく書いてしまいましたが、要するに親のスケール成分をキャンセルするように親側にマイナススケールを突っ込めばいいよね！という話です。

このやり方の場合に気を付けなければいけないのは、スケールに０が入ってくると破綻することです。なので今回はスケールの最小値を定義してそれを下回らないようにしてみました。

※追記
ここまで書いて考え直してみたら、何か間違っているような気がしてきました（汗）。正しくはCt*Ps^-1*Cr*Csな気が…明日テストデータを作ってもらって確認します…

※更に追記
続きを追加しました。
http://forte.at.webry.info/201205/article_3.html

を見てきました！

うーん正直微妙でしたね…質感も何かいまいちだし、何よりガウォーク形態の肩から前の部分しかないので大きさに圧倒されたりということもありませんでした。まあ毎日実物大のガンダムを見ているので、それと比べちゃうとどうしても。

でも今後は大阪でもやるみたいで、そのときは足部分も含めた全体像になるらしく、もしそうなら遊びに行くついでにまた見にいってしまうかもしれません（笑）。

せっかく発表になったので。今はこの仕事をしています↓

http://tangogameworks.com/project/

おひさしぶりです！
今日は今の会社の忘年会で、ビンゴ大会があって僕は景品として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

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

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

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

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

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

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

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

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

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