現在位置: ホーム / shade+OSX / 実践-小動物編#10

実践-小動物編#10

習作の続きにネズミをモデリングしてみる

ボーン作成の前に

そもそもボーンとは、端的に言ってしまえば、半自動ポリゴンメッシュ変形システムのことだ。

 

ポリゴンメッシュの変形とは、とどのつまり頂点座標の変更だ。いままでさんざんやってきたモデリングで、それこそ万単位の指定をしてきた、頂点座標の移動のことだ。それを半自動でやってしまおう、というのが、ボーンと呼ばれるシステム。というわけで、

 

ありがちな疑問1:ならモデリングで変形すればいいんじゃね?

回答1:やれるもんならやってみろ

たとえば、ネズミの左手を挙げたポーズを作りたいとする。

ボーン解説#1

これを、モデリングのように手作業で頂点座標を移動する場合は、

ボーン解説#2

上図で選択した頂点、計57個を、手の形が崩れないように移動する必要がある。まあ、shadeを使う分には、まとめて選択してマニピュレーターで移動し、回転させれば、そこそこなんとかなりそうな気がする量ではある。

だが、これがジャンケンとなった場合は、どうだろうか。しかもハイポリリアルな人間の手だったりした場合。たとえば、

ボーン解説#3

これ。練習で作成した自由曲面の手を、普通にポリゴン分割しただけで、まったく作り込んでいないやつだが。俺的shade最初期の手だな。こうして今見てみると、つくづく下手く・・・ゲフン。それはともかく。こんな手でも、頂点数は大笑いの一万越え。この後、造形やポリゴンの整理をしたとしても、軽く五千はこえると思う。これを、グー、チョキ、パーに変形するのは、骨が折れるを通り越して、気が遠くなる。ましてや、「おちゃらかホイ」なんてやられた日には。

参考までに、このように各頂点を細かく移動させて変形させるアニメーションのことを、モーフィングという。一番原始的なポリゴンメッシュ変形手法なのだが、ハリウッドなどでは、結構多用されている。ボーンを使うより詳細な形状の制御が出来るので、映画館の大画面で見ても破綻しない絵作りが可能だからだろう。だが、かかる経費も尋常ではなく、ワンカット数秒でウン億円、なんていう世界だ。

 

というわけで、もう少し手軽に変形できないものか、と考え出されたのが、ボーンシステムだ。ポイントとしては、

  • ある範囲にある複数の頂点を、まとめて移動できるようにする。(範囲の目安とする棒状のガイドが骨のように見えることから、ボーン(骨、bone)と呼ばれている)
  • 直感的な変形が出来るように、座標値ではなく、角度や捻れといった要素で変形できるようにする。(ボーンの関節(ジョイント)のこと)
  • 滑らかな変形が出来るように、各頂点毎に、どれだけボーンの影響を受けるか、を個別指定できるようにする。(スキンのこと)

あたりか。

上のネズミの例でいえば、57頂点をいじくり回すよりは、変形の基準とするボーンの、

ボーン解説#4

肩の関節部分を上に120度ほど回転させるほうが、はるかにわかりやすく、かつ楽に作業が出来る。

 

ありがちな疑問2:自動でメッシュ変形すんなら、モデリングもしてくれよ

回答2:残念。変形は出来ても、造形は出来ないのだよ。

ボーンシステムは、あくまでも変形を手伝ってくれるだけであって、自動的に頂点を追加したり削除したりはしてくれない。つまり、すでにあるものを、あらかじめ決められた法則に従って変形させることしかできないのだ。

最初にあるモデルがすべて。頑張ってモデリングしよう。

 

shadeのボーンシステムについて

さて、というわけでボーン。ホネ。骨。shadeにも、ボーンシステムは組み込まれている。だが、参考書にあるような、一般的にいわれているボーンと、ちょっと体系が違う。この違いを理解するまでに時間がかかった。

 

1. shadeでは、関節(ジョイント)がメインで、ボーンはサブ

一般的には、二本のボーンを配置すると、その継ぎ目が自動的に関節となる。だが、shadeの場合、二つの関節(ジョイント)を配置することで、その間に自動的にボーンが作成される。・・・と、言葉で並べてしまうと、たいした違いはないように聞こえるが、出来上がるボーンの数と関節の数に注目して欲しい。

一般的なシステムでは、単純に直線で配置した場合、ボーン2本で関節1個、ボーン3本で関節2個、といった具合に、「ボーン数-1」が「関節数」となる。

ボーンと関節#1

対して、shadeの場合は、関節2個でボーン1本、関節3個でボーン2本、といった具合に、「関節数-1」が「ボーン数」となる(前例と言い方を合わせれば、「ボーン数+1」が「関節数」となる)。

ボーンと関節#2

この違いが、後で出てくるスキニング処理に影響するんだな、これが。

 

2. shadeでは、ボーンは副産物扱い(としか思えない orz)

とにかく図面でボーンが目視しづらい。下図はボーンを配置した直後の図だが、ボーンが見やすいように、ポリゴンメッシュも非表示にして、後からPhotoshopを使用して正面図のボーンに色をつけてみたものだ。元々のボーンの色は、右面図の尻尾のつけ根あたりにある灰色の線だ。

ボーン解説#4

目を凝らさないと見えない

さらに、形状編集モードでジョイントを選択状態にしても、ジョイントは青くなるくせに、ボーンは灰色のまま。普段の作業では、これにポリゴンメッシュの表示が重なるわけで、結果、

ボーン解説#6

もはやボーンを見ることは不可能に近い。

これには参った。いったんスキニングが完了してしまえば、ボーンが見えなくても、関節が目立つので、作業的に支障は出ないのだが。

問題となったのは、次。

 

3. shadeでも、スキニング(バインド)だけはボーンを基準として行われる

これを把握するのに、かなり時間がかかった。すでに述べているが、ボーンの目的として、「ある範囲にある複数の頂点を、まとめて移動できるようにする」というのがある。このうち、「ある範囲」というのがポイント。shadeがメインで扱っている関節は、いわば「点」である。つまり、「点」は「範囲を持たない」のだ。

ボーンシステムによる変形では、どのぐらいの変形をさせるか、を決めているのは、確かに関節だ。実際、3Dをプログラム的に処理する場合にも、「ある関節に紐づいている頂点に対して、関節に設定された変形量を割り当てる」という作業を行う。その点では、shadeのシステムは非常にプログラム寄りの考え方をしている。

ボーンに対してスキニングを施す際、自動でやらせようとしたら、「その関節が持つ影響範囲」を特定しておく必要がある。それが、一般的なシステムではボーンであるわけだが、shadeでも、この部分は同じシステムを踏襲している。つまり、「スキニングをするときだけボーンがメイン」になるのだ。困ったことに。

 

なにがどう困ったかについては、次回以降の「ネズミのホネ付け」にて。