最近あまり走れてないけど今週はちょっと自転車通勤。
あと、週末に舞洲クリテ。こんだけ乗れてないのにクリテに出るのは無謀という気もしないでもないって感じ。
以下、それらの記録。
【“[自転車] 4/12～4/18 の走行記録”の続きを読む】
最近あまり走れてないけど今週はちょっと自転車通勤。
あと、週末に舞洲クリテ。こんだけ乗れてないのにクリテに出るのは無謀という気もしないでもないって感じ。
以下、それらの記録。
【“[自転車] 4/12～4/18 の走行記録”の続きを読む】「リバースフット」 で検索するとたくさん出てきます。
ただ、Softimage XSI や Maya ばかりだったので、Blender で作った例をあげときます。（まぁ、たいして変わりませんが）
名前が見にくいと思いますが、以下のようになっています。
以上が基本的な骨格部分です。
脚のメッシュを以上のボーンでスキニングすることになります。
以下は上記のボーンをコントロールするためのコントローラです。
また、図ではずらして描いてますが、本当は ctrlLeg と ctrlToe、ctrAnkle は重なっています。そして、これらが AnkleAngle の先っぽのところにあります。
コントロールに使うのは ctrlLeg、ctrlToe、ctrlAnkle、そして、poleLeg だけです。
あとは見やすく選択しやすいように Shape を作ったり、グループ分けして色をつけたりすれば OK です。
もちろん、コントローラの 4つ以外はボーンレイヤーを分けて普段は非表示にしておけば邪魔になりません。（なにより、間違って動かしちゃったりするのを防げます）
サンプルの blend ファイルを置いておきます。
http://cid-ca42d76a68f54d16.skydrive.live.com/self.aspx/Public/Blender/LegRig.blend
（Blender 2.49b）
つま先も動かせるようにした 「リバースフット改」 という感じのものですが、結構使いかってはいいんじゃないかと思います。
ここで紹介するのは、↓の内容をそのまんま Blender でやってみたというものです。
http://www.sonofpat.com/Tutorials.html
って、ありゃ、サイトが無くなってるぅ。残念だな。気になる方は Web Archive とかで探してみればみつかるかも。
最初にお断り。
正直、今回の手法はほんとにそこまでする意味があるのか？見合った効果があるのか？よくわかりませんｗ
それと Skinbones 法という名前が 3DCG 一般で使われている用語なのかよくわかりません。検索してもそれらしいのはほとんど見つからないから上記のサイトを書かれた人がとりあえずそう呼んでただけのような感じがします。
で、どういう方法なのかというと下図 (1) (2) みたいなものです。
これを見ればだいたい検討つくとは思いますが、(1) は赤が肩ボーン、青が上腕ボーンです。緑はすべて補助ボーンで上腕に連動して自動的に動きます。(2) も同様で、赤が腰ボーン、青が大腿ボーン、緑は大腿ボーンと連動して動く補助ボーンです。
そして、これが Skinbones の特徴と言っていいと思いますが、1つの頂点を動かすために 1つの補助ボーンが入れてあります。(1) では肩の 6つの頂点を動かすために 6つの補助ボーンが、 (2) では股関節の 8つの頂点のために 8つの補助ボーンが入っています。
もともと人体の皮膚は骨によって形が決まるわけじゃなく、骨の周りにある筋肉やら脂肪やらといったいろんな組織によって形付られているわけです。それをごく単純化した骨の位置関係だけで本物と同じような形にしようということに無理があるのは明らかです。かと言って、まじめに筋肉をシミュレートするようなのは大変です。そこで必要なボーンをジャンジャカ入れ、それで少しでもうまい具合に変形するようにしよう、ということなんでしょう。
で、これらの補助ボーンは以下の要素によって動きが制御されます。
・Copy Rotation Constraint
補助ボーンに Copy Rotation Constraint を仕込んで、上腕ボーンや大腿ボーンと連動して自動的に動くようにします。
・Copy Rotation の Influence
たとえば、Influence を 0.1 にすれば、上腕が 90度動いたときに 9度だけ動くことになります。
・ボーンの位置と長さ
本物の人体と違ってボーンを体の中に納める必要があるわけじゃないので、好きなところにボーンを配置できます。
また、長くすれば大きく動きますし、短ければ小さく動きます。
・Roll 値
Armature の Eidt Mode のメニュー Armature→Bone Roll でセットしたりリセットしたり、もしくは、Armature→Transform Properties で出るパネルで表示・設定できる Roll 値のことです。
この値はそれぞれのボーンのローカル座標の向きを決めるものです。普通なら上腕を前に回転させれば補助ボーンも前に回転する、というようになるわけですが、Roll 値をいじると前のとき下に、下のとき後ろに、というように回転軸をずらすことができます。
以上の Influence、位置・長さ、Roll 値を組み合わせて補助ボーンがいい感じに動くように調整するわけです。
と、内容的にはこれだけです。
ただ、実際にやってみるとそれなりには大変でした。
上腕は前と下に大きく動きますし、上や後ろにもちょっと動きます。股関節も同様です。そのため、どちら向きに動いてもそれなりにいい結果になるというポイントを探しだすのは簡単ではありません。そもそもそんなポイントは無いってこともあるでしょうし。また、当然ながら頂点の位置も重要になります。けど、頂点の位置を調整すると近くの頂点にも影響を与えたりしてそれらも再調整が必要になったりします。結局、すんなりうまくいくことはめったになく、あれやこれやと調整を繰り返すことになります。ちまちまと調整してると 「ShapeKey 登録して、上腕ボーンでドライブするようにした方が早いんじゃね？」 とか思えてきます（笑）
というわけで、最初に書いたように 「ここまでする意味あるのかなぁ？ここまでしなくてももっと単純な方法でも似たような結果になるんじゃないかなぁ？」 と感じているのが正直なところです。
もちろん、Skinbones という手法を否定するつもりもありませんし、うまくはまれば単純なスキニングよりかなりいい結果が出るんじゃないかとは思ってるんですけどね。
けど、ちょっと調整が大変すぎるかなぁ、と。
正直、次にボーンのセットアップをするときにはこんなにたくさん補助ボーンを入れたりはしないと思いますｗ
まず何も考えずに作った例。
下図 (1) の細い部分が前腕、ちょっと太くなってるところが手首から先と思ってください。それぞれ、LowerArm、Hand という名前のボーンが入っています。頂点ウエイトも図の通り。それぞれ黄色く選択されている頂点が Weight:1.0、されていない頂点が 0.0 です。
これで Hand ボーンを 90度ひねったのが図 (2)。真横からだとわかりにくいのでちょっと斜めから見てます。一列の並びだけで 90度分のひねりの相手をしなくちゃいけないのでかなり不恰好になります。
極端な話、180度ひねると図 (3) のようになっちゃいます。
これを何とかしようというのが今回の話。
ちなみに、前回の 「[Blender] 肘や膝をなるべくきれいに曲げるための補助ボーン」 に書いたようにこれもデュアル・クォータニオン・スキニングを使うとこうはならなかったりするわけですが、今回も Quaternion ボタンはオフのままで何とかするってことで。
オーソドックスなのが図 (4) のように前腕全体でひねる方法。
実際の人間も、手首が回転するわけではなく、前腕の 2本の骨がクロスするように動くことで手首のひねりを実現しているそうですから、そういう意味でも理にかなっているのかも。
図 (4) では頂点ウエイトが LowerArm は左から 1.0, 0.75, 0.5, 0.25, 0.0、Hand が左から 0.0, 0.25, 0.5, 0.75, 1.0 となっています。
これを 90度ひねってみたのが図 (5)。
図 (2) と比べるとかなりましです。
ただ、この方法ではどうしても前腕が痩せてしまいます。
頂点の位置をうまいことすればもう少しましになるかもしれませんが、スキニングの仕組み上どうやったって痩せます。ひねり方向の移動では、複数のボーンが引っ張り合った結果、回転軌道上ではなくボーンの中心方向によってくるんですから避けようがありません。
あと、今回の話の本質とは関係ないので無視してますが、図 (4) みたいな構造だと手首を上下左右に曲げることができません。曲げると図 (6) のように前腕全体がしなっちゃいます。そりゃ、Hand のウエイトを前腕部分に割り振ってるんですから当然です。なので、この方法でやるなら手首の曲げとひねりを別々のボーンで行うなどの工夫が必要です。（それも下に書く今回の手法と同じような感じで対応可能ですが）
というのが前置き。ここから、ひねりをきれいに、と言うか、痩せないようにするためのひねり用補助ボーンの話です。
まずは図 (7)。
UpperArm は上腕のボーンです。ボーンの親子関係を示すために足しただけで、ひねり用ボーンとは関係ありません。（今回の例ではあってもなくてもいっしょ）
Twister1 がひねり用の補助ボーンです。LowerArm と同じように UpperArm の子になっています。見えなくなってしまうため図では離して描いていますが、実際には LowerArm とまったく同じ位置に重なって入っています。そして Twister1 には Copy Rotation Constraint と IK Solver Constraint が仕込みます。
Copy Ratation のターゲットは Hand です。なので、Hand が回転すると Twister1 も同じく回転します。
IK Solver のターゲットも Hand です。なので、Twister1 は常に Hand の方を向きます。また、Chain Len を 1 にしているのでこの IK Solver が影響するのは 1つのボーンだけ、すなわち、Twister1 自身だけです。
この Copy Rotation と IK Solver の両方が入っているのがミソです。こうすると Copy Rotation によって Hand に同期して回転しますが、IK Solver によって向きが Hand の方に修正されます。IK Solver は向きを修正するだけでひねり方向の回転にはノータッチなので結果的に、向きは LowerArm と同じ、けれども Hand と同じだけひねった状態、となります。
そして、もうひとつのミソが Copy Ratation の Influence が 0.5 になっていることです。こうすると Twister1 は Hand のひねりの半分だけひねられます。もちろん、0.8 にすれば 80%、0.2 にすれば 20% という具合に Hand の何%ひねるかを指定できます。
では、本番。
図 (8) がそれです。
ひねり用ボーンを Twister1、Twister2、Twister3 の 3本にしました。この図でも離して描いていますが本当は LowerArm とまったく同じ場所に重なって入っています。そして、Copy Ratation の Influence の値を除いて設定はまったく同じです。
頂点のウエイトは図のようになっています。すべて選択されているところが Weight: 1.0 でされていないところが 0.0 です。見れば分かる通り、複数のボーンのウエイトが入っている頂点はありません。
これの Hand を 90度回転させてみたのが図 (9) です。
Hand が 90度、Twister1 は 67.5度（75%）、Twister2 は 45度（50%）、Twister3 は 22.5度（25%） だけひねられています。
図 (5) と見比べてもらえば痩せてないのがわかると思います。そりゃ、ひとつの頂点はひとつのボーン影響しか受けないようにしたんですから痩せるはずはないんですが。
ボーンも表示させたのが図 (10) です。LowerArm がドリルみたいになってますが、これは重なって入っている Twister1、Twister2、Twister3 がそれぞれ違う角度で回転しているからこう見えます。
ところで、補助ボーンを LowerArm とまったく同じ場所に同じ長さで入れていますが、今回の場合、長さはお好みで構いません。始点位置は揃えないとまずいですが、長さはひねりに関しては影響しませんから。
ただ、LowerArm の位置を変えるときなどに補助ボーンの長さが違うと調整が面倒なので私は長さもまったく同じにしてます。
あと、Blender のボーンには Roll 値があります。
Armature の Edit Mode でメニューの Armature→Bone Roll でクリアしたり設定できたりするやつです。また、Armature→Transform Properties で出るパネルで Roll 値を見たり変更することもできます。
この Roll 値はボーンそれぞれの座標系を決める値ですから、これがずれていると Copy Rotation の結果もずれます。
これも都度調整するのは面倒なので、私は、LowerArm と位置も長さも Roll 値も同じ、としています。
前回の 「[Blender] 肘や膝をなるべくきれいに曲げるための補助ボーン」 に 「手首のひねりを手首ボーンではなく LowerArm ボーンをひねることによって表現しているような場合は二軸回転することになるのでこの方法は使えない」 と書きましたが、これの回避策も今回の手法で可能です。今回の手法では手首のひねりは補助ボーンで表現するので LowerArm はひねらなくていい、と言うか、ひねらないようにできる、というわけです。
この間ニコニコに上げた春香には最近書いている天使の輪やら平面とカーブで作った眼やら肘の補助ボーンやら今回のひねりの補助ボーンやらがみんな入っているんですが、腕部分のボーンをすべて表示したのが図 (11) です。
肘のところにある青い四角形が前回の肘の補助ボーン、肘の上下にある青いジグザグが前回の肘の内側と外側を調整するための StretchTo を仕込んだ補助ボーン、上腕と前腕にあるサイコロみたいな青い立方体が今回のひねり用補助ボーン、あとはコントローラーやら何やらです。もちろん補助ボーンはボーンレイヤーを分けておいて普段は非表示にしとけば邪魔にはなりません。（左上にちょっと見えてるのは 「[Blender] 平面とカーブで眼を作る」 で書いた瞳のサイズ、ヨリ目、位置をコントロールするためのコントローラー）
本物の人体は肩をひねれるようですが、同じことをすると簡単に肩がねじれてしまいます。そこで肩はひねらずに上腕をひねるようにしています。
同様に股関節も股関節でひねるのではなく大腿でひねるようにしています。
ちなみに、以前見た Softimage XSI の解説動画では null を配置してそいつを expression で動かすといった感じでひねってました。Copy Rotation と IK Solver の二段重ねっていうのは Blender 独特かもしれませんが、本質的にはやってることは同じです。
上に書いたそのまんまなのであまり必要ないようには思いますが一応サンプル blend ファイルを置いておきます。
http://cid-ca42d76a68f54d16.skydrive.live.com/self.aspx/Public/Blender/Twist.blend
（Blender 2.49b）
まずは何も考えず普通に。
下図 (1) は、腕 （ここでは単純に八角柱） に UpperArm （上腕）、LowerArm （前腕） のボーンを入れたものです。頂点ウエイトは図のようになっています。（黄色く選択されている頂点が Weight: 1.0 でされていないのが 0.0）。
これを 90度、135度曲げてみたのが図 (2)。
肘の外側にあたる部分は結構ひしゃげます。パイプを曲げたときみたいな感じとでも言えばいいでしょうか。
まぁ、スキニングの仕組みから言って極々普通です。
通常のスキニングは単なる線形補間、すなわち、一つの頂点を複数のボーンが引っ張り合いっこして位置を決めるわけです。今回の場合、肘のところの頂点は UpperArm、LowerArm とも Weight: 1.0 なので同じ力で引っ張り合います。なので当然こういう結果になります。
ちなみに、ウエイトは比率なので、1.0 : 1.0 でも 0.5 : 0.5 でも 0.1 : 0.1 でも結果は同じです。
そういや、ずいぶん前に 「単なる線形補間ではなく、回転している部分は回転で補間する方式があればいいのに。クォータニオンで計算すりゃできるんじゃないの？」 みたいなことを書いたことがあるような気がしますが、どうやらそれがデュアル・クォータニオン・スキニングと呼ばれるものみたいですね。
Blender にもデュアル・クォータニオン・スキニングは搭載されています。Armature Modifier の Quaternion ボタンを押すだけです。実際押してみると肘のひしゃげ方がずいぶんましになります。
ならそれでいいじゃん、という気もしないでもないですが、ここではデュアル・クォータニオン・スキニングは使わないということで以下進めます。（単に私が使ってないからですが）
話がそれましたが、普通のスキニングではこういう形になってしまうわけですが、実際の肘を見ると骨の形から来てるんだと思いますがこんなにひしゃげません。むしろちょっととがってるような感じがするくらいです。膝も同じような感じですね。
で、これを改善したいわけですが、頂点の位置を調整すれば多少はましになると思います。
ただ、スキニングの仕組みから考えて、複数のボーンで引っ張り合う以上近くに寄ってくることは避けようがありません。
ならば、複数のボーンで引っ張り合わなけりゃいいんじゃね？というのが以下の方法です。
（元ネタは BlenderArtists のフォーラムで見たんだったと思う）
図 (3) は Elbow ボーンを追加してあります。重なって見にくくなっちゃってますが、Elbow ボーンは UpperArm ボーンの子で LowerArm ボーンとほとんど重なって入っています。
また、Elbow ボーンには Copy Ratation Constraint を仕込んであります。ターゲットは LowerArm ですが、Influence を 0.5 にしてあります。
頂点ウエイトは図のような感じです。
これを 90度、135度曲げてみたのが図 (4)。
Elbow ボーンは Copy Rotation によって LowerArm にあわせて回転しますが、Influence が 0.5 になっているため LowerArm のちょうど半分だけ回転します。
肘のところの頂点はこの Elbow ボーンによってスキニングされるのでひしゃげ方はだいぶましになっています。
ちなみに、たぶんですが、デュアル・クォータニオン・スキニングにしたときと同じ結果になってるんじゃないかと思います。（回転で補間するってそういうことだよね？）
こんな単純な形ではなく、実際のモデルで試してみると、頂点の位置などをうまいこと調整すれば 「まぁ、許容範囲じゃね？」 という位にはできそうな感じです。
ただ、この方式にはちょっと注意点があります。
LowerArm ボーンを複数軸で回転させると、当然それにあわせて Elbow ボーンも半分だけ回転するので肘の形が壊れます。
通常、肘や膝は一軸でしか回転しませんが、たとえば、手首のひねりを手首ボーンではなく LowerArm ボーンをひねることによって表現しているような場合は二軸回転することになるのでこの方法は使えません。
と、言いつつこれには回避策があります。それについてはまた次回。
さて、だいぶましになったとはいえ、もう少し肘を尖らせたいような感じもします。
また、下図 (5) (6) のように 45度くらい曲げた場合は肘の内側が凹んでいます。Elbow ボーンをいれてある図 (6) はだいぶましにはなりますがそれでもちょっと凹んでいます。
では、これの対処法。まずは肘の内側。
下図 (7) がそれです。
UpperArm、Elbow、LowerArm は上のと同じです。
これを動かすとどうなるかというのが図 (8) です。ただ、InnerAnchor、InnerTarget、InnerStretch は UpperArm と LowerArm になるべく近づける、できれば重ねてしまった方が効果がはっきりします。重ねてなくても効果はありますが、見た目にもわかりやすいので図 (8) では重ねています。
頂点ウエイトは図 (8) の黄色く選択されている頂点に InnerStretch の Weight: 0.2 を加えています。それ以外は今までと同じです。ですから、選択されている頂点は Elbow の Weight: 1.0 と InnerStretch の Weight: 0.2 の両方のウエイトが入っています。
図 (8) を見たまんまですが、肘がまっすぐなときは InnerStretch は腕に重なっています。肘を曲げるにつれて見かけ上 InnerStretch が内側に出てきます。それによって InnerStretch のウエイトが入っている頂点が内側に引っ張り出されます。
肘の外側もやり方は同じです。
それが図 (9) です。
そして肘を曲げてみたのが図 (10)。
こちらも同じく黄色く選択された頂点に OuterStretch の Weight: 0.2 を加えています。
ちょっと影響が大きすぎて肘が飛び出しちゃってますがもちろんこれは OuterAnchor や OuterTarget の位置、および、頂点のウエイトで調整することになります。
あんまり必要ないと思いますが、いちおうサンプルの blend ファイルを置いておきます。
http://cid-ca42d76a68f54d16.skydrive.live.com/self.aspx/Public/Blender/ElbowBone.blend
（Blender 2.49b）
どうでしょ？
こういった手法を使えば肘や膝の形状をそれなりに制御できます。
もちろん、肘や膝だけでなく肩や足の付け根などにも使えます。が、こういったところは可動範囲が大きすぎてなかなかうまく制御できないのが難しいところですが。
また、StretchTo を使う手法なんかは、腕を曲げたときに力こぶを作ったりといったようなことにも使えそうです。
アニメ調のキャラでは眼が大きい場合が多々あります。
あまりに眼が大きいためそれにあわせて眼球を作ると頭から飛び出すほどの大きさになっちゃうこともよくあります。
頭から飛び出すわけにはいかないので、球はあきらめて平面で作るとか、以前 「[Blender] 平面に近い眼球を作る方法」 で紹介したような球を empty でスケール変換して見かけ上ひらべったくするとか、そういった方法で何とかするわけです。
で、あるとき、ふと 「平面を曲げて眼を作ってやればいいんじゃね？」 と思い立ちました。
以下、長々と解説を書いてますが、blend ファイルを見りゃわかるって方は下のほうにサンプル blend ファイルへのリンクを貼りつけてありますのでそいつをどうぞ。
■ 平面とカーブで眼を作る
基本はこれだけです。
Curve Modifier を知っていれば何も特別なことはやってないんですけどね。
アニメ調の眼にする場合は、この平面を UV 展開してテクスチャを貼ることになると思います。その辺は書きませんが、単なる平面なので UV 展開も簡単です。
■ ボーンを組み込む
眼を動かせるようにボーンを組み込みます。ここでいくつか注意点があります。
以下、ごちゃごちゃと書いてますが 「理屈はいいから方法だけ教えれ」 という方は適当に読み飛ばしてくださいｗ
まず、眼をキョロキョロさせる前に、そもそも頭が動いたときにそれにあわせて眼も動いてくれないと困ります。
すなわち、上で作った平面とカーブを頭にあわせて動くようにする必要があるということです。
普通に、Armature Modifier を追加して、Weight Paint で頂点にウエイトを設定して、、、もちろん平面はこれで問題ありません。ところがカーブでこれをやろうとすると困ったことになります。
Curve には Armature Modifier はあるのですが、Weight Paint がありません。というか、Vertex Group がありません。なので Armature Modifier を追加してもアーマチュアにあわせて頂点を動かすことができません。なにか方法があるのかもしれませんが私にはわかりませんでした。
そこで別の方法で眼を頭にあわせて動かす必要があります。以下、その方法です。
ここでは、下図 (1) のように Neck ボーン（首）→Head ボーン（頭）と繋がっていて、この Head ボーンに追随するように眼を動かしたいとします。そして、これらのボーンは BodyArmature というオブジェクト名のアーマチュアになってるとします。
これで横方向用カーブが Head ボーンの子になりました。
試しに Pose Mode で Head ボーンを動かしてみれば、それにあわせて横方向用カーブが動くはずです。
あとは同じ手順で縦方向用カーブ、平面を Head ボーンの子にします。
これで Head ボーンにあわせて眼が動くようになったはずです。
続いて、眼をキョロキョロさせられるようにします。
普通なら Head ボーンの子ボーンとして Eye ボーンを追加して、眼の平面に Armature Modifier を追加して Weight Paint で頂点ウエイトを設定して、、、とするところです。
ところがこの方法ではうまくいきません。
眼の平面は Head ボーンの子オブジェクトです。Head ボーンが動けばそれにあわせてオブジェクトが動きますが、これはオブジェクト自体がグローバル座標系で動いているだけです。当然、オブジェクト内のローカル座標系は動いていません。それに対して、Eye ボーンは BodyArmature オブジェクトの座標系の中にあり、その位置はEye→Head→Neck→．．．というように根っこのボーンからの動きがすべて累積された状態にあります。そのため、Eye ボーンの変位量を眼の平面に適用しても期待した結果になりません。
ではどうするか？以下、その方法です。
ここまでやったのが下図 (2) です。
パッと見では Eye ボーンが Head ボーンの子ボーンのように見えますが、上記の手順のようにやれば 「Head ボーンの子オブジェクトとして EyeArmature があり、その中に Eye ボーンがひとつだけある」 という状態になっています。
上で座標系がどうのと書きましたが、要するに 「眼のオブジェクトが Head ボーンの子オブジェクトになってるんだから、それを動かすボーンも Head ボーンの子オブジェクトにする必要がある」 ってことなわけです。（余計わかりにくいか？ｗ）
あとは眼の平面に Eye ボーンのウエイトを設定してやれば OK です。
ここでも注意があります。
まず、Modifier の順番。これは上記の通り Armature Modifier が上になるようにする必要があります。（スキニングしてからカーブで曲げるか、カーブで曲げてからスキニングするか、の違い）
次に頂点のウエイトですが、周囲一周を Weight: 0.0 のまま残しているのはわけがあります。
Curve Modifier はオブジェクトの原点を見ているのではなく、メッシュの一番左側 （もしくは右側） を調べてそこを原点に処理しているようです。メッシュすべてを Weight: 1.0 とすると Eye ボーンを動かすとメッシュ全体が動くわけですが、そうするとメッシュの一番左側もいっしょに動き、その動いた結果を原点として Curve に貼りつけるので結果として何も動かないことになります。（こんな書き方でわかるかな？ｗ）
そのため周囲は動かないように Weight: 0.0 のままにしているわけです。
また、もともと一番左にある頂点ではなく、スキニング後にもっとも左になった頂点が原点とみなされるようです。そのため Curve Modifier を使っているメッシュをスキニングで変形させると予想と違う位置になってしまう場合があります。これはどこが原点になっているかを考えながらうまいこと調整するしかないと思います。（うーん、文章で説明するのは難しい）
基本的な構造は以上です。
上記は片目分ですが、両目必要な場合は同じものをもう 1セット作ることになります。
■ サンプル blend ファイル
blend ファイルをあげておきます。
http://cid-ca42d76a68f54d16.skydrive.live.com/self.aspx/Public/Blender/CurveEye.blend
（Blender 2.49b で作った blend ファイルです）
このサンプルには両目分入っています。
また、左右の目をまとめて操作できるコントローラのボーンも入れてあります。
とりあえず、横着して Grease Pencil ですがコメント書いといたので見ればわかるんじゃないかと思います。
ちなみに Move と Cross は EyeArmature.L/R の Eye ボーンにしこんだ Copy Location で連動させてます。（Local 座標系の Offset で）
Size は同じくしこんだ Transform で X 方向、Z 方向への移動をサイズに変換してます。
また、「あまり大きく動かすと眼のメッシュが壊れる」 の理由はカーブの長さが足りなくなったり、メッシュのサイズがカーブからはみ出したりするからです。このあたりは必要十分になるように適当に調整すれば OK です。
以上、長々と書きましたが、自分ではかなりいい方法だと思っています。
カーブなのでかなり柔軟に形状を調整できますし、肝心なところは単なる平面なのでテクスチャの調整も楽です。
アニメ調のキャラの眼だけでなく、ザクやドムのモノアイみたいなやつとかにも使えそうです。
ここ 10ヶ月くらいあまり Blender はさわってなかったんですが、ふと、またモデリングとかしてみようかなぁと思い立ちました。
で、その前に以前いくつか試したことをまとめておこうと。
というわけで、最初は 「マテリアルノードで天使の輪を描いてみた」 です。
Blender は 2.49b です。
（試してたのは 10ヶ月以上前なのでその頃は 2.49 はまだ出てなかったと思いますが、今回この記事を書くにあたって 2.49b でサンプルを作りなおしました）
天使の輪っていうのはアレです。アニメ風の絵の髪の毛にできる反射のことです。
普通にスペキュラで描いただけではああいうアニメ風の輪っかにはならないんですよね。
そこで反射ではなく、マテリアルノードで描き足してやるようにしてみました。
もともとのアイデアはこちらです。
「天使の輪をトゥーンレンダリングで作る」
こちらは Softimage XSI のシェーダーを使った例ですので Blender でそのまま再現することはなかなかできませんが、内容自体はとても参考になりました。
というか、
というのを読んでものすごくショックを受けました。「おぉ、ライトなんて関係なかったんや！」 とｗ
で、これらを素直にマテリアルノードでやってみました。
サンプルとして作った blend ファイルを置いておきます。
http://cid-ca42d76a68f54d16.skydrive.live.com/self.aspx/Public/Blender/TenshinoWa.blend
（Blender 2.49b で作ったサンプルファイル）
以下、簡単な解説
マテリアルノードは以下のようなもの。
分かる人が見ればそのまんまですが、
と、こんな感じです。
自分では普通にスペキュラで描くよりはだいぶましになってるかな？と思います。
ただ、本当にマンガチックな天使の輪は髪の毛を完全な球体とみなして、そこに輪っかを投影しているような感じだと思います。（天使の輪がデコボコしない）
これができるとおもしろいかなぁなんて思ってるんですが、ちょっと難しそう。
一応、髪の毛のメッシュを球体とみなしたときの x, y, z 座標を頂点カラーの RGB にでも入れておいて、マテリアルノードではその頂点カラー （球体とみなした時の x, y, z） から求めた法線を Normal に放り込んでやることができればできそうだ、なんて思ってるんですがどうでしょ？
ところで、この方法で天使の輪を描いたテスト動画をニコニコにも上げてたりします。
わかる人にはすぐわかりますが 友Pのテスト動画 のマネですｗ
リピートすると繋がってゆらゆらする予定だったんですが、なぜか最後に静止部分が入っちゃってますね。Blender では 30fps×2秒の 60フレームぴったりになってるはずなので、エンコードするときに最後にちょっと余計な部分が追加されちゃってるのかな？
ちなみに、これは以前ニコニコに上げたりしていたモデルとは別のモデルです。
最初のは事実上生まれて初めてモデリングしたものでしたし、いろいろと直したいところもあったりで、きれいさっぱり捨て去って完全に新規にモデリングし直しました。
で、このモデルを作ってる時に今回の天使の輪やその他いくつか試してみたのが今回の記事の元ネタです。
けどこのモデルはボーンを入れ終わって後はもうちょっと調整すれば完成かな？というところまで進めたところで、その後 10ヶ月完全放置になってしまっているというかわいそうな娘です。（まぁ、Blender 自体をさわってなかったわけですが）
そういや、このモデルでは髪の毛や肌の色もマテリアルノードで描いています。
シェーダーは Lambert のままにして、マテリアルノードで Color を ColorRamp に繋いでそこで 2値 （髪の毛なら暗い茶色と明るい茶色、肌なら暗い肌色と明るい肌色、という具合） にしています。髪の毛は 2値化した色に今回の方法でさらに天使の輪を加えています。
これなら影の色も自分で指定できますし、Blender 標準の Toon シェーダーよりきれいにできるように思います。もちろん、2値だけでなく、暗い色・普通の色・明るい色の 3値にするなどもできるはずですし、それぞれを好きな色にできるわけです。
ただ、ライティングが変わるとマテリアルノードの ColorRamp を調整してやらないと陰がうまくでないという大きな欠点がありますが。少なくとも 2.49 ではマテリアルノードの ColorRamp にキーを打ったりできないので、アニメーションするときには困ることもあるかもしれません。
おまけネタ
シマシマのテクスチャを GIMP2 で簡単に作る方法 （Photoshop とかでも似たような感じでできると思いますが）
これだけ。
22日の休日に走りに行っただけ。
火～木は雨、金は用事、週末の土日も乗れずでいくらなんでもヤバイ感じ。
土曜日に用事で梅田に行ったついでにチェーンを買ってきた。日曜日に付け替え。
RFX8 を購入したときのままだから 1万2千キロくらい走ったのかな。
ほんとはもっと早めに替えてあげた方がいいんだろうけど。
まだ雨がちだけどちょっとは乗れた一週間。
以下、自転車通勤の記録。
自転車通勤 3日。
雨の日もあったから仕方ないけど、それにしても最近ぜんぜん乗れてない。
最近サボりっぱなしだったけど、今週からまたそれなりに乗っていこう、、、と思ったけど雨やら何やらで 3日自転車通勤しただけ。
以下、自転車通勤の記録。
【“[自転車] 2/22～2/28 の走行記録”の続きを読む】自転車通勤 1日のみ。
天気は悪くなかったけどなんとなくモチベーションが上がらず。
自転車通勤は 3日間と少なめだけど、土曜日に久しぶりに走りに行った。（友人と）
以下、それらの記録。
12（火）のパンク箇所が原因で再びパンク。タイヤに入った切れ目がチューブにダメージを与えてしまう模様。仕方なく新品を買ってきてタイヤ交換。
用事と雨で 1日おきに 3日しか乗れなかった。
以下、自転車通勤の記録。
【“[自転車] 1/18～1/24 の走行記録”の続きを読む】イマイチ、モチベーションがあがらず 2日しか自転車通勤してない。
以下、自転車通勤の記録。
なぜか二回もパンクした。どちらもリアだけど、一回目はガラス片、二回目は針金みたいなものと別原因。
単に運が悪かったということなんだろうか？
以下、自転車通勤の記録。
【“[自転車] 1/4～1/10 の走行記録”の続きを読む】CodePlex にこんなのがありました。
http://silverlightviewport.codeplex.com/
すごく簡潔な説明しか無いですし、ソースを見たわけでもないので詳細はわかんないんですが、WPF/XNA 上で Silverlight をホストするものみたいです。（Host ではなく Render になってますが）
また、「まだめっちゃ実験的なもんだよ！」 とのこと。
作者さんのブログの記事はこちら
Render Silverlight in WPF ? WPF SilverlightViewport
まず、「より明確に理解するために取り組んでみたホビープロジェクトだ」 といった文からはじまってます。
で、以降をざっと要約すると 「Silverlight は COM API でホストできる。C++ のサンプルコードもある。けど、これは Win32 のウインドウに描画するのが前提。Silverlight はウインドウレスもサポートしてるはず。なので、Silverlight をウインドウレスにロードして画面の代わりに GDI ビットマップに描画させてみたらうまくいった。ただ、CPU 使用量が高かったのとアルファが透過できなかったけど。で、ちょっと汚くなったけど interop でごにょごにょしたらアルファも抜けるようになったし、パフォーマンスも良くなった。WriteableBitmap も使ってみたけど、結局 InteropBitmap にした。パフォーマンスも良くなったし。」 という感じです。
ソースをダウンロードして Visual Studio 2008 でソリューションを読み込んでやればビルドして実行できます。
（XNA を入れていない場合、XNATestApplication プロジェクトと Primitives3D プロジェクトが読み込めませんが、無視して読み込んでしまえばとりあえず TestApplication を動かしてみることはできました）
TestApplication を実行してみるとちゃんと動いてます。動いているのは http://silverlight.net/ にある SHOWCASE を表示しているやつです。
Window1.xaml の <slvp:SilverlightViewportElement ...> の Source を Source=”http://silverlight.net/content/samples/sl3/toolkitcontrolsamples/run/System.Windows.Controls.Samples.xap “ と書き換えてやって Silverlight 3 Toolkit を動かしてみましたが、それなりに動いてます。
なお、マウス入力はそれなりに生きてますが、キー入力は未対応みたいです。
（マウス入力は WPF 上のイベントを転送してやってるんじゃないかと思いますが、キー入力は IME とかいろいろ絡んできそうなので簡単ではないのかも）
作者さんもホビープロジェクトと言ってる通り、実用性についてはよくわかりません。
そもそも、「Silverlight をホストしなくても WebBrowser を使えばいいんじゃね？」 という気がしなくもないですｗ
けど、試みとしてはおもしろいですね。
以下、自転車通勤の記録。
【“[自転車] 12/21～12/27 の走行記録”の続きを読む】World# - Real Time 3D Augmented Reality with Silverlight より。
Silverlight 4 では webcam API がサポートされるってことで、当然のように AR している人がいましたｗ
完全にマネージド （C#） な NyARToolkitCS という ARToolkit を使っているそうです。
また、3D モデルのレンダリングに Balder というマネージドなゲームエンジンを使っているそうです。
上記は実際に Silverlight 4 で動かしてるところをスクリーンキャプチャしたものだそうです。
記事に 「スクリーンキャプチャソフトがリソースをえらく食ってる」 といったことが書かれてますので、カクついて見えるのはキャプチャムービーだからみたいです。
記事によると 50～60fps でスムーズに動いているとありますね。
13日（日）、シルベスト梅田店にて OGK のモストロを購入。
今まで使ってたヘルメットも OGK のもうちょっと安いヤツだけど、落車したときにぶつけてたようで実は割れてた。ほんとはすぐに新しいのを買おうと思ってたんだけど、なんだかんだで遅くなり今回ようやく購入。
あと、Vittoria の RUBINO PRO と Panaracer の R-Air 18-23c 48mm バルブも購入。
暇を見て付け替えるつもり。
と思ったら、下にも書いたように 15（火） の朝にパンク。そのときにタイヤをはずしてみたら弾力が無いというか素人目に見ても限界っぽい感じ。ちなみに、今まで付けてたのも Vittoria の RUBINO PRO。走行距離は6450km ほど。よくもったな。
というわけで、その日の帰宅後に新しいタイヤに付け替え。
以下、自転車通勤と土曜日に走りに行った記録
【“[自転車] 12/14～12/20 の走行記録”の続きを読む】
名前: 青柳 臣一
（アオヤギ シンイチ）
住所: 大阪, 日本
仕事: ソフトウエアの開発
自転車: ANCHOR RFX8
好きなもの: C#,Silverlight,自転車,ロードバイク,ロードレース,アイマス,ニコマス,中村繪里子さん(えりりん),Blender,3DCG
RSSリーダーで購読する