ゲーム/映像的なものと工学的なものの違い
なんか似ているようで異なる技術。
ゲームで出来てるのにどうしてCADやCAEでは出来ないのか、などと言われることがあってみたり、自問自答してみたり。
ちょっと整理してｍ・・・いや、書き散らかしてみる。整理はしてない。
IK (Inverse Kinematics; 逆運動学）
ゲーム/CG系でいうIKと、ロボット工学系でいうIKは、似ているようで結構違いがありそう。
各関節の角度（足の付根、膝、足首など）からつま先の位置を求めるのがFK（Forward Kinematics）、逆につま先の位置から各関節の角度を求めるのがIK（Inverse Kinematics）。
MMD（MikuMikuDance）のモーションデータ（VMDファイル）を再生するプログラムを組んだことがある。キャラクタの3Dデータ（PMDファイル）をモーションデータに沿ってアニメーションさせるプログラムだ。
MMDでは下半身のモーションはIKを使って定義されている。どういうことかというと、与えられた腰の位置やつま先の位置を元に、適切な膝の角度を自動で計算しなくてはならないということだ。
参考：http://d.hatena.ne.jp/edvakf/20111102/1320268602
上記ページを見ればわかるけど、アルゴリズムは割と単純で「なんと、こんな程度のアルゴリズムでそれっぽく動くのかー！」とちょっとした感動を覚えた。
でも産業用ロボットのIKはそんなに簡単には行かなそうだ。こちらは作った経験ないので単なる想像だけど。
ロボットにおけるIKは、指定された手先の位置と向きを厳密に守らなくてはならない。ロボットは手先で仕事をする。モノを掴んだり、塗装をしたり。だから指定された位置や向きを厳密に守らなくては仕事ができない。
一方MMDで使われているIKは「それっぽく見える」だけで厳密にIKボーンの位置と向きをトレースしないので、ロボットには適用できないはず。
それに加えてロボットでは
- 様々な機種（関節数が違ったり関節の自由度が違ったり）に対応しないといけない。
- 関節の曲がる角度に制限がある。
- 手先の位置が合っていても、肘関節の位置が他の物体に接触してはいけない。
などの厄介な問題がありそう。
そう考えるとロボットのほうが難しそうだが、一方でゲームほどリアルタイム性は求められない。
物理演算
最近ゲームはいとも簡単にヌルヌルと物理演算が動いていて驚かされる。
以前 BulletSharp という物理エンジン（Bullet Physics の .NET ラッパー）で遊んでみたことがある。カオスな動きをするはずの「二重振り子」を BulletSharp でシミュレーションしてみたのだ。
結果は、全然カオスな動きにならなかった。単純に揺れるだけで、あっというまに揺れが収束してしまう。
つまり、Bullet Physics は正確に物理をシミュレーションしているわけではないということが分かる。リアルタイム性を確保するために演算ロジックには何らかの「ごまかし」が入っているのだと思う。ゲームなどで「それっぽく」見せるには十分だが、物理シミュレーションとしては使えない。
衝突判定
ゲームの衝突判定は、直方体や球やカプセル（薬の）みたいな形で形状を近似して行なっているようだ。詳しく知らないんだけど、MMDとかUnityとかを見たらそんな感じだった。
一方で工学系では現実世界をシミュレーションする必要があるので、ポリゴン等で構成された複雑な形状同士をそのまま正確に衝突判定しなくてはならない。場合によっては「物体同士の距離が 5mm 以下まで近づいたら警告」みたいな距離判定も必要になる。
というわけで衝突判定はゲーム/映像系と工学系で全然違う。
CADとCG
ここが一番詳しいだけに一番書きにくい。
うまく端折って簡単に紹介できない。
というわけでバッサリ割愛（笑）。まあ、内容は上記の延長で推して知るべし。
あと、あれだ。ゲームや映像系で演算を間違えても何も壊れないし誰も死なないんだけど、工学系では現実世界に被害が及ぶからなー。
