そもそもの始まりは、ティラノサウルスを研究したかったことではありません。
まず絵を描いて、それを動かしてみたかった。
脚の曲がり方が分かりにくかったので、テスト画面に鳥型の参考脚を追加しました。黄色が膝、青が足首です。鳥のように見える「逆関節」は膝ではなく、後ろへ下がった足首です。
自分の知っている範囲で、シンプルなのに動きがうまいと感じていた例が、Virtua Fighter 2（バーチャファイター2）でした。バーチャファイターのコードやモデルを再現したかったわけではありません。少ない情報でも、立つ、踏み込む、重心が移るという動きが伝わる。その感覚を、恐竜の制作にも持ち込みたかった。
そこから、次の疑問が出ました。
> 恐竜も、輪郭を描く前に骨格を押さえた方が、自然に動かせるのではないか。
最初から数学や学術資料を調べていたわけではありません。絵を動かしたいという気持ちから始まり、失敗した動きを直すために、数学の考え方と学術資料へ進みました。
先に結論：輪郭より先に、歩ける骨格を作る
最初は、ティラノサウルスらしい黒いシルエットを作ろうとしていました。
頭を大きくする。口を開ける。尾を長くする。短い腕を付ける。脚を太くする。
しかし、静止画としてそれらしく見えても、歩かせると次の問題が出ます。
- 足が床から滑る
- 左右の脚が同じ場所に重なる
- 重心が支持脚の外へ出る
- 顎だけが浮く
- 胴体と脚のつながりが切れる
そこで問題を「ティラノサウルスの絵を描く」から「ティラノサウルスの骨格が、接地を保ったまま歩けるか」へ変更しました。
現在の実験は、その判断を確認するための小さなリグです。
ここでいう「リグ」とは、3Dモデルやキャラクターを動かすための骨格・関節・動きのルールを組み込んだ仕組みです。人形に骨組みを入れて、脚や腕を動かせるようにするイメージに近いです。今回の実験では、完成した恐竜の模型ではなく、骨格点と関節、足の接地や重心を確認するための簡易的なリグを作っています。
画面には、黒い輪郭ではなく、線と関節だけが表示されます。左右の脚、接地している足、重心、支持範囲を確認しながら、歩く・走る・尻尾の強さ・速度を切り替えられます。
関節を置く
↓
脚の到達点を動かす
↓
2本の骨から膝の位置を計算する
↓
左右の位相をずらす
↓
接地・重心・支持範囲を検査する
↓
最後に輪郭を付けるこの順番にした理由と、そこへたどり着くまでの「間違った歴史」を、この記事で振り返ります。
数学と学術資料に相談した
動きを作るときは、数学の考え方に相談しました。点、距離、角度、制約、重心をどう置けば、足が床から滑らないか。
恐竜の形を考えるときは、学術資料を検索しました。骨や関節の構造を調べ、輪郭を直接まねるのではなく、設計条件へ変換しました。
役割は分けています。
- 数学：決めた条件を計算し、動きを検査する
- 学術資料：骨や関節について、形を考える根拠を得る
- 自分の判断：どの姿勢をティラノサウルスらしいと採用するか決める
調査した事実を、そのまま絵にすれば正解になるわけではありません。数学で動きを検査し、資料で形の根拠を確認し、最後は人間が選ぶ。この分担が必要でした。
竜盤類とは何か
ティラノサウルスは、恐竜の中では竜盤類（Saurischia）の獣脚類に分類されます。竜盤類という名前は骨盤の骨の並び方に由来し、ティラノサウルスのほか、竜脚類や鳥類につながる獣脚類を含みます。名前だけを見ると少しややこしいのですが、「鳥盤類」から鳥が生まれたのではなく、現生鳥類は肉食性獣脚類の系統から進化しました。ロンドン自然史博物館の恐竜分類でも、ティラノサウルス類と鳥類型恐竜は竜盤類の獣脚類として紹介されています。
ただし、同じ系統に属することと、現代の鳥とまったく同じ歩き方をすることは別です。今回の分析では鳥の脚を関節の順番を理解する参考にしながら、数トンの体を支えるティラノサウルスでは、骨盤・股関節・膝・足首・指へどのように荷重を分散するかを別に検証しています。鳥は獣脚類から進化したという解説も、この「近縁だが同じ動きではない」という整理に役立ちます。
記事を公開したあと、足の動きが人間のように見える問題にぶつかった
最初の記事を公開した時点では、骨格点が動き、接地滑りも数値上は0になっていました。しかし、動きを見続けると違和感が残りました。
- 膝が人間の脚のように後ろへ逃げる
- 上段の骨格と下段の肉付きが別の周期で動く
- 足裏ではなく脚全体が床をこするように見える
- 骨盤と脚が別々に上下し、胴体から脚が外れて見える
- 脚を矩形で切って回していたため、関節に裂け目ができる
- 尾と首が動いても、全身の荷重変化とつながっていない
つまり、「足が滑らない」という一つの検査には合格しても、「大きな頭と胴体を二本脚で運んでいる」とは見えませんでした。数値上の成功と、動物として自然に見えることは別でした。
修正1：二つあった歩行計算を一つにした
上段の骨格は周期1.2秒・歩幅120、下段の輪郭は周期0.76秒・歩幅86で動いていました。これでは同じ恐竜を見ているのに、骨と肉が別の歩き方をします。
そこで、歩行状態を一度だけ計算する computeRigState() を作り、周期、歩幅、接地率、足上げ、左右の位相、骨盤、首、尾を上段と下段へ共通配布しました。現在の基準は周期0.76秒、歩幅86、接地率62%、足上げ34です。
修正2：骨盤を全身の基準にした
以前は脚だけが上下し、胴体・首・尾がその動きに十分ついてきませんでした。修正後はmanifestの骨盤中心を剛体の基準点にし、胴体、首頭、腕、尾、左右の股関節へ同じ移動と傾きを適用しています。
骨盤の傾きは最大でも約±0.8度に抑えました。大きく揺らして「動いている感」を足すのではなく、支持脚へ荷重が移る範囲だけ動かします。
修正3：膝を選ぶ向きを制約した
2リンクIKには、同じ股関節と足首へ届く膝の候補が二つあります。近い方を無条件に選ぶと、人間の脚のような曲がり方が混ざりました。
修正後は、股関節から膝が進行方向側へ出る候補を優先し、股関節 → 膝は前、膝 → 足首は後ろ、足首 → つま先は前という順序を保ちます。さらに支持脚の膝が伸び切らないよう、最小屈曲角を22度にしました。
修正4：足裏ではなく、指先で接地させた
ティラノサウルスは人間のように踵を床へ置くのではなく、趾行性の脚として考える必要があります。そこで接地点を足首から指先へ移し、支持期は指先の世界座標を固定しました。
足は 足首 → 中足部 → 主趾・内趾 に分けています。中足部は固定長の剛体として扱い、蹴り出し時の角度変化は最大2度に制限しました。101位相を検査した結果、左右の支持指の滑りは0でした。
修正5：切った脚を回すのをやめ、骨軸から毎フレーム肉付けした
初期の輪郭は、一枚の脚を大腿・下腿・足へ矩形で切り、回転させていました。速く試せる反面、膝や足首に裂け目が生まれ、肉が関節から外れて見えます。
現在は、股関節・膝・足首・中足部・指先の骨軸から、始点と終点で太さが違う輪郭を毎フレーム作ります。股関節、膝、足首には連結用の楕円を重ねます。これで骨の長さを保ちながら、肉付きも同じ関節へ追従するようになりました。
この修正を、解析画面だけで終わらせないことも重要です。/dino/の遊び場でも同じmanifestを読み、同じ股関節・膝・足首・指先から脚を描くようにしました。分析した恐竜と、ゲームで遊ぶ恐竜を別物にしないためです。
いちばん良かったのは、再現して実現するプロセスだった
この制作でいちばん良かったのは、最後に恐竜が動いたことだけではありません。
「なぜこの動きがよく見えるのか」を自分で考え、参考にした動きを分解し、骨格・関節・重心という形に置き換え、失敗したら原因を探して作り直す。そのプロセスを、自分の手で持てたことです。
気になる動きを見つける
↓
何がよく見えるのか考える
↓
骨格・数値・制約へ分解する
↓
小さく再現する
↓
動かして失敗を見つける
↓
Web上で触れる形へ実現するこれは、完成品を受け取るだけの作業とは違います。自分の疑問から始めて、再現可能な構造を作り、ブラウザで動かし、最後はWordPressの記事から読者にも触ってもらえる形にする。そこまで持っていく過程そのものが、今回の成果でした。
間違っていた歴史：最初から歩行を作っていたわけではない
制作の履歴を振り返ると、最初から正しい順番で進んでいたわけではありません。
1. 数値違いの候補を大量に作れば、正解に近づくと思った
頭の角度、頭の大きさ、背中の高さ、肉付きなどを少しずつ変え、候補を9案、40案、さらに自動探索へ増やしました。
ここで使う32pxは、一般的な基準ではなく、私が決めた制作上のルールです。あとでゲームの中で恐竜を動かすとき、形を確認しながら動作させるための最低限の大きさとして設定しました。32pxより小さい表示では細かな差がゲーム上で分かりにくくなるため、この大きさを基準に候補を比べています。
この方法は、比較画面を作るところまではうまくいきました。けれど、変更量が小さくなると、32pxでは見分けられない差まで探索し始めます。
機械上のスコアは違っても、人間には同じに見える。これは「探索できた」だけで、「良い形を選べた」ことにはなりません。
そこで、微差の探索を止め、構成原理が違う案を比べる方向へ戻しました。さらに、32pxで次の差が0.5px未満なら自動停止するルールも入れました。
2. 口を開ければ、ティラノサウルスらしくなると思った
次の失敗は、顎と口を輪郭の一部として後から足したことです。
口の開口、口角、下顎の厚み、顎関節を別々に比較しました。しかし、下顎が浮く案が生まれました。頭蓋と顎関節と首が、ひとつの構造としてつながっていなかったからです。
頭を短くした比較では、頭全体まで小さくなる面積補正の問題も起きました。数字を変えれば形が改善する、という前提が間違っていました。
最終的には、吻端、眼窩上の隆起、後頭部、顎関節、下顎角、首の接続という6つのランドマークから基準頭部を作り直しました。口の細部を先に変えるのではなく、頭蓋と首の構造を先に固定しました。
3. 一脚だけを見れば、歩行を設計できると思った
脚の比較では、股関節、膝、足首、中足骨、指先の5点を置きました。
これは脚の形を見るには役立ちましたが、歩行全体を見るには足りませんでした。一脚だけを自然に曲げても、二本脚になったときに左右の支持関係が崩れるからです。
一脚中心の比較は止め、二本の脚、二つの接地点、全身の重心、支持範囲、左右の床反力を同時に見る力学テストへ切り替えました。
4. 肉付けを自動探索すれば、自然な胴体になると思った
体軸を固定し、肉厚を40案生成して、制約を通った代表4案を表示する探索も作りました。
ところが、内部の空白と股関節の位置が壊れ、全案を不採用にしました。外側の輪郭だけ見ていると、関節が肉の中に埋まっているか、脚が胴体から自然に出ているかを見落とします。
そこで、関節円による連結、骨盤内の股関節、二本の脚、内部空白なしを必須条件にしました。
5. A/Bテストを回せば、良い動きが選べると思った
候補をA/Bで並べ、どちらが自然に見えるかを比べるテストもしました。比較画面を作ると、頭の角度、脚の高さ、尾の振れ方の違いを見つけやすくなります。これはうまくいった部分です。
ただ、A/Bテストの勝敗だけで「自然な恐竜の動き」を決めることはできませんでした。画面の大きさ、見る順番、比較した瞬間の印象で結果が変わるからです。数値の差が小さい候補を勝者として残しても、実際に歩かせると足が滑ったり、重心が崩れたりしました。
A/Bテストは最終決定ではなく、違いを見つけるための道具として使うことにしました。最後は、骨格、接地、重心を動かして確認し、人間が採用する姿勢を決めます。
自動探索は、何を解決し、何を解決しなかったか
最終的には、目標値から始めて、関節、骨格、肉厚、ポリゴン、制約検査、修正を繰り返すループを作りました。
480案を生成し、目標誤差は 0.39934 から 0.20992 へ下がり、最終案は制約を通りました。首、骨盤、尾の結合円と、前肢・二本指のポリゴンも追加しました。
ただし、ここで「完成」とは言いません。
自動探索が証明できるのは、決めた数値条件を満たしたことだけです。人間が見てティラノサウルスに見えるか、歩き方が自然か、32pxで識別できるかは別の判断です。
このため、候補選択は人間が行い、自動処理は失敗候補を除外する役割に限定しました。
現在の歩行テストは、3ファイルでできている
今回の画面は、次の3ファイルだけで動きます。
tools/dino/tyrannosaurus-motion-lab.html
tools/dino/rex-rig-lab.css
tools/dino/rex-rig-lab.jsHTML：描画する場所だけを先に用意する
SVGの中に、地面、支持範囲、骨、関節、ラベルの5レイヤーを置きます。
<svg
data-rig-svg
viewBox="0 0 1000 600">
<g data-ground></g>
<g data-support></g>
<g data-bones></g>
<g data-joints></g>
<g data-labels></g>
</svg>最初から複雑なSVGを手で書かず、JavaScriptが毎フレーム各レイヤーを描き直す構造にしました。輪郭を描く前の検証なので、線と円だけで十分です。
JavaScript：23骨格点と重心を座標として扱う
骨格には、尾、骨盤、肩、首、頭、顎、短い腕、左右それぞれの股関節・膝・足首・足先を置いています。現在のmanifestには、可動部のpivotを含む23個の骨格点と、別に重心データを持たせています。
胴体と頭は、次のような設計用の点として扱います。
pelvis → shoulder → neck
head → jaw
tailTip → tailMid → tailRoot
tailRoot → pelvisこれは解剖学的な復元データをそのまま再現したものではありません。輪郭と歩行を検証するための、設計用リグです。
脚：2本の骨から膝の位置を計算する（2リンクIK）
ここでいう「2リンク」は、脚を「股関節から膝まで」と「膝から足首まで」の2本の棒として考える方法です。大腿（太もも）と下腿（すね）の長さを決め、股関節を始点、足首を終点にします。
歩行中は、足首の位置が毎フレーム変わります。膝を画面上で手作業で置くと、脚の長さが伸びたり縮んだりしてしまいます。そこで、股関節と足首の位置、2本の骨の長さを入力し、足首に届く膝の位置を毎フレーム自動で計算します。これが2リンクIK（逆運動学）です。
solveLeg()では、まず股関節から足首までの距離を測ります。次に、余弦定理という「三角形の辺の長さから、角度や位置を求める計算」を使い、股関節と足首を結ぶ線に沿った膝の位置と、そこから横に離れる距離を求めます。最後に bend で膝を前後どちらへ曲げるかを決めます。
var d = Math.hypot(dx, dy);
var a =
(upper * upper
- lower * lower
+ d * d)
/ (2 * d);
var h =
Math.sqrt(
Math.max(
0,
upper * upper
- a * a
)
);これにより、足先を動かしても脚の長さが勝手に伸び縮みしません。膝の向きは bend で左右を制御します。
歩行：足を「置く」と「運ぶ」に分ける
歩行では、片方の足を床に置いて体を支え、その間にもう片方の足を前へ運びます。プログラムでは、1回の歩行の中の進み具合を「位相」として扱い、左右の脚の位相を半周期ずらしています。
var leftPhase = cycle % 1;
var rightPhase =
(cycle + 0.5) % 1;足を床に置いて体を支える時間を「支持期」と呼びます。支持期では、足先の位置を地面に対する座標（世界座標）で固定します。胴体が前へ進んでも足先は同じ地面の位置に残るため、足が床を滑って見えません。
足を床から離して前へ運ぶ時間を「遊脚期」と呼びます。このときだけ足を持ち上げ、次に足を置く場所へ移動させます。
最初は、歩幅（1回で進む距離）、接地率（1周期のうち足が床についている割合）、周期（歩行1回にかかる時間）を固定し、足が滑らないことを確認しました。走るモードでは、歩幅を大きくし、周期を短くします。その結果、左右どちらの足も床についていない時間が生まれるため、この時間を「飛行期」として扱います。
重心と支持範囲：見た目ではなく診断値を出す
重心は、頭、胴体、肩、尾の設計用質量を加重して計算します。
com =
(head * 4
+ pelvis * 10
+ shoulder * 6
+ tailMid * 10)
/ 30;足の接地点から支持範囲を作り、重心がその中にあるかを表示します。歩くときは「支持範囲内」、走るときは「動的支持」または「飛行期」と表示します。
これはティラノサウルスの本当の質量中心を測定したものではありません。姿勢を比較するための設計用の重心です。ここを科学的な復元値と取り違えないことが重要です。
うまくいったこと
現在の歩行テストで、確認できたことは次の通りです。
| 項目 | 結果 |
|---|---|
| 左右別の脚チェーン | できた |
| 23骨格点＋重心データ | できた |
| 2リンクIK | できた |
| 左右の位相差 | できた |
| 2歩以上のループ | できた |
| 接地滑り | 検証サンプルで 0.00 |
| 支持範囲外 | 検証サンプルで0 |
| 歩く・走る切り替え | できた |
| 尻尾の強さ変更 | できた |
| 速度変更・停止・再生 | できた |
| 指先を基準にした接地 | 101位相で左右とも滑り0 |
| 支持脚の最小膝屈曲 | 約22度を維持 |
| 骨格と肉付きの歩行状態 | 同じ計算へ統合 |
| ゲームへの同一リグ接続 | ティラノで実装 |
| console error | 0件 |
実ブラウザでも、歩くモードでは「支持範囲内」、走るモードでは「動的支持」、どちらも接地滑り 0.00 を確認できました。
まだ失敗していること、または未完成なこと
一方で、この画面は完成したティラノサウルスではありません。
- 解析画面の肉付けは設計用で、完成した復元模型ではない
- 指や顎など、細部の可動リグは未接続
- 走行中の動的重心は、まだ質量と床反力から厳密に計算していない
- トリケラトプスは四足用の骨格・接地順序へ作り直す必要がある
- 重心は設計用の近似値で、実物の復元値ではない
- 数値条件を通っても、自然な歩行だと人間が承認したわけではない
- 32pxでの識別と、実際の利用者による評価は別に残っている
つまり、現在の状態は「歩行の物理条件を調べられるところまで」です。黒い輪郭を付けて完成させる工程は、骨格姿勢を人間が確認してから進めます。
この失敗から得たルール
今回の制作で、次の順番が最も安全だと分かりました。
- 何を「自然」と呼ぶかを決める
- 固定する関節と変える軸を決める
- 二本の脚、接地点、重心を同時に置く
- 数値検査で明らかな失敗を落とす
- 人間が姿勢とシルエットを選ぶ
- その後に肉付けと輪郭を足す
逆に、次の順番は失敗しやすい。
輪郭を描く
↓
細部を足す
↓
あとから骨を置く
↓
動かそうとして破綻するAIや自動探索に候補を作らせること自体は、かなり役に立ちました。ただし、候補を増やすほど良くなるわけではありません。固定条件、変更軸、失敗条件、人間の停止判断が必要です。
まとめ
このティラノサウルスは、最初から正しく設計されたものではありません。
数値違いの比較に寄り道し、顎を浮かせ、一脚だけを見て、肉付けを先に試し、全案を不採用にしました。その失敗を経て、ようやく「骨格が歩けるか」を先に確認する小さな画面へ到達しました。
今うまくいっているのは、脚の長さを保ったまま動かし、接地滑りと重心を数値で確認できることです。まだ失敗しているのは、骨格の正しさを、そのまま自然な恐竜の姿や完成ロゴへ変換できていないことです。
この先は、ゲーム内で接地と肉付きを確認しながらティラノサウルスを詰め、その共通契約を四足用へ拡張してトリケラトプスへ進みます。二足の脚を増やすだけではなく、前脚と後脚の役割、四点の接地順序、低い重心、頭部とフリルの質量を別に定義します。
完成した絵を見せる前に、どこで間違え、何を捨て、何を確認したかを残す。今回の歩行テストは、そのための制作ログです。
最新版の追記：鳥の脚と比べて、膝と足首を見分ける
ここまで作っても、脚の関節について一つ分かりにくいところが残っていました。
画面で後ろへ突き出している関節を見て、「これは鳥の膝のような逆関節なのか。それとも足首なのか」と迷いました。自分の目だけで判断すると、股関節から下の関節の名前を取り違えます。
そこで、恐竜の脚だけを見て決めるのをやめ、同じ位相で動く「鳥型の参考脚」を横に並べました。ここでいう鳥型は、特定の鳥を正確に復元したものではありません。関節の順番を見比べるための簡易モデルです。
比較では、次の4点を同じ名前で表示しています。
- 股関節：体に脚がつながる場所
- 膝：股関節に近く、進行方向へ出る関節
- 足首：膝から下で、後ろへ下がる関節
- つま先：足首から前へ戻り、地面に触れる部分
つまり、鳥や恐竜の脚が「逆関節」に見えるとき、後ろへ曲がっているように見える場所は膝ではなく足首です。膝は体に近い位置にあり、足首が後ろへ下がり、つま先が前へ戻ります。
今回の私の間違いは、見た目の曲がり角をそのまま「膝」と呼んでしまったことでした。修正方法は、関節を名前で推測せず、股関節 → 膝 → 足首 → つま先という順番に分け、同じ動きの中で色とラベルを付けて確認することです。
最新版の歩行テストでは、膝を黄色、足首とつま先を青で表示しています。歩行の位相が変わると、ティラノサウルス側と鳥型側の両方が動きます。読者は「どちらが正しいか」を一枚の静止画で決めるのではなく、関節の順番と動き方を見比べられます。
ただし、この比較だけでティラノサウルスの脚を完全に復元したことにはなりません。鳥類にもさまざまな脚の形があり、化石動物の軟部組織や動きには不確実さが残ります。今回の最新版は、まず自分の見間違いを減らし、脚の構造を読者と一緒に確認するための表示です。
この追記で、制作の記録は「骨格を動かせた」で終わりません。最初に間違えた見方を残し、比較画面を作り、関節名を付け、動かして確かめるところまでを一続きの制作過程として掲載します。
