カテゴリー: 3DCG

JettoBevel – LightWaveプラグイン

最終更新：2020/05/03

オブジェクトの角の面取りや丸めについてはかなり前に触れたことがあるけど、ラウンダー（Rounder）ツールや、LW 11で追加された面取り（Chamfer）ツールでは思ったような加工や正確な加工ができないことがある。

オブジェクトの形状が単純なうちはいいけれど、かなり複雑になってからラウンダーやチャムファーを使うと座標の演算中に処理不能に陥ってモデラーがクラッシュしてしまうことも珍しくない（ミドルレンジの3DCGソフトウェアの限界というか、宿命のようなもので、欠陥とまでは言えない）。

そこで、ネットを調べていたら、JettoBevelというプラグインを知った。最近はYouTubeで使い方の解説動画がアップロードされていることも多く、プラグインの機能をイメージしやすくなった。なお、「Jetto」というのは作者のニックネームのようなもので、特に深い意味はないようだ。

JettoBevelの概要

ベベル（標準機能）

標準機能のベベル（Bevel）では、一度に1段階しかセグメントを増やすことができない。しかも、複数のポリゴンを選択した場合、各ポリゴンごとにベベルがかかってしまうため、実用的でない部分があった。インターフェースが簡便で理解しやすいのは長所。

ベベルツールの数値入力画面。シンプルで解りやすいインターフェースを持つ。シフトとインセットは説明するまでもないだろうけど、その間にある「+ / -」という設定項目はシフト量やインセット量をランダムで増減する範囲を指定するためのもの。機械のようなモデリングよりも、植物のような長さが一定でないものを作る時に使う。

マルチシフト（標準機能）

複数ポリゴンをベベルしたい場合はマルチシフト（Multishift）ツールを使うことになるけど、パラメータが多く難解なうえ、一度に1段階しかセグメントを増やせない特徴は同じ。複数段追加したければ、プロファイルを自分で作成しなければならないなど非常に扱いづらい。

マルチシフトの数値入力画面。インセット量とシフト量はベベルと同じなのでまだ理解できるけど、その他のパラメータはいまひとつ理解できていない。

JettoBevelの特徴

LightWaveのモデラーはサブパッチ（キャトマル）によるモデリングに都合が良いように進化してきた部分があり、機械のようなかっちりした形状のモデリングに弱いという問題がある。でも、機械のモデリングをしていると、ベベルを複数セグメントにわたって連続してかけたいという事態や欲求というのは往々にして起こる。

このJettoBevelでは、マルチシフトをベースとして、ベベルのように単純なパラメータを設定するだけで半自動的に複数セグメントのベベルを再帰的に一度に追加可能なうえ、ベベルをかけたポリゴンに更にベベルを続けてかけられるようにインターフェースが工夫されている。

LightWaveは今ではBlenderなどに押されてマイナーな3DCGソフトウェアになってしまったけど、過去には多くのユーザーに支持されていたものなので、ユーザー・プラグインが多数開発されていて、資産として今でも公開されている。

LightWave Assets : Plugins – JettoBevel

JettoBevelを使った角の丸め

まずは簡単な角の丸めをやってみる。次の画像のような直径1mの円柱を用意してみた。

JettoBevelを起動すると、次の画像のようなパネル・ウィンドウが表示される。ここで、ベベルの「Type」を「Circle」に、「Shift」と「Inset」に100mm、「Segment」に「4」と入力する。セグメントの右にある円弧状のボタンはベベルをどちら側に膨らませるかを指定する。

入力が終わると、プレビューで完成後の状態が確認できる。次の画像のように4段階のセグメントを持つ丸みを持ったベベルが追加されているのが判る。

このくらいなら、ラウンダーでも同じことはできる。そこで、先ほどベベルをかけたポリゴンに更にJettoBevelを適用する。設定はほとんど同じで、円弧を反対向きに変えただけ。

適用すると次の画像のようになる。想像どおりの結果なので驚くべきところはないように思えるけど、この時点でラウンダーで同じことを行うのは厳しくなってくる。ラウンダーはあくまでも選択したエッジを丸めるものなので、ラウンダーを適用済みのセグメントをベベルのように追加できるわけではない。

更に2段階、JettoBevelでセグメントを追加して、普通のベベルで円柱を伸ばした状態。棒に溝を切ったような、一見簡単なように見えるオブジェクトではあるんだけど、これと同じようなことを行いたければ、標準機能では回転体ツールなどを利用するなどして、セグメント数などをあらかじめ綿密に決めておかなければならない。

回転体ツールというのは、意外と曲者で、半分の形から最終形を予測しながらモデリングしなければならないため、やってみたら思ったような形にならなかった、というのも珍しくなく、面白いツールではあるんだけど、それほど出番は多くない。

ひとまずディスク生成ツールでセグメントだけ切っておいて、ストレッチ（Stretch）や拡大縮小（Scale）ツールなどを使って直径を調整して綺麗な半円形の溝を作るというのも人間には辛い作業だ。いちいち三角関数を使って電卓で計算しながら縮小率を求める労力を考えるとぞっとしない。できればそういう計算はコンピュータにやってもらいたいところだ。

LightWaveのモデラーは行き当たりばったりモデリングができるのが良いところという部分もあるため、あらかじめ出来上がりを決めてからモデリングを始めるというスタイルがそもそもソフトウェアの特性とマッチしていない。

JettoBevelによる穴の刳り貫き

JettoBevelは、オブジェクトの角をあらかじめ丸めておきたいという目的を叶えるのに十分な能力を持っている。でも個人的には、その真価はおそらく、複雑な形状の穴を開けたい時に発揮されると思っている。

次の画像のように、少し複雑で、複数のポリゴンにわたる範囲に穴を開けたいとする。普通ならば、拡張プラス（Extender）を使ってマイナス方向にシフトさせることで実現するくらいしかないわけだけど、角が鋭角になってしまう。

機械部品の角というのは旋盤やフライス盤で特注で切削したとかでなければ、直角や90度未満の鋭角というのはほとんどありえない。量産性を考慮すると、型ばなれのいいように直角以下の角を作らないようにするのが一般的。鋭角がない部品は同時に安全性にも優れている。したがって、鋭角が多いモデルはいかにも現実に存在しそうにないものになる。

余談
その昔、携帯電話のauが「au design project」という名称でデザイナーズ・ケータイを作っていたことがあり、他のケータイが曲線を多く取り入れた貝殻のような二つ折りデザインを採用していた時代に直角デザインを採用したことがあった。
そのデザインを見たメーカーの担当者がauに「本当に直角で作るんですか？　いや、そうですよね、それに意義があるんですよね…」と趣旨には理解しつつも直角加工に難色を示したことが逸話として残っている。
上でも書いたように、直角の部品はプラスチック射出成形機の金型からの型ばなれが悪く、量産性が極めて悪くなるのでメーカーとしては本当は勘弁して欲しかったはず。実際には、メーカーの努力によって直角デザインのケータイを量産することに成功した。その方法は企業秘密にあたるため、今でも明らかにされていない。
その後、それらのauケータイは工業デザインとしての優秀さが高く評価され、MoMAの愛称で知られるニューヨーク現代美術館に永久収蔵品として所蔵されるまでに至っている。

これにJettoBevelを使って、4段階ほど適用してやると、穴の周囲を丸めることができるばかりか、内側に入ったところで底に向かって広がっていく複雑な穴を実現することができる。

こういった形状は昔のF1マシンやジェット戦闘機のエア・インテークによく見られた。過去の自動車や飛行機は操縦系統のほぼすべてを油圧で制御していたため、オイルを冷やすための空気の取り入れ口が数多く必要だった。

現在では操縦系の電子化が進み、燃焼系と冷却系で2～3つ大きい穴が開いているくらいになった。自動車はオイルを冷やす需要が減ったことと空力特性の向上が理由だけど、飛行機には別の事情がある。

エア・インテークは対空レーダーにとても映りやすいため、ステルス性の向上を目的として空気取り入れ口を極力減らし、レーダーの電波がエア・インテークに入り込まないようにする方向に進化している。近年のステルス戦闘機の表面が凹凸が少なくのっぺりしていたり、直角がなく、45度くらいの角が多いのはすべてレーダーに映りにくいようにするため。ただし、空力特性は劣悪で、電子制御であるフライ・バイ・ワイヤがなければまともに飛ぶことすらできない。油圧で代替することもできないため、電子制御系に故障が発生すると即座に墜落してしまうという極めて危ういバランスで成り立っている。民間機の場合はフライ・バイ・ワイヤが三重系統になっているうえ、単位面積あたりの翼面荷重が低いため、滅多なことでは墜落はしない。

上の例のように、単純な円柱などなら三角関数を駆使すればいつかは完成するかもしれないけど、標準機能だけでこのような穴を作ろうとしたら、どうしたらいいのか見当もつかない。少なくとも、電卓で座標を計算していたのではいつになっても終わりそうな気がしない。

作例

まだ完成はしていないけど、JettoBevelを使うきっかけになった作品。ティレル・P34（当時の発音では「タイレル」）というF1史上空前絶後の6輪マシン。投入直後にワンツー・フィニッシュを飾るなど一定の成果を修めたため、F1のレギュレーションに「車両の車輪は4輪まで」という項目を加えさせた伝説が残っており、その強烈なシルエットも手伝って幅広い世代に知られている。スケール・モデルで知られる田宮模型が実車を保有していることでも有名。

基本的に角をとるのが目的なのでどこに使われているのかはわかりにくいかもしれないけど、直角以下の鋭角が目に見えて目立つようでなければJettoBevelの効果は出ていると言える。

参考記事

LightWave プラグインのメモ（100光年ダイアリー）
neonは東芝泣かせの「完全垂直」な携帯（ITmedia Mobile）
ケータイのデザイン革命！『au Design project』誕生の知られざる構想（TIME＆SPACE by KDDI）

旧メインPCのリフレッシュ (1)

最終更新：2020/04/25

いよいよ旧メインPCをリフレッシュして性能の底上げをはかり、サブPCでありながら優れた演算能力をLAN経由で提供させることで、ネットワーク・レンダリングの実現への第一歩を踏み出す。

要は、パーツをかき集めてPCを自作するわけだけど、感想から先に述べると、パーツの選定や組み立て作業が非常に楽しかった。学生の頃に1円でも安く、Windowsが動くPCを手に入れたくて自作PCに手を出したわけだけど、その経験が今になって役に立った。その当時に比べれば自作用のPCパーツも手頃で高性能なものが手に入りやすくなった。昔はケースファンもサイズさえ合っていれば回転数や静音性なんてのは二の次で選択肢も少なかった。今ではPCケースやケースファンだけでも数え切れないほどの種類があって希望のものを絞り込むのも大変なくらい。

BTOパソコンの場合は、完成品ゆえに自分はお金を出しただけで何も苦労していないために、長所よりも欠点ばかりが気になってしまうけど、自作PCなら欠点を最初から承知のうえで組んでいるので欠点も含めて愛着すら感じるようになる。目的のために思い切って削ってしまう性能も選択できるためコストの調整も容易で、後に強化したくなったら当初は備えていなかったパーツを追加すればいいのでまだ楽しみも残る。

電源仕様

PCを自作する上で根幹となるATX電源は旧PCから流用する。新しい電源を買ってもいいんだけど、旧電源を流用してもどの程度までまともなPCを組めるのか試してみたかったのもある。流用する電源は古いBTOパソコンに搭載されていたHEC-500TE-2WXという、今では値段もつかないような年代物。

電源の仕様は次の表のとおり。規格はATX12V Ver.2.3。Haswell世代以降のC6/C7ステート（12V 0.05A）には対応していないけど、TDP 95WくらいのCPUで過度なオーバークロックをしなければまだ使える電源。C6/C7ステートをBIOSで無効にしてスリープ機能を使わなければいいだけの話。ただ、12Vが2系統あるため、1枚で消費電力が200Wを超えるようなハイエンド・クラスのグラフィックス・カードを搭載すると容量不足に陥る可能性がある。搭載するとしても、せいぜい150Wが限度だろうし、グラフィックス・カードを搭載したいなら12V 1系統の新しい電源を買ってしまった方が無難。

電源仕様
モデル	+3.3V	+5V	+12V1	+12V2	-12V	+5Vsb	定格出力
HEC-500TE-2WX	24A	15A	25A	18A	0.3A	2.5A	500W
HEC-500TE-2WX	120W		444W		3.6W	12.5W	500W

当初の予定構成

最初はCPUにオーバークロックができない代わりにTDPが65Wと控え目のCore i7-9700を選び、B365チップセット搭載のMicroATXマザーボードに載せ、メモリもバリューモデルにして2×8GBで1万円もしないものにして使う予定だった。当初予算は7万円程度。

旧メインPCのマザーボードはMSIのH55M-P33というモデルだったんだけど、旧PCケースはミニタワーで奥行きがあまりないタイプで、シャドウベイに3.5インチHDDを搭載するとマザーボードのATX電源コネクタやDIMMスロットの上に被さってしまっていた。また、92mmサイズのトップフローCPUクーラーとの干渉マージンもギリギリだった。寸法がかなりシビアだったので、旧マザーボードの部品配置を参考に、PCケースを買い換えないと仮定して、MOSFETのヒートシンクが小規模でCPUソケットがPCI Express x16スロットの右端と並ぶものを探していたら、ASUSのPRIME B365M-Aが該当する唯一の機種だった。

ASUS Intel B365 搭載 socket1151対応マザーボード PRIME B365M-A 【MicroATX】

ASUS PRIME B365M-A MicroATX マザーボード

posted with amazlet at 19.08.10

参考価格: ¥ 10,800 (2019-08-10)

Asustek (2019-04-19)

Amazon.co.jpで詳細を見る

Intel Core i7 9700 デスクトッププロセッサ 8コア 4.7GHz LGA1151 300シリーズ 65W

Intel Core i7-9700 BOX (BXC80684I79700)

posted with amazlet at 19.08.10

参考価格: ¥ 44,980 (2019-08-10)

Intel (2019-05-15)

Amazon.co.jpで詳細を見る

G.SKILL 16GB (2 x 8GB) バリューシリーズ DDR4 PC4-21300 26‣デスクトップメモリーモデル F4-2666C19D-16GNT

G.SKILL 16GB (2 x 8GB) DDR4-2666 デスクトップメモリー F4-2666C19D-16GNT

posted with amazlet at 19.08.10

G.SKILL

Amazon.co.jpで詳細を見る

ところが、いざi7-9700が発売されてみると、以前から指摘されていたIntel CPUの脆弱性を緩和することを目的として最初からR0ステッピングで製造されていて、既存のシステムに導入しようとするとOSの再インストールが必要になることが判明した。脆弱性への対策なので仕方ないと言えば仕方ないけど、中途半端な時期に中途半端なものを投入してくれたものだ。

問題とされている脆弱性も、それを悪用するには相当に高度な技術が必要で、一般消費者が不特定多数の攻撃者からサイドチャネル攻撃を受けて損害を被る可能性は限りなくゼロに近い。心配すべきなのは、例えばVPNのパスワードを生成するワンタイム・パスワード・ジェネレータを持っているなど事業所のファイヤーウォールを通過する権利がある組織内部の人間が攻撃者になった場合で、ファイヤーウォールを突破する手立てもなく無作為にあらゆるIntel CPUのシステムに侵入できるわけではない。P0を選ぶかR0を選ぶかはユーザーの任意として、無印型番のCPUもとりあえずP0ステッピングでリリースして欲しかったものだ。

旧PCのシステムもだいぶ使い込んで不必要に大量のデータを抱え込んでいてパフォーマンスが落ちていると言えばそうなんだけど、喪失すると困る重大な情報がシステム・ドライブの普段意識していない領域に格納されていることもあるのでOSのクリーン・インストールだけはどうしても避けたい。

もちろん、システム・ドライブのクローンをとっておいて、重要なデータがあることが判明したらそこからサルベージすればいいんだけど、レジストリに保存されている設定などの復元にはそれなりに手間がかかるので、そこまでしてB365を前提としたPCを組む必要があるのだろうか、と意欲が喪失してしまった。

また、8コアのCPUでなければ所期のパフォーマンスを発揮できないことが予想されたので、i7-9700の代わりにCore i5 や i3 を採用することはできず、B365チップセットを採用した安価なシステム構築は諦めざるを得なくなった。安上がりに組み上げることだけが今回のPCリフレッシュの目的ではないというのもある。

構成変更

P0ステッピングで製造されている8コアCPUは、i7-9700K か i9-9900K しかなく、コストパフォーマンスを考慮してi7-9700Kを選ぶことにした。K型番を選ぶということは、Z370かZ390のマザーボードにしないと十分な性能を発揮できないということ。

旧PCケースの流用にはCPUソケットの位置が重要であったため、唯一の選択肢だったPRIME B365M-Aを使えなくなったことでMicroATXである必要性もなくなってしまった。

そこで、次のような要求を再設定してパーツ選定をやり直した。どうせ最初からやり直すなら、年甲斐もなく「光り物PC」にもチャレンジしてみることにした。

マザーボード
- CPUの消費電力制限を解除しても不安定にならない堅牢な電源回路を持つこと。
- Intel LANコントローラ・チップを搭載していること。
- Wi-FiやBluetoothを最初から内蔵している必要はなく、後の拡張性のためにCNViスロットが備えられていればいい。
- 高音質オーディオ・コントローラ・チップを搭載していること。
- PCIe 3.0 x4接続のM.2 NVMe SSDを1基以上搭載できること。
- SATAドライブを最低4基接続できること。
- フロントUSBポートをUSB 2.0/3.0それぞれ2ポート分以上搭載していること。
- 可能ならばUSB Type CのフロントUSBポートを搭載していること。
- 可能ならばThunderbolt AICコネクタを搭載していること。
- パラレル・ポートやシリアル・ポートは必要ない。
- イルミネーションも楽しんでみたいのでRGB LEDを制御可能であること。
CPUクーラー
- i7-9700Kを最大定格4.6GHzで動作させても冷やしきれる空冷CPUクーラー。
- ファンだけでなく、ヒートシンクにもRGB LEDを内蔵していること。
メモリ
- メモリ・クロックは2666MHz以上。容量は16GB以上。
- RGB LEDのライトバーを内蔵したヒートスプレッダ付きメモリ・モジュールであること。
- RGB LEDヘッダからではなく、DIMMスロットからSMBus経由でLED制御できること。
PCケース
- 組み立てやすく、メンテナンス性に優れていること。
- 搭載コンポーネントに重なりが少なくアクセスしやすいこと（特定のパーツにアクセスするために他のコンポーネントを取り外したりしなくていいこと）。
- HDDの厚さの違いのようなちょっとした規格違いに影響を受けるようなことがなく、パーツを選ばず汎用性が高いこと。
- 剛性や工作精度に優れ、長く使えること。スチールが主材料であること。
- フロントUSB 2.0/3.0ポートをそれぞれ2ポート搭載していること。
- 可能ならばUSB Type CのフロントUSBポートを搭載していること。
- 3.5インチHDDを2基以上搭載できること。
- 一般的なサイズの内蔵5.25インチ光学ドライブを搭載できること。
- 中型～大型の空冷用CPUヒートシンクが収まること。
- 内部のRGB LEDが見えるようにアクリル又は強化ガラス製のサイドパネルであること。

パーツ選定

CPU

CPUはi7-9700Kと決まっているけど、R0ステッピングのものが既に出回っているので、P0ステッピングのものを選ばなければならない。実店舗を持っているPCパーツ・ショップの場合はこだわり派向けにP0とR0を別の箱に区別して販売してくれていることもあるけど、通販などでは一般的にはステッピングを指定して注文することはできない。大手ほどその傾向が強く、P0が送られてくるかR0が送られてくるかは運任せになる。

そういった場合、価格は大手ほど安くはないけど、あえて小規模な店舗を選ぶと、ある程度融通をきかせてくれて発送する前にステッピングを確認してから送ってくれるところがある。もちろん、P0の在庫が尽きている場合は確認してもR0だけど、問答無用でR0を送りつけてくるようなことはないので、特定のステッピングを入手したい場合は小規模店舗や中古販売店を狙ってみるのもありだ。

INTEL インテル CPU Corei7-9700K INTEL300シリーズ Chipsetマザーボード対応 BX80684I79700K【BOX】【日本正規流通品】

Intel Core i7-9700K BOX (BX80684I79700K)

posted with amazlet at 19.08.10

参考価格: ¥ 47,990 (2019-08-10)

インテル (2018-11-02)

Amazon.co.jpで詳細を見る

マザーボード

最近はMSIが続いていたけど、ASRockも気になっていたので、ASRockのZ390チップセット搭載マザーボードから選定することにした。

ASUS、MSI、GIGABYTEも含めればいくつか選択肢はあったけど、すべての要求を満たすようなマザーボードはハイグレードのミドルレンジかハイエンド・クラスになってしまう中、ASRockではミドルレンジ・クラスにも要求に合致するものがあった。「Z390 Extreme4」か「Z390 Phantom Gaming 6」の二者択一になった。

Z390 Phantom Gaming 6は7セグメントLED（古典的なデジタル時計方式の数字表示器）を採用したデバッグ機能やオンボードに電源ボタンとリセットボタンを備えているなど、PCケースに不具合があった場合やベンチ板での検証にも便利な装備があることが魅力。しかし、そんなに頻繁にパーツを組み換える予定がなかったことと、コンシューマ向けのルーターやハブには対応製品がほぼないこともあり、2.5ギガビットLANは必要ないと思われたので、Z390 Extreme4に決定した。

ASRock Intel Z390 チップセット搭載 ATX マザーボード Z390 Extreme4

posted with amazlet at 19.08.10

参考価格: ¥ 19,712 (2019-08-10)

ASROCK (2018-10-09)

Amazon.co.jpで詳細を見る

CPUクーラー

海外製のCPUクーラーではヒートシンクにもRGB LEDを内蔵しているものが結構見受けられたけど、LED制御に専用のコントローラ（リモコン）やソフトウェアを使用したり、肝心の冷却性能が日本のPC自作派ユーザーにとって一定以上の評価や人気を得られていないといった問題があったため、決めきれなかった。日本設計のCPUクーラーは冷却性能重視のものが多く、通常のラインナップでヒートシンクにLEDを内蔵しているものはなかった。

幸い、ASUSのTUFゲーミングとのコラボレーションでScytheの人気空冷クーラー「無限五 Rev.B」の限定生産版としてヒートシンクにRGB LEDを追加したものがあった。LED制御は12V RGB LEDヘッダにケーブルを接続するだけのシンプルなものなので専用ソフトウェアが必要ないのもポイントが高かった。ただ、限定生産なので流通在庫がそもそも少なく、私が購入した後、日本国内では取り扱い店舗はひとつもなくなった。どうやら最後の1個だったらしい。海外に輸出したものを逆輸入するという手もなくはないけど、国内での価格を知っていると手が出せるような価格ではない。

イルミネーションを楽しみたい層には一定の需要があると思われるので、RGB LED内蔵のヒートシンクを採用した空冷CPUクーラーも通常のラインナップに加えて欲しいところだ。

Scythe Mugen 5 TUF ゲームアライアンス CPUクーラー(SCMG-5100TUF)

Scythe Mugen 5 TUF (SCMG-5100TUF)

posted with amazlet at 19.08.10

Scythe

Amazon.co.jpで詳細を見る

結局、2019年中にはRGB LEDを内蔵した無限五は再販されることはなかったけれど、2020年1月にアドレサブルRGB LEDを搭載したモデルとして復刻した。

邪推かもしれないけど、ASUSとのRGB LED内蔵CPUクーラーの再販に関する取り決めには「アドレサブルRGB LEDを含む」とはどこにも書いてなかったということを根拠にしているのではないかと勝手に思っている。

アルミニウム色の味気ないヒートシンクの無限五ではないラインナップも改めて増えて、ライトアップにこだわりたい人にとっては朗報になったんじゃないかと思う。売り出し価格が1万円弱と通常版の無限五に比べると無視できないくらいの高めの価格設定なので、アドレサブルRGB LEDにどれだけ価値を見いだせるかどうかの商品ではあるんだけれども。

サイズの新型CPUクーラー「無限伍 ARGB PLUS」が発売、120mmファン×2基搭載

メモリ

RGB LEDをヒートスプレッダに内蔵したメモリは、Team、Corsair、Kingston、G.SKILL、GIGABYTEなど主要なメーカーに数多くラインナップがあるけど、大抵大型のヒートスプレッダが取り付けられていて、空冷のCPUクーラーとの干渉は避けられないものが多数見受けられた。特に、Corsairのメモリは高さが50mmを超えるため、空冷とは相性が悪い。Corsairはイルミネーションの見栄えを良くするにはDIMMスロットを全部埋めたほうがいいことを理解していて、RGB LEDのライトバーを内蔵しただけのためだけのダミーメモリを用意している。この発想は素晴らしいんだけど、メモリをオーバークロックするようなユーザーは水冷クーラーを利用しているという想定のようだ。ダミーメモリは意外と作っているところがなく、Corsair以外だとGIGABYTEくらいしかない。

G.SKILLのTrident Z RGBとTeamのXCALIBURが最終候補に残ったけど、XCALIBURが独特の斜めデザインで最大高48mmと高めだったため、44mmと控え目なTrident Z RGBを選択した。最初は高価だったハイクロック・メモリが最近は手頃な価格になってきたため、定格2666MHzでも2933MHz以上の選別メモリでも容量が同じなら価格に大差がなくなってきた。

IntelのCPUを採用しているシステムではハイクロック・メモリの恩恵を体感として感じにくいと言われているけど、高負荷ゲームや画像処理、暗号化/複合化処理、3DCGレンダリング、動画エンコードなどCPUとメモリ間で大量のデータをやりとりする用途では威力を発揮するようで、どの程度違いが生じるものなのか試してみたくなったので、3600MHzの製品を選んだ。CASレイテンシがCL16など短いものは万単位で価格が跳ね上がるので、バランスのいいところでCL19のものにした。JEDEC準拠のDDR4-3200メモリがCL22なので、3600MHzでCL19は十分速いと思う。

なお、Trident Z RGBの後継になるTrident Z Neoが発売されたので、ヒートスプレッダが両面黒のTrident Z RGBは入手しにくくなっていくと思う。DDR4 SDRAMは作れば作るほど赤字になっていくというほど価格の下落が続いていたため、半導体メーカー各社SDRAMチップを減産する傾向にあり、選別メモリは更に入手困難になるか、価格高騰の可能性がある。今後は付加価値が高く、利益の見込めるDDR5の開発、商品化を加速していくことになるのだろう。

G.SKILL TridentZ RGBシリーズ 32GB (4 x 8GB) 288ピン DDR4 3600MHz デスクトップメモリーモデル F4-3600C19Q-32GTZRB

G.SKILL TridentZ RGB 32GB (4 x 8GB) DDR4 3600MHz デスクトップメモリー F4-3600C19Q-32GTZRB

posted with amazlet at 19.08.10

G.SKILL

Amazon.co.jpで詳細を見る

PCケース

あまりにも安いPCケースを選んでしまうと、ドリルで穴をあけたり、ネジ穴を切ったりなんてのは当たり前くらいのよほどDIYに慣れている人でない限り、基本中の基本である組み立てで問題が起こる可能性が高くなる。マザーボードを設置する場所以外は特に規格がなく、各社の特徴が出やすいので、PCケースの選定が一番大変だった気がする。

要求を満たすようなPCケースはFractal DesignのDEFINE R6くらいしかない。というか、新しくPCケースを買うならFractal Designしかないと思っていた。安くはないけど、今後PCケースは買い換えないつもりで汎用性の高い製品を選んだ。USB Type Cをフロント・パネルに搭載していないものでもよかったんだけど、後からUSB-Cを搭載したオプションのフロント・パネルを購入するよりも若干安上がりだったのでDEFINE R6 USB-Cにした。こうして予算が徐々にオーバーしていくのである。

DEFINE R6は光学ドライブを搭載できる点でも貴重。オールインワン型水冷CPUクーラーの流行で、内部に場所をとり、ラジエータと干渉しやすい5.25インチ・オープン・ベイが嫌われ、最初から搭載していないPCケースが増えた。

USBで外付けするDVD/Blu-rayドライブが省電力化され、バスパワーでも駆動できるなど電源の心配がなくなったこともあり、5.25インチ・ベイを1基でも搭載しているPCケースのほうが珍しくなってしまった。実際、ほとんどのソフトウェアはダウンロード販売で、OSでさえUSBメモリからインストールするようになってしまったので、光学ドライブの出番は急激に減った。

サイドパネルが透明の、いわゆる「魅せるPC用ケース」はデザインが奇抜なものが多く、日本人の感覚や住宅事情に馴染まないために人気のケースというのは少ないんだけど、その数少ない中でFractal DesignのDEFINEシリーズは人気がある。シリーズ一貫してフロント・パネルが垂直、平面で潔く、奇抜な見た目よりも機能美を重視した主張しない設計が人気の理由のようだ。

Fractal Design Define R6 TG Blackout USB3.1 Gen2 USB-C ミドルタワー型PCケース CS7407 FD-CA-DEF-R6C-BKO-TGL

posted with amazlet at 19.08.10

参考価格: ¥ 17,933 (2019-08-10)

Fractal Design (2018-10-26)

Amazon.co.jpで詳細を見る

最終構成

当初は旧PCの性能底上げのためのリフレッシュ程度の軽微な改修の予定だったけど、CPUをi7-9700Kに切り換えたために、結局ハイスペックを追求した構成になってしまった。総額13万円ほどで予算をかなりオーバーした。もっとも、これだけのスペックを持ったPCをBTOなどで購入しようとしたら13万円ではとても買えないので、相対的なコストパフォーマンスはいいほうだと思う。

BTOパソコン・ショップでどれだけパーツの選択肢を増やしていたとしても、自分で吟味して選ぶ自由度の高さには敵わない。もちろん、相性問題といったリスクもあるけれど、それをも楽しむのがPC自作の醍醐味というものだ。

新構成一覧
項目	メーカー	品名	仕様	備考
マザーボード	ASRock	Z390 Extreme4	Z390チップセット Intel I219V GbE Realtek ALC1220 NCT6791D
CPU	Intel	Core i7-9700K	SRELT (P0)
CPUクーラー	Scythe	Mugen 5 TUF SCMG-5100TUF	無限五 Rev.B RGB LED仕様
メモリ	G.SKILL	Trident Z RGB F4-3600C19Q-32GTZRB	DDR4-3600 UDIMM 19-20-20-40 SK Hynix C-die (18 nm)
グラフィックス	Intel	Intel UHD Graphics 630	DisplayPort×1 HDMI×1 VGA×1
SSD	crucial	BX200 CT240BX200SSD1	2.5″ 240GB SATA3	旧PCから移設
HDD1	Western Digital	WD5000AAKS	500GB SATA2 7,200rpm	旧PCから移設
HDD2	HGST	HDT725025VLA380	250GB SATA 3Gbps 7,200rpm	旧PCから移設
光学ドライブ	LG	HL-DT-ST GH24NS50	SATA DVDスーパーマルチ	旧PCから移設
電源	HEC	HEC-500TE-2WX	500W 80PLUS Standard ATX Ver.2.3 EPS Ver.2.92	旧PCから移設
PCケース	Fractal Design	DEFINE R6 USB-C BKO TG

性能

例によってLightWave2015でレンダリング時間を計測した。無限五の冷却性能に期待して、長期間電力制限を200Wに設定してコアクロックが4.6GHzで張り付くように設定してみたところ、サーマル・スロットリングも発生することなく、70℃台で完走した。

ハイパー・スレッディングはないものの、物理8コアの性能をいかんなく発揮していて、旧PCでは11分25秒かかっていたものが2分28秒で終わった。なんと、i9-9900Kを搭載したマウスのBTOパソコンの2分12秒にあと16秒まで迫る性能を示した。

**LightWave 2015**
CPU	総レンダリング時間	ラジオシティ時間	パフォーマンス	備考
Core i7-860	685.2秒（11分25秒）	91.2秒（1分31秒）	1.00倍	DDR3-1333
Core i9-9900K	132.4秒（2分12秒）	21.7秒	5.17倍	DDR4-2666
Core i7-9700K	148.9秒（2分28秒）	21.9秒	4.60倍	DDR4-3600

i9-9900Kは定格95Wで計測したもので、コアクロックは4.2GHzまでしか上がらなかった。マウスのBTOパソコンはCPUクーラーが非力で、コアクロックが4.7GHzになるように設定するとあっという間に90℃を超えてしまい、サーマル・スロットリングが働いてしまうので本来の性能を発揮できていないことが予想される。

BTOパソコンはパーツ交換を前提としていないので、CPUクーラーひとつ交換するにもマザーボードを取り外さなければならなかったり、分解するのは少々面倒だけど、CPUクーラーを風魔弐あたりに換装しようと心に誓った。

LightWaveでメカの多重関節を作る

最終更新：2019/05/09

以前はメカの関節についてはモデラーの中心点移動ツールを使って中心点を関節の駆動部分に指定することで実現していた。今でもこの方法は有効だけど、すべてのパーツを別のレイヤーかオブジェクトとしてあらかじめ分割しておく必要があった。

この方法は、煩雑な設定が不要で簡便なのが長所で、簡単なモデルの場合はいいんだけど、人型ロボットのように見栄えがするようにスタイリングやポージングを懲りたい場合はバランスの調整が難しいという欠点があった。現在はメカにもボーンを組み込んでウェイト・マップを使って関節を動かすのが主流になりつつあるので、単純に今風な方法でないとも言える。

LightWaveでのメカの多関節化についてはノウハウがあまり貯まっていなかったので、人型ロボットのような本格的なメカに取り組む前に数本程度のボーンで構成される簡単な多関節モデルで試してみることにした。

モデラー

今回は、次の画像のようなモデルを用意した。すべての部分が1レイヤー上に配置されている。このうち盾のような部分を三軸で回転させられる可動モデルとしたい。

難しいことはやってないので作り方は省略するけど、5ポイント以上のポリゴンがあるとボーンの旋回に綺麗に追随してくれないことがあり、悪くするとレンダリングした時に無視できないくらいの誤差が生じ、共有しているはずのエッジが分離してしまう不具合を起こすので、極力4ポイント以下のポリゴンに整理しておく。

スケルゴンの構成

モデルには次の画像のような構造の5本のスケルゴンを組み込んである。実際の動作に必要なスケルゴンはCenter、Arm及びShieldのみ。Rootは母機であるパワーユニットを固定するために存在する。Null_BoneはCenterスケルゴンとArmスケルゴンの回転軸のほんのわずかなズレを補うためにあり、動作には直接関係ない。繰り返しになるけど、Rootスケルゴンを最初に作る時だけドラッグで引き切らないと長さがゼロのスケルゴンができてしまうので注意。

モデルの座標情報を参照してスケルゴンの位置を回転の中心軸に可能な限り精密に合わせておく。中心軸になりそうなところにポイントができるように平均統合（Weld Average）ツールなどを利用すると座標を取得しやすい。

Shieldスケルゴンを最終的にはバンク（スケルゴンのヘッドからテイル方向を軸とする回転）で制御したい関係上、他のスケルゴンもすべてバンクで制御することになってしまった。ロボットの腕や脚などを作りたい場合はジンバルロックを避けるためにも極力ピッチで制御するのが常套手段ではある。

画像を示す必要があるかどうかは微妙だけど、スケルゴンツリーは次の画像のとおり。左右の区別の必要があるかもしれないと思って接尾辞に「_L」を付けてあるけど、同じレイヤー上に左右のスケルゴンを置かない場合は必要なかった（上の画像では接尾辞を省略している）。表示上、Null_Boneのウェイト・マップ名も出ているけど、実際のマップは作成していない。

バンクハンドルの設定

これは後でもいいんだけど、レイアウトに移した時にボーンのバンク角に中途半端な値が入ってしまって操作しづらくなることがあるので、スケルゴン回転（Rotate Skelegons）でバンクハンドル（Bank Handle/Pitch Plane）をキリの良い値に設定しておく。3つの値のうち、いずれかひとつを1.000にすればいいんだけど、今回のようにスケルゴンが三次元的に直角に連なっている場合はどっちが前か後ろかはっきりしないので、どこをその値にすればいいのかはスケルゴンにより異なり、これといった決まりがない。レイアウトに移してみないとどうなるかわからないのが実際のところで、こういったところがLightWaveのわかりにくいところ。

スケルゴン編集（Edit Skelegons）でも同様のことはできるけど、数値入力ウィンドウがなく、どうしても誤差が入るので、スケルゴン編集で視覚的に大体整えたらスケルゴン回転で一番大きい値を1.000にするのが一番確実。

ウェイト・マップの作成

各所のウェイト・マップを作成する。ウェイト・マップ名はレイアウトでの作業を簡略化するために、スケルゴンと同じ名前にしておく。メカは基本的に100%か0%かの2値しかないので、MAP値指定（Set Map Value）で割り当てていく。

次の画像は、前後（垂直）方向へ回転させるためのCenterスケルゴンに対応する部分をウェイトシェイドで表示したもの。

同じく、左右（水平）方向へ回転させるためのArmスケルゴンに対応する部分。なお、Centerスケルゴンに対応する部分とはポイントを共有しないように一度分割しておかないと、スケルゴンを回転させた時にねじれてしまう。

最後に、盾の部分をひねり方向へ回転させるためのShieldスケルゴンに対応する部分。

残りの部分にはウェイト・マップを設定しなくても特に問題ないけど、気になるようならRootスケルゴンに対応するウェイト・マップに設定しておくとよい。

スケルゴン回転でチェック

次に、スケルゴン回転（Rotate Skelegons）でうまくスケルゴンとウェイト・マップが連動しているかをテストする。関節になるはずの部分がつながっていたりするようなモデリングのミスに気付くこともある。ここでは、バンク角のみを使用する。

ちなみに、スケルゴン回転でチェックできるのは、ウェイト・マップによる変形のみで、レイアウトにおけるボーンからの距離のフォールオフによる変形の影響をチェックすることはできない。

次の画像は、Centerスケルゴンを指定しての垂直方向の回転のチェック（入力はバンク）。Centerスケルゴンの子スケルゴン以下のすべてのスケルゴンが旋回に追従しているのがわかる。

一度スケルゴンの回転をリセットしてから、Armスケルゴンの水平方向の回転チェック（同じく入力はバンク）。次の画像のように、水平方向にのみ旋回している。

次の画像は、Shieldスケルゴンのひねり方向の回転チェック。同スケルゴンはアームの蝶つがい部分を中心に引いてあるので盾の部分は180°で裏表が反転するように動く。

レイアウト

モデラーで問題ないようであれば、レイアウトに移る。モデルをアイテムの追加で呼び出し、スケルゴン変換かSkelegon Readerプラグインでボーンを組み込む。スケルゴン・エディタを使わなかった場合は、どちらでもほぼ同じ結果になると思う。Skelegon Readerは、スケルゴン・エディタでのバンクの整列などが反映されるけど、スケルゴン変換は反映されないという違いがある。

そのままの状態で、各所のボーンを旋回させると次の画像のようにモデルが大きく歪む。特に、Centerボーンを旋回させた時の歪み具合がひどいけど、場所によってはボーンからモデルが離れてしまっている。ワイヤーフレームで表示させてみると、細かいところであちこち歪んでいるのが確認できる。

これは、ウェイト・マップ以外にもボーンからの距離のフォールオフで変形してしまっているのが原因。オブジェクトの頂点は、接続している一連のボーンによる変形にも影響を受けるので、更に歪みがひどくなる。ウェイト・マップとフォールオフの併用は、モデラーとレイアウトが独立していて二者間を行ったり来たりしなければならないという難点を克服しようと試みたものであり、生物系モデルのアニメーションの場合などはワークフローを改善する。ウェイトの設定が多少雑でもなんとかなるLightWaveの特徴でもあるんだけど、メカの場合はかえって邪魔になる。

そこで、Root、Center、Arm及びShieldの各ボーンのプロパティを次の画像のように変更する。「ウェイトのみ使用（Use Weight Map Only）」にチェックを入れるとボーンのフォールオフの影響をまったく受けなくなる。ただし、無効にも関わらずフォールオフ種はグレーアウトされないので、非常に紛らわしい。

「ウェイト正規化（Weight Normalization）」はデフォルトでチェックが入っているけど、ひとつの頂点のウェイトの合計値が100%を超えないようにするためのもので、今回は100%と0%以外は使っていないので、チェックを入れても外しても変化はない。「固定長の強さで乗算（Multiply Strength by Rest Length）」のチェックは外しておく。

ちなみに、「高速ボーン（Faster Bones）」は影響を受けるボーンを近いものから4本までに限定するもの。ボーンが多くて変形に時間がかかりすぎる場合に使うもので、ここではあまり関係ない。

Null_Boneについては、次の画像のように「ボーン有効（Bone Active）」のチェックを外してボーンそのものを無効にしておく。有効なままにしておくと、モデラーのスケルゴン回転では想定していなかった変形を生じたり、ウェイト・マップを割り当てていない部分全体が回転してしまったり何かしらの影響を与えてしまうことがある。

ボーンの設定が終わると、初期状態で生じていた歪みは解消され、モデラーのスケルゴン回転でチェックしたとおりの旋回を行えるようになる。旋回角度が大きければ大きいほど歪みがひどくなる傾向にあるので、少し回転させて問題ないようなら、デザイン上の制限はともかく180°くらいまで一気に回転させてテストしてみる。これで歪みが解消されているかどうか最終確認ができる。

なお、Shieldボーンが二重になっているように見えるのは、盾を内側と外側に分割して個別に動くように後で改善したため。

完成

以上の方法で多重関節化したモデルが次の画像。大きく前に旋回させても歪みは生じていない。これでLightWaveでも1レイヤー上にデザインした多関節メカのモデルをボーンとウェイト・マップで動かすことができるようになった。

参考記事

補足： LightWave 3D ～ Bone 設定に関して（デザイナーの視点で見た 3DCGのススメ）

LightWaveで二次元キャラ系人物モデリング奮闘記 ―視線コントロール編―

最終更新：2017/01/13

視線コントロールには、一般には目の中心軸の延長線上に視線用ターゲット・オブジェクトを配置し、両目からそれを参照させてIKを用いて視線をコントロールする。IKを使いたい場合は目を球状のオブジェクトとしてモデリングする必要があり、扁平な顔が基本の二次元イラストやアニメ調の作風にはなかなか合わせにくい傾向がある。劇画調を目指している場合を除き、IKを使いたいがために眼球がちゃんとはまるようにするには、顔のモデリングに必要な工夫の労力が釣り合わないことが多い。

そこで、瞳の動きにはモーフを使いながら、擬似的にIKのような視線コントロールを実現する方法を考える。

瞳の後退モーフによるカメラ目線

カメラ目線を実現するには、MMDなどでよく使われている方法を使う。MMD方式のカメラ目線は簡単に言うと、目の位置を後退させて、三次元的に瞳の中心をずらすことによって擬似的にカメラ目線になっているように見せる。

これまでは白目を自己発光させて陰影が出ないように設定していたけど、まぶたに白目が透けてしまったりする問題があったため、自己発光度を0%に変更し、拡散レベルを400%という非常に大きい値にすることで陰影を極力落とす。

目を後退させると、眼窩の内側が見えてしまうので、内側を白に染めて目の後退がわかりにくいような仕組みを作る。内側を自己発光度の設定してある白に染めてしまうと、目を閉じても内側が透けて見えてしまう。上のサーフェース設定はその対策でもある。

逆に、瞳の中心は目を後退させることでライトの光線が届かなくなり、徐々に暗くなっていってしまうので、自己発光度を「40%」に設定する。拡散レベルは「60%」に設定し、自己発光度と拡散レベルの合計が100%になるように設定すると、自己発光度を設定していなかった場合と色合いがあまり変わらないようにできる。

目の後退によるカメラ目線の例が次の画像。白目と眼窩の内側の境界がわからないようにunReal Xtreme2のToon Tracerピクセルフィルター・プラグインの設定を変更しておく。

上の画像だけではカメラ目線になっているかどうかが少しわかりにくいので、俯瞰構図と仰視構図も示しておく。いずれもモーフ量は同じで、瞳の位置を後ろに下げただけ。カメラの位置を上下に動かしても瞳はカメラの方を向いているように見える。

エクスプレッションによる視線コントロール

眼を独立した球状オブジェクトとして作成しなかったので、視線の制御にIKを使えない。二次元キャラクターの目を球体として作成しようとする場合に発生しうる問題は以前にも述べたとおりで、瞳は水平、垂直の二軸のみで動くようにデザインしている。

モーフを使っている場合でも、グラフ編集に用意されていている「Channel Follower」モディファイヤを使用すれば、ターゲット・オブジェクトの特定のチャンネルの値の変動にモーフを連動させる簡易的な視線コントロールはできる。ただ、ターゲットの距離などを考慮して左右のモーフ量を個別に制御できないので、両目をひとつのターゲットで制御するのは容易くない。

ただし、Channel Followerをモーフのグラフ（エンベロープ）に適用する場合に限り、X、Y、Zの座標系チャンネルだけにしか追随させられない。H、P、Bの回転系チャンネルに追随させようとしても不可解な値が返されてしまい（特定のチャンネルだけまともな数値が出ることもあるけど、ほとんどの場合、0に限りなく近い極小の値になる）、サインカーブのような動きをさせることはできない。モーフは線形補間なので、ある意味当たり前と言えば当たり前なんだけど、Channel Followerで連動する要素に回転系のチャンネルを指定してもエラーも警告も出ないので、設定か計算の間違いだと勘違いしやすい。

そうかと言って、どこか一点を注視するような視線をモーフのスライダーだけで実現するのは楽ではない。アニメーションさせることを考えに入れたりすると、キーフレームごとにモーフ量を計算するか、その都度目分量で調整しなければならず、かなり労力がかかりそうなことは想像に難くない。

そこで、注視している場所を大雑把に指示するターゲット・オブジェクトを用意して、モーフ適用量を計算させる。視線コントロールの基本的な考え方は次の図のとおり。IKでも考え方そのものは同じ。

この図から、目の正面方向と注視点に対する方向がなす角度 $\theta$ についてのタンジェントは次のとおりに求められる。

$\begin{align*} \tan \theta&=\frac{X_{sight} - X_{eye}}{Z_{sight} - Z_{eye}} \end{align*}$

タンジェントの逆関数インバース・タンジェント（又はアークタンジェント）を用いて $\theta$ を求める。

$\begin{align*} \theta &= \tan^{-1} \frac{X_{sight} - X_{eye}}{Z_{sight} - Z_{eye}} \end{align*}$

これをLightWaveで受け付けられるエクスプレッションに置き換える。プログラミング言語ではインバース・タンジェント（アークタンジェント）を「atan」などと記述することが多い。次の式は左目のエクスプレッションの例。名称は左右の区別がつきやすく、わかりやすければなんでもいい。

式の出力はラジアンではなく、関数電卓などで「DEG」と表される円周360°の角度なので、 $0^\circ \leq \theta \leq 90^\circ$ の範囲の値をとる。必要であれば、これに定数を掛けて調整する。

atan(([Null_EyeSight.Position.X] - [Null_Eye_L.Position.X]) / ([Null_Eye_L.Position.Z] - [Null_EyeSight.Position.Z]))

エクスプレッションと、グラフで表されるチャンネルはそれぞれ独立していて、一義に定まる名称で識別されるエクスプレッションを複数のチャンネルに割り当てられるようになっている。そのため、最初は左目用のエクスプレッションを右目のチャンネルにも割り当ててしまったり、重複したエクスプレッションの除去に手間取ったり、インターフェースにとっつきにくさを感じるかもしれない。

同じく次の式は右目のエクスプレッションの例。右目のX座標は左目の正負反転なので、参照するチャンネルが異なるだけで式はほぼ同じ。両目とも瞳を顔の外側に動かすほうをモーフ量のプラスにしている場合は、全体をマイナスで正負を反転する。

atan(([Null_EyeSight.Position.X] - [Null_Eye_R.Position.X]) / ([Null_Eye_R.Position.Z] - [Null_EyeSight.Position.Z]))

それぞれの目のモーフにエクスプレッションを適用（アタッチ）し、両目のグラフを同時に表示させると次の画像のようになる。注視ターゲット・オブジェクトは $-1m \leq X_{sight} \leq 1m$ の範囲で行ったり来たりさせているだけ。Z軸座標は目から約1m先に固定で、注視距離によって必要があれば移動させる。 $Z_{sight}$ を移動させるとグラフの振幅が変動する。

ターゲット・オブジェクトを注視させた場合と、スライダーで視線を手動設定した場合の比較。ターゲット・オブジェクトとは言うものの、上の式では精密に注視させることはできないので、あくまでも擬似的な制御。IKではないのでモーフ量と視線の角度を完全に同期させるにはエクスプレッションを更に作り込む必要がある。

morph038 — 両目ともモーフ適用量「100%」。視線は交わらずに平行になっている。

morph037 — エクスプレッションで視線コントロールをしたもの。左目のモーフ量は「88.78%」、右目は「66.20%」。

今回は水平方向のモーフしか使っていないけど、同様に上下方向のモーフを作っておけば、理屈はまったく同じで瞳の上下運動も可能。

LightWaveで二次元キャラ系人物モデリング奮闘記 ―表情モーフ編―

最終更新：2016/10/14

モーフィングも昔は高度な技術のひとつだったけど、今では安価な3DCGソフトウェアでも比較的手軽に利用できるようになった。

LightWaveでは、サブパッチやキャトマルといったリアルタイムに編集可能なサブディビジョン技術を備えたことによって、モデル全体のポリゴンを実際に細分化して固定させなくてもローポリゴンのまま、ハイポリゴン状態のモーフィングを実現できるようになった。また、それがモーフであるかどうかをあまり意識しないでモーフ・マップを作成及び編集できる機能を備えている。

ただ、勘違いされがちなんだけど、モーフィングは線形補間なので、ベース・モデルからモーフターゲット（LightWaveでは「エンドモーフ（Endomorph）」と呼んでいる）までは直線的に変形され、何らかの曲線を経由させるような変形や、捻りといった回転系の変形は難しい。よって、関節の旋回を伴う指などに使うことは稀なんだけど、デザイン上、指が少なかったり関節があってもないと見なせるようなデフォルメ風キャラクターなどの場合はボーンを節約してリグを簡略化したい場合は指にモーフを使うこともある。普通は顔の各所の表情や、息を吸ったり吐いたりすることによって胸や腹が規則的に膨らんだり縮んだりするモーションに用いられるのが一般的。

目を閉じるモーフの作成

「マップ」メニューグループにある新規モーフ（New Endomorph）で新しいモーフ・マップを作成する。モーフ・マップ名には、ファイル名やサーフェース名と同様に日本語全角文字（マルチバイト文字）を避けて命名する。

また、マップ名をピリオドで区切ることでモーフ・マップをグループ化することができる。グループ数にはメモリの許す限り特に上限がないので、左右を別々に管理したり、顔のパーツごとではなく「笑い」「怒り」「泣き」など表情ごとに一括管理したければそのようにすることも可能。

ここでは、左右の区別なく、目に関するモーフをすべて「EYE」グループに分類する。左右を区別する時はボーンのように「_L」や「_R」といった接尾辞をつけることで管理する。

モーフ・マップの種別を「相対」に設定し、「作成」ボタンを押す。なお、モデラーウィンドウの右下に並んでいるボタンから「M」を選択して「（新規）」を選択しても同じ結果になる。ちなみに、「絶対」モーフ・マップというのはベース・モデルの形状に関係なく固定の形状にモーフィングするために使うものだけど、キネマティック・アートやモーション・グラフィックスのようなケースを除くとそんなに使う機会はないかもしれない。

モーフ・マップを作成すると、同時にモーフ・マップ編集モードに移される。LightWave 11から表示が改善され、HUD（ヘッド・アップ・ディスプレイ）が表示されるようになった。すべてのビューの左上に編集中のモーフ・マップ名とその種別、現在編集中を意味するビューを囲む枠が表示されるようになったため、誤ってベースや意図しないモーフを編集してしまうといったミスを未然に防止できる。

表情に関係ない部分をすべて隠し（Shift+-：「=」キー）、左目が閉じるようにポイントをひたすら調整する。ちょっと顔側のパッチの数が足りなくてまぶたが伸びきってしまったけど、まだなんとかなるレベル。ここでいったんオブジェクトを保存する。

今度は右目のモーフを作る。左目のモーフを先に作ってしまってから左右対称になるようにモデリングするのは困難だし、そうかと言って両目を対称モードで一度にモデリングしてしまうとウィンクができなくなってしまうので、左目のモーフを複製して作成する。まずは、頂点マップのコピー（Copy Vertex Map）で左目のモーフを単純に複製して「EYE.CLOSE_R」モーフ・マップを作成する。

このままだと両方のモーフ・マップが左目を閉じるモーフになってしまうので、「EYE.CLOSE_R」モーフ・マップ上の左目のモーフを右目側に反転して複製する。

「ユーティリティ」メニューグループからMMorphプラグインを選択する。「Keep Original Map Value」にチェックを入れると、元になったモーフをそのまま残して複製する。身近なところで言い換えると「コピー&ペースト」に似たような動作になる。チェックを外すと、元のモーフを残さない「カット&ペースト」と似たような動作になる。

反転して複製してみたところ、右目の閉じ方が左目と同じようにならなかった。原因としては、まつ毛の先端の非常に近い距離に6個ほどあるポイント群を結合していなかったために、ポイントにモーフを適用する順番が狂ってしまったことが考えられる。

ポイントの位置そのものは左右対称なのでモーフで問題になるとは想定していなかったんだけど、解決策はある。とりあえず、左右ともまつ毛の先端のポイントをひとつに結合してしまう。結合してしまうと先端が尖らなくなるので、先端のポイントをひとつ選択し、「詳細」メニューグループにあるCCシャープネス設定（Set CC Sharpness）を選択する。

値はいくつでもいいけど、結合前と大体同じくらいの尖鋭度になるように「80%」とした。ここで設定したシャープネス値は「エッジ・ウェイト」とも呼ばれるけど、必ずしもエッジを選択しないと設定できないわけではない。LightWaveに限ったことではないけど、マップ類はすべてポイントで管理されているので、エッジ単位でなければエッジ・ウェイトを設定できないなんてことはない、というのは勘の良い人ならすぐ気付くはず。

再度、左目を閉じるモーフを右目に反転複製する。今度は次の画像のとおり左右対称になった。両目ができたらオブジェクト・ファイルを保存する。

レイアウトに移り、アイテムプロパティウィンドウの「変形タブ」を選択し、変位プラグイン追加から「Morph Mixer」を選択する。オブジェクト・ファイルをちゃんと保存していれば、自動的にエンドモーフ（モーフ・マップ）が読み込まれ、レイアウト内のオブジェクトにも反映される。以後、オブジェクト・ファイルを更新する度に自動的にモーフ・マップの増減と変更が反映されるようになるけど、たまにクラッシュするので適宜シーン・ファイルも保存しておく。

モーフミキサーのプロパティを選択すると、次の画像のような設定パネルが表示される。グループ化した部位が階層化されて表示される。

パネル左下の「オプション」を選択すると「スライダー範囲を設定」を選択できる。

モデラーでのモーフ・マップは適用量「100%」の状態を編集しているわけだけど、レイアウトでは適用量を任意の範囲に拡大又は制限できる。極端な話、「1000%」や「-300%」なんていう指定も可能なんだけど、アニメーションとして動かしてみたら思っていたより変位量が足りなかったとか、海外アニメのカートゥーンのようにもっと大袈裟にしたいといったケースに対応するためのもので、動きの範囲が限られている人間の表情モーフを作る上では使う機会はほぼないと言って良い。最低値を「0」にしておいてもいい。

両目のモーフ適用量を100%にしてテスト・レンダリングしてみたところ、まぶたの裏にあるはずの目が見えてしまい、寝ている人にマジックで目を落書きされてしまったみたいになってしまった。理由は明快で、SSSの深度を100mmとありえないくらいの値にしているために、皮膚の表皮にあたる半透明部分が想定よりも深くなっていて、目が透けて見えている。

SSSの設定を見直すのが一番いいんだけど、一応悪あがきとして目の位置をモーフ・マップを利用して頭の中まで後退させるという方法を使ってみた。次の画像のように、まぶたに目は映らなくはなったんだけど、眼窩にぽっかりと穴が開いているのは変わらないため、結局眼窩の影がまぶたに映り込んでしまうという結果になった。

遠景なのであまり目立たないけど、顔をアップにすると細かいところに問題が起きているので、いずれにせよSSSの設定は近いうちに見直さなければならなかった。

ひとまず、Epidermis DistanceとSubdermis Distanceを「10mm」に修正した。

SSSを修正してレンダリングしたのが次の画像。影の境界線がやや鋭くなって肌がマットな感じになってしまったけど、モーフで問題が起きるのを回避するにはこのくらいにする必要がある。また、影が鋭くなってしまう問題についてはライティングの方向を見直すことで少し改善できる。

口を閉じるモーフの作成

同様にして、口を閉じる「MOUTH.CLOSE」モーフ・マップを作成していく。まぶたは筋肉と皮膚だけでできていて骨は入っていないので顔の輪郭には影響しないんだけど、口の場合は開閉によって顎の骨が動くため、顔の輪郭にも影響が出る。

最初は強引に下唇を引き上げて口を閉じようとしてみたけど、全体的に位置が高く、不自然になってしまった。

そこで、口を全体的に下げてみた。多少は顔のパーツの配置のバランスは改善したけど、顎が長く面長に見えるのはあまり改善しなかった。二次元アニメでは口と顎が必ずしも連動しているわけではないので、輪郭をいじらないようにモデリングする方法もないことはないけど、口が開いている状態を先にモデリングしてしまったので輪郭をいじらないほうが無理がきてしまった。

更に、口が完全に閉じるまでモーフ・マップを調整し、下顎を少し上げて顔の輪郭を整えた。しかし、今度は口が完全に閉じてしまったことでどこに口があるのか判りにくくなってしまった。

口が開いている状態を基準にしていたスケッチ色の配置を見直し、上唇と下唇を色分けする。その際、異なるスケッチ色が隣り合わないように注意する。スケッチ色が隣り合っていると想定外のところに境界線が引かれてしまう原因になる。

スケッチ色の再塗り分けが終わったら、次の画像のようにモーフ・マップで口を閉じてみて、唇の上下のスケッチ色が隣り合っていることを確認する。

再びレイアウトに戻り、unReal Xtreme2のToon Tracerピクセルフィルター・プラグインのパラメータを調整する。口を閉じている状態を基準にスケッチ色を塗り分けたので、今度は口が開いていると輪郭線が引かれなくなる。そこで、境界設定で「深度境界」を追加し、「深度しきい値」をひとまず「50mm」とした。

「MOUTH.CLOSE」モーフ・マップの適用量100%でレンダリングしてみたのが次の画像。口が閉じていても輪郭線が引かれているのがわかる。口の位置が判りやすくなった。

次の画像は「MOUTH.CLOSE」モーフ・マップの適用量90%のもの。輪郭線は引かれなくなるものの、口の中の影が赤く見えるようになるので、口が行方不明になったりはしない。

次の画像は「MOUTH.CLOSE」モーフ・マップの適用量50%のもの。

次の画像は「MOUTH.CLOSE」モーフ・マップの適用量0%、つまりベース・モデルのもの。これまでは口の向かって右側に輪郭線が引かれていたけど、深度境界を指定したことによって向かって左側に輪郭線が引かれるようになっている。若干口元の印象が変わった気もしないでもないけれど、特に不自然なところはないので、Toon Tracerの設定はこれで仮決めとする。

表情集

LightWaveで二次元キャラ系人物モデリング奮闘記 ―プリーツスカート編―

最終更新：2017/01/13

今回はプリーツスカートがテーマ。なんとなくそれらしい形のものを作るのは簡単なので、学生の制服やアイドルユニットのお揃いの衣装などでお馴染みのチェック柄のスカートを作る。チェック柄なんて珍しくもないけど、チェック柄を甘く見てはいけない。

3DCG隆盛の昨今でも、チェック柄のスカートを身にまとった美少女キャラクターの3Dモデルというのは驚くほど見かけない。まず考えられる理由としては、UVマップに格子状に展開したチェック柄を歪ませないように維持したままスカートをモデリングするのが難しいからというのが挙げられる。単純に裾を広く、ウェストを細くすると上に行くほど柄が細くなってしまい、不自然になってしまう。

仮に、モデルを単純化してテクスチャの描き方を工夫するにしても、放射状に広がる裾に合わせてチェック柄を描くのは、柄の連続性をどうやって担保するのかといった問題も含め、控えめに言っても労力がかかる。立体化を前提、想定、又は期待してキャラクターデザインをする場合、チェック柄のスカートは全般的に避けられる傾向にある。現実世界では街に出ればチェック柄のスカートばかりが目立つのに、二次元世界では学園物の作品でも制服のプリーツスカートにチェック柄を採用している学校のほうが珍しい。もっとも、立体化の前にアニメ化やコミカライズといった二次元化があり、単純に描くのが面倒という現実的な問題もある。

また、プリーツスカートの縫製の特殊性にも理由がある。縫い目を切り離して展開してみると、大抵の人が想像するような扇形や台形の生地ではなく、実は長方形の布1枚でできている。それを末広がりの独特のラインに仕立てるために、「曲線折り」という特殊な折り方を採用している。ウェストが細くなるようにまっすぐに折るといずれチェック柄が斜めに傾いていってしまうのを避けられない。

本物の布や折り紙であれば基本的に伸び縮みはないので、順序よく折り目をつけていけば自然にプリーツスカートの形になっていくんだけど、3Dモデリングの場合、ポイントを移動させるとエッジがいくらでも伸縮してしまう特性があるため、エッジの長さを固定したまま折り畳むという操作がそもそも難しい。

そのプリーツスカートを現実のものとほぼ同様の発想でモデリングすることにあえて挑戦する。挑戦しないのであれば、わざわざ記事にする必要はない。例によって拡張プラスと移動ツールでモデリングしていく方法を今更紹介されても「またその組み合わせ？」と言われかねない。

基礎を作る

それでも、3DCGソフトウェアの制限には逆らえないので、まずはセオリーどおり円筒から作る。ディスク（Disc）ツールで原点に直径1m、高さ1mの標準的な大きさの筒を作る。これからややこしい計算をすることになるので、初期座標くらいは単純にしておきたい。

ひだの数があまり多いと作業が大変だし、逆に少なすぎるとプリーツスカートとは呼べなくなるので、15個とした。折り返し分を計算に入れて30面の円筒を作る。15という数字は、1周分の360°を割り切れるから。ついでに言うと、UVは幅が100%（LightWaveの内部では1.0 = 1m = 100%は等価）なので、100と360の公約数だと更に計算しやすい。とは言うものの、100と360の公約数は1、2、4、5、10、20の6つしかなく、実質10か20しか選択肢がない。

上面と底面は必要ないので、削除する。大抵要らなくなるので、「上面と底面をふさがない」というオプションがあれば便利なんだけど、些細なことなので文句を言っていても始まらない。

サーフェースがデフォルトのままだと何かと不便なので、次の画像のように「Skirt_Check」というサーフェースを割り当てておく。

とりあえず、スムージングはかけないでおく。

早々にUVマップを作成する。極めて単純な形状のオブジェクトなので、標準機能の新規UVテクスチャ（New UV Map）ツールで円柱状に展開する。今回の目標はUVマップを基準にしてモデリングのほうを工夫することなので、手芸店などで計り売りされている1枚布のようなマップが必要。

なお、プリーツの数が4で割り切れるのであれば、4分の1だけモデリングしてあとは90°ずつ回転させて複製し、境界線をつなぎ合わせればモデリングの労力をほぼ4分の1にできる。ただ、その場合のUVは4箇所とも同じ位置に重複してマッピングされることになるので、UVの扱いに慣れていて混乱しない自信があれば試してみてもいいかもしれない。それから、モデリングを済ませてしまってからUVを展開してももちろんいいんだけど、plg_Make_UV_Editなどによる自動展開は多少なりとも歪むので、UVの調整にそれなりに時間を要する。プリーツを折り畳んでしまってからLightWaveの標準機能によるUV展開は使えないと思っていい。

次の画像のような簾状のマップを作る。

更に、作成したUVにチェック柄のテクスチャを割り当てる。モデリングの説明が思いのほか長くなりそうなので、チェック柄のテクスチャの作り方はまた今度説明する。Adobe Photoshopのスマートオブジェクトはチェック柄の変更や修正に柔軟に対応できて便利なので一番おすすめではあるんだけど、レイヤーが扱えて標準的なレイヤーモードを備えている画像編集ソフトウェアであれば簡単に作れる。

次の画像の状態が基準になる。以後、この模様が歪まないように工夫を凝らしていく。

すべての面の幅が一定ではプリーツスカートにならないので、折り返す部分を短くする。次の画像のようにUVマップのビューでひとつおきにポイントを選択する。三面図の上面からのビューで選択しても同じだけど、チェック柄の連続性を維持するためにはマップの左右端にあたるポイントは間違っても動かせないので、UVマップ内で選択したほうが結果的には手早く済む。

スカートのデザインにもよるんだけど、ひだの表側に見えている部分と折り返し部分の比率は4:1にすることにした。ひだの数は15個で、現在5:5になっている比率を8:2にしたいので、 $100 \div 15 \times 0.3 = 2 \, [\%]$ だけUVのU成分をずらす。UV値の変換（Transform UV）ツールで次の画像のとおりに入力する。

「OK」ボタンを押すと、次の画像のようにUVマップが変換される。

UVマップを変換しただけなので、三次元空間の筒の形状には変化がないけど、チェック柄が歪んでいるのが確認できる。

ポイントの選択を解除しないようにして、今度は三次元空間のポイントを $360 \div 15 \times 0.3 = 7.2 \, [^\circ]$ だけ回転させる。正負の方向はUVの歪みを見て判断する。

正しい方向に回転させられれば、テクスチャの見た目上は最初の状態に戻る。これでプリーツスカートを作る準備ができた。チェック柄のパターンは15×15なので縦方向が圧縮されて縦横比が一致していないけど、この段階では横方向の模様が歪んでいなければいい。

アポロニウスの円

ここからが本題。ひとつのひだを4:1に分割したまでは良かったんだけど、その比率を維持しながら折り返すのが結構難しい。比率さえ維持できていればUVを歪ませずに済むので、この際長さは変わってしまってもいい。

ここで久しぶりに数学らしい数学を利用する。

2つの点 $A$ と $B$ からの距離の比が $m:n\; (m \neq n)$ で一定である点 $P$ が描く軌跡を求めたい。結論から先に言うと、その軌跡 $P$ は円になるんだけど、その円の中心点を $C$ とする。各点はXとYの成分を持っているので、それぞれ $A(\alpha), B(\beta), C(\gamma)$ とする。

$C$ 点の座標 $\gamma$ は、次の式で求める。要は、X座標とY座標をそれぞれ別に同じ式で計算するということ。

$\begin{align*} \gamma=\frac{\displaystyle -n^2\alpha+m^2\beta}{\displaystyle m^2-n^2} \end{align*}$

$C$ 点の座標が求まれば $A$ 点と $B$ 点との距離は三平方の定理で求められるけど、今は試験問題を解いているわけではないので、ポイントの計測（Measure Points）ツールを使って簡単に求める。

線分 $AC$ と $BC$ の距離が求まれば、点 $C$ を中心とする円 $P$ の半径 $r$ は次の式で求められる。

$\begin{align*} r=\sqrt{{AC} \cdot {BC}} \end{align*}$

計算と作図がしやすいように、 $B$ 点が $(X,Z)=(-0.5,0)$ の位置にあるところを選んだ。これらの式から求めた数値をディスクツールの数値入力ウィンドウに入力する。座標を参照するだけなので高さは0でいい。サイドが36なのは言うまでもなく、10°刻みにするため。

計算が合っていれば4:1の折り目で分割しているポイントを通過する円が描けるはず。実際に作図してみると思ったより半径は小さかった。精度としては4.006:1～3.995:1くらいだから誤差±0.16%前後。

このような円をアポロニウスの円と言う。一般的には次の画像のような図で表される。図は $m:n = 3:2$ になっている。 $A$ 点と $B$ 点が水平に一列になっていたほうが理解しやすいのでこのように描くけど、二次元的に斜めにずれていても円の位置と半径は求められる。図を見るとわかるように、比率が一定になるだけで長さまでは一定にならないことに注意。

なんでこのような式になるのかまでは省略。ネットで「アポロニウスの円」を検索すれば高校の先生が詳しく証明してくれているページがたくさんある。つまり、まったく憶えてはいないけど高校の数学で習ったはずで、センター試験にも出題されるポピュラーな平面幾何学の定理。更に発展させた複素数平面を使った解法は2004年（平成16年）を最後に今の高校では教えていないらしいけど、コンピュータの発達した21世紀に生きる私がすぐには思いつかなかった方法を紀元前の数学者が既に考案していたというのだからまったく皮肉なことだ。

ある平面上で線分 $AP$ と $BP$ の比率を一定にしたまま分割点 $P$ を移動させたいという要求はありそうだけど、Adobe Illustratorのようなベクター画像編集ソフトウェアのツールにも意外と備えられていない。少し調べたところでは、Illustratorでもアポロニウスの円を描いてその円の外縁にスナップするようにパスの制御点を移動させるという方法が採られているようだ。

こんな手間のかかる計算までしなくてもいいのでは、と言われそうだけど、アポロニウスの円は平面上にある2点についてしか通用しないものなので、今使わないと使う機会がなくなる。それに、いつも「適当に、感覚で」と繰り返すのでは何の参考にもならない。それほど厳密でなくても良ければ、ひだの角度を直角と仮定して三角関数の正接（ $\tan \theta$ ）が0.25になるおおよその位置を求める方法もある（あくまでも仮定なので、実際に操作すると直角にはならないため、無視できないほどの誤差が出る）。

$A$ 点と $B$ 点の間の分割点を選択し、スナップドラッグ（Snap Drag）ツール（Shift+G）でアポロニウスの円上にある任意の点にスナップさせる。この時、「操作ビューに沿う」にチェックを入れておかないと水平に動いてくれないので注意。

次の画像のように、4:1の比率を維持したまま折り返すことができた。

15個あるひだの数だけアポロニウスの円を作るのはさすがに大変なので、スカート全体を15分の1、つまり24°ずつ回転させて、スナップドラッグを繰り返す。原点を中心にしてアポロニウスの円をスカートの外縁を周回させても同じだけど、円周率が無理数であるために回転は誤差が蓄積しやすいツールなので、変形の基準にするものはできるだけ移動させたくない。

15個のひだを折り返し終わった状態が次の画像。ここでウェスト部分を絞ってしまうと、冒頭でも書いたようにチェック柄が先細りしてしまう。

縦横の模様を合わせる

ここでチェック柄の縦の模様を横の模様に一致させる。ひとつのひだの長さは既にわかっているので、それを15倍すると裾の周囲の長さが求められる。結果、4.4306205mと求まり、スカートの丈の長さは1mなので、裾の周囲に対する割合は $22.5702 \dots \, [\%]$ となる。

上端のポイントを選択し、これをUV値の設定（Set UV Value）ツールでUVのV成分に入力する。

上を下に移動させたほうが計算が楽なのでそうしたけど、下を上に移動させても結果は同じ。

上の画像と見比べてもらえば、チェック柄の縦横比が合っているのがわかると思う。

曲線折りの模擬

次はいよいよ曲線折りを行っていく。まず、ウェストに向かって絞りたい部分を分割する。全体を半分に分割し、上半分をさらに半分に分割する。

この時、必ずバンドソープロ（Band Saw Pro）を使う。まだ単純な形状なのでナイフツールを使ってもいいような気もするし、一見すると似たような動作ではあるけど、ナイフツールはUVを壊してしまうことがある。バンドソープロが優れているところは、どんなに入り組んでいようと、ポリゴンが連続さえしていれば正確に分割できることばかりではなく、UVを破損させることがない点。

次の画像のように3分割した。

分割点をひとつのひだの10%分だけ左にずらしていく。ひとつのひだのUVにおける幅は15分の1、つまり $6.666 \dots \, [\%]$ なので、その10分の1をUV値の変換ウィンドウに入力する。

裾側から順に、 $8:2(=4:1)$ 、 $7:3$ 、 $6:4(=3:2)$ 、 $5:5(=1:1)$ になっている。

すべての段の折り目について、アポロニウスの円を作図するのがもっとも正確な方法なんだけど、 $(x_A,y_A)=(0,0)$ 、 $(x_B,y_B)=(1,0)$ として単純化してみて気が付いたことがある。

分割点が $A$ 点と $B$ 点からの距離の比が $8:2$ の時、アポロニウスの円の半径は次のように求められる。

$\begin{align*} x_C&=\frac{\displaystyle -2^2x_A+8^2x_B}{\displaystyle 8^2-2^2}=\frac{\displaystyle 16}{\displaystyle 15}\\ r&=\sqrt{x_C \times (x_C - x_B)}=\sqrt{\frac{\displaystyle 16}{\displaystyle 15} \times \left(\frac{\displaystyle 16}{\displaystyle 15}-1\right)}\\ &=\sqrt{\frac{\displaystyle 16}{\displaystyle 15}}=0.2666 \dots \end{align*}$

同様に、 $7:3$ の場合は次のとおり。

$\begin{align*} x_C&=\frac{\displaystyle -3^2x_A+7^2x_B}{\displaystyle 7^2-3^2}=\frac{\displaystyle 49}{\displaystyle 40}\\ r&=\sqrt{x_C \times (x_C - x_B)}=\sqrt{\frac{\displaystyle 49}{\displaystyle 40} \times \left(\frac{\displaystyle 49}{\displaystyle 40}-1\right)}\\ &=\sqrt{\frac{\displaystyle 441}{\displaystyle 1600}}=0.525 \end{align*}$

同、 $6:4$ の場合は次のとおり。

$\begin{align*} x_C&=\frac{\displaystyle -4^2x_A+6^2x_B}{\displaystyle 6^2-4^2}=\frac{\displaystyle 9}{\displaystyle 5}\\ r&=\sqrt{x_C \times (x_C - x_B)}=\sqrt{\frac{\displaystyle 9}{\displaystyle 5} \times \left(\frac{\displaystyle 9}{\displaystyle 5}-1\right)}\\ &=\sqrt{\frac{\displaystyle 36}{\displaystyle 25}}=1.2 \end{align*}$

つまり、ものすごくざっくりではあるけど、比率が1割変動するたびに半径は約2倍になっている。半径の計算に平方根を使っていることに多分関係がある。円の中心点 $C$ は移動するので単純に2倍では本当はダメなんだけど、同じ作業を60回繰り返すのはちょっと辛いので、ある程度は近似できるということも併記しておく。

なお、 $5:5$ の場合は $m=n$ なので、 $m^2-n^2$ は0になってしまい、計算できなくなる。分割点がちょうど中間の場合は、点 $A$ 、点 $B$ 及び点 $P$ をつなぐ三角形は二等辺三角形になり、点 $P$ の軌跡は直線になる。つまり、アポロニウスの円の半径は無限大になり、円にならないということ。とは言え、計算できないと座標が求められないので、 $6:4$ の場合の更に2倍と仮定して求める。

ひだの短いほうのエッジを選択し、ストレッチ（Stretch）ツール（Hキー）の中心点は $(X,Z)=(-0.5,0)$ に固定、下から順に200%、400%、800%まで内側に向かって拡大する。

ウェストの絞り込み

最後に、ウェストに向かって細くなるように各段のエッジを1周分選択して縮小する。冒頭で「ウェストに向かって絞ったらプリーツスカートの意味がない」と言っていたことと矛盾するように感じるかもしれないけど、これまでの操作で上の段に行くほどプリーツの幅は広くなっているので、最後に帳尻合わせのために縮小しなければならない。エッジの長さを固定して折り畳めないならば、一度広げてから縮小して元のスケールに戻すという発想。

裾から数えて2段目の設定。裾のひだの長いほうのエッジが8に対して7なので87.5%と求めた。

裾から数えて3段目の設定。裾のひだの長いほうのエッジが8に対して6なので75.0%と求めた。

裾から数えて4段目、つまり上端の設定。裾のひだの長いほうのエッジが8に対して5なので62.5%と求めた。

拡大してよく見てもらえればわかると思うけど、折り返し部分も含めた裾の長さの総計に対し、上の段の長さは必ずしも一定ではない。プリーツの表側と折り返し部分の比率はほぼ計算どおりなので、折り返しの角度が深すぎるために長くなってしまっている。

基本版完成

以上の操作がすべて完了してできあがったのが次の画像のようなモデル。水車のような形にはなっているけど、とてもではないけどお世辞にもスカートのようには見えない。

ところが、これにサブパッチ（キャトマル）をかけると、不思議なことにかなりそれらしいプリーツスカートに早変わりする。チェック柄もそれほど大きくは歪んでいない。見直す余地はまだあるけど、方向性は間違っていないことが確認できた。

最後に、アポロニウスの円を各段ごとに作成したという証拠物件。後でどうしても正確を期したくなった場合に再利用する。これらの円を使って作業している途中で円の半径が比率の2乗にほぼ比例することに気が付いた。

途中経過

作業のしやすさを重視して単位長（1メートル）の範囲内でモデリングしていたので、実際のモデルに着せるには大きさを全体的に拡大し、ウェストの位置とサイズに合うように調整する。あとは、多少脚がはみ出していても、物理演算でなんとかできる。

ClothFXを次の画像のように設定する。構造維持（Hold Structure）は「100」くらいにしておかないと体のラインに合うように変形してくれないのであまり上げすぎないほうがいい。一方、粘性（Viscosity）と抵抗（Resistance）をそこそこの数値にしておかないと、スカートの形状がなかなか落ち着いてくれないし、わざわざ計算までして比率を揃えたプリーツが不規則に歪むのを抑制できない。

ちょっと短かったけど、いつものモデルに着せてみるとこんな感じ。

チェック柄を解除して無地にするとこんな感じ。ウェストの余裕を厳しくしすぎたために、スカート右側の一部のプリーツがモデルに貫通してしまっている。上の画像でも同様の現象は起きているんだけど、柄がなくなったので目立ってしまった。

参考記事

「プリーツスカートの展開面は長方形」という驚きの事実を再確認すべく、プリーツスカート折り紙を作る。曲線折紙はほんと面白い（まんがは「制服の幾何学」より） pic.twitter.com/lDPrQN6ApY

— こーわ (@kowa) 2016年5月4日

LightWaveで二次元キャラ系人物モデリング奮闘記 ―手指FK編―

最終更新：2016/12/05

手の指にはIK（インバース・キネマティクス）を設定しないで、FK（フォワード・キネマティクス）のままにしてある。手の指はFKにすることが多いというので盲目的にそれに倣っていたわけだけど、なぜ手の指だけはFKのほうがいいのかという理由まではよくわかっていなかった。

最近ようやくその理由がわかった。まったく合理的なもので、FKなら「5本の指をひとつのコントローラで一度に操作できる」から。具体的には、5本指の全関節のボーン旋回をまとめて、ひとつのコントローラ・オブジェクトの回転に追従させるようにする。こういった設定を3DCG分野では一般にコンストレイン（Constrain = 拘束）と言う。

手は狭い範囲に関節が集中するところなのでIKを使いたくなるんだけど、IKの場合それぞれの指先にひとつずつゴールオブジェクトが必要になる。指の折り曲げ方の加減を個別に決められる反面、手を握ったり開いたりするような単純な動作をさせる場合でも単純に5本分の手間がかかる。また、IKを設定した関節の角度はゴールオブジェクトの位置から逆算的に求められるので、ある関節だけ曲げ、ある関節だけ伸ばすといった制御が難しくなる。

コンストレインをうまく利用すると、手のおおまかな握り方はコントローラで決定し、それぞれの指の調整が必要な場合は直接指定といったことができるようになる。ただ、それを実現するためには熟慮した設定が必要になるため、IKよりも手間がかかる。リグというのは本当に奥が深くて、直感的な操作を可能にしようとすればするほど設定は複雑になっていく傾向にある。

本記事ではLightWave 2015のGENOMA2を利用しているけど、標準機能のスケルゴンやボーンを利用しても設定可能。LightWaveでいつからコンストレインができるようになったかは定かではないけど、少なくともLW 9.6の頃には既に使えていた。

ボーンの二重化

単純に5本指を握ったり開いたりするだけで良ければ、既存のボーンの「回転アイテム」にコントローラ・オブジェクトを指定すれば全部の指を同時に操作できるようになる。ただ、そうした場合は文字通り回転アイテムに完全に拘束されてしまうので、個別にヘディングやピッチを直接入力してもその値は無効となり、コントローラ以外の方法で指を操作できなくなる。

そこで、コンストレイン用のボーンを作成し、ボーンを二重化する。次の画像は初期状態。

いずれかのボーンを選択し、Ctrl+Cでコピーし、Ctrl+Vで同じ場所にペーストする。次の画像は中指の根元のボーンを選択した状態。

選択を解除しないで拡大縮小ツール（Shift+H）で適度な大きさまで縮小する。アクションの中心は「選択範囲モード」を使用する。

どのボーンがコンストレイン用なのか判別できればいいので、大きさは任意。あまり目立たないようにと思い、だいぶ小さくしてしまって後で選択しにくくなってしまったので、50%前後がちょうどいいかもしれない。

コンストレイン用のボーンを選択し、スナップドラッグ（Snap）ツール（Shift+G）の数値入力ウィンドウで「全ポイント」を指定する。

本来のボーンの根元にスナップさせる。スナップドラッグではポイントの結合はしないので、浮動スケルゴンになっているけど、理論上はこのままでもコンストレイン用のボーンとして機能する。もののついでなので、指の関節の長さを調節した。指の第3関節の長さを100%とした時、第2関節はその75%、第1関節は更にその75%（つまり、第3関節の56.25%）にすると美しく見えるそうだ。

同様にして、5本指のすべてのボーンに対してコンストレイン用のボーンを作成する。手間のかかる作業だけど、リギング作業というのは究極的にはこういう地味な作業の繰り返しなので、目的に対して作業のコストがかかりすぎると思う場合は省略してもいい。そういった割り切りもリギングのうちとも言える。

コンストレイン用のボーンを作成し終わったら、次の画像のように判別しやすいようなスケッチ色をつけておく。また、余裕があったらGENOMAプロパティの「アイテム」タブでアイテム色を「レッド」に設定しておくとレイアウトでも赤いボーンとして表示されるので視覚的に識別しやすくなる。

GENOMA2を使っている場合は、コンストレイン用のボーンに一括でコントローラを指定できる。上の画像で赤色のボーンを選択し、「GENOMA編集」のセットのドロップダウンメニューから「コントローラ」を選択する。

次の画像は5本指のもっとも手のひらに近いボーンのコントローラ設定。握ったり開いたりする他に、指を揃えたりジャンケンのパーのように開いた状態を実現するためにピッチもコンストレインしている。

次の画像はその他の指の関節に相当するボーンのコントローラ設定。指の途中からピッチ方向に旋回してしまうと骨折したようになってしまうので、ヘディング方向だけコンストレインしている。

GENOMA2を利用している場合は、モデラーでボーンの親子関係を変更しておく。これまで使っていたボーンをコンストレイン用のボーンの子になるように設定し、コンストレイン用のボーンをその前の節のボーンの子になるようにする。GENOMAは親子関係を特に指定してある場合はスケルゴンツリーを無視するので、従来のスケルゴンの接続を切り離す必要はない。

途中で頭が混乱してくるかもしれないけど、最悪レイアウトでGENOMAリグを組ませてみて確認してもいいので、地道に作業する。この親子関係を言葉で説明するとわかりにくいので、次のスケマティックビューを見てもらったほうが理解しやすいだろう。

右手への複製

右手は基本的に鏡面X（Mirror X）で左手を複製するんだけど、GENOMAスケルゴンの場合は内部的に様々な設定が入っているので、ただ複製してリネームしただけだと何かの設定が競合又は衝突するようで、レイアウトでGENOMAリグを編成する際にLightWaveがクラッシュする。

そこで、次の画像のようにいったんGENOMAのタグを消去して通常のスケルゴンに戻した。まさかクラッシュするとまでは思っていなかったので右手のボーンを全部削除してしまったんだけど、よくよく考えてみたらボーン・ウェイトの設定も消してしまったことになるので、従来のボーンは活かしておいて、コンストレイン用のボーンだけ鏡面複製するほうが賢明。もし、原因不明のクラッシュが頻発する場合はGENOMAタグの消去を試してみると改善するかもしれない。

右手のセットアップをほとんどやり直す羽目になったけど、右手も左手と同様に設定した状態が次の画像。

コンストレイン用のボーンにはボーン・ウェイトを設定してなくても大丈夫だとは思うんだけど、左手と重複するウェイトが設定してあるのはさすがに問題なので、スケルゴンツリーで確認しておく。

左手を右手に複製した時にポイントを共有するボーンがすべて結合されてしまったので、ツリーとしてはかなり不可解な状態になっている。GENOMA2を使わない場合は、このままレイアウトにもっていって、親子関係をSceneEditorなどで修正することになる。

スケルゴンツリーの「ウェイトマップ」欄をダブルクリックするとボーン・ウェイトの設定を変更できるので、左手のウェイトが割り当たっている場合は右手のものに変更する。

コンストレインの設定

手を握ったり開いたりする動作は人差し指から小指まで同じヘディングで制御するので設定は同様でいいんだけど、指を水平に開いたり閉じたりする動作はピッチ制御で行うので、中指を基準（0倍）にして外側に行くほど大きくなるように倍率を変えて設定する。次に例示する各設定はGENOMA2を利用した場合のもの。

中指

自分の手を動かしてみればわかると思うけど、指を水平方向に開いたり閉じたりしても中指はほとんど動かない。これを利用してピッチの基準にする。コントローラ・オブジェクトのピッチに影響を受けないように、「x / +」の「x」側を「0.0」にする。

なお、GENOMA2で「回転アイテム」を指定しておくこともできるけど、モデラー上に存在しないアイテム名を指定するとレイアウトでGENOMAリグの作成に失敗する。今回はレイアウトで後付けでコントローラを追加するので「NONE」のままにしている。

GENOMA2を使わない場合は、レイアウトで次の画像のように設定する。「回転アイテム」に指の制御用のNullオブジェクトを指定してある。他の設定は同様なので、中指だけ例示しておく。

薬指

薬指はコントローラのピッチの影響を通常通り受けるので、「x / +」の「x」側を「1.0」のままにしておく。水平方向に開く方をピッチのプラスにしているけど、マイナス方向にしたい場合は「-1.0」にすればいい。

小指

小指は薬指よりも更に外側に開くので、「x / +」の「x」側を「2.0」にし、コントローラのピッチの影響を2倍にする。

人差し指

人差し指は薬指とは反対方向に開くので、正負を反転させる。「x / +」の「x」側を「-1.0」にし、コントローラのピッチの影響を逆にする。

親指

親指が結構難問で、次の画像の設定でもうまくいっているかどうかは今のところなんとも言えない。親指は他の指とは異なり、握り方向がピッチに寄っているので、少なくとも追跡するコントローラの成分を入れ換える必要がある。ヘディングはコントローラのピッチを、ピッチはコントローラのヘディングを追跡するようになっている。右手の場合は更に正負を逆転させる必要が出てくることもあるので、予想しきれなくなったらレイアウトでテストしてみて影響量を判断する。

リグのテスト

レイアウトでGENOMAリグを作成した後、コントローラ用のNullオブジェクトを作成し、コンストレイン用のボーンに参照させる。コントローラの指定はSceneEditorで複数のボーンを一度に選択して右クリック、「操作」－「モーションオプション」でまとめて設定できるので、GENOMAの使用に関わらず片手ごとに1回で済むはず。

なお、コントローラ用のNullオブジェクトは手首のIK用のNullオブジェクトの位置にコンストレインしてある。コントローラはできれば手に近い場所にあったほうがいい。

次の画像はGENOMAリグを作成した直後のニュートラルの状態。赤く見えるのがコンストレイン用のボーン。

次の画像はコントローラのピッチを「10°」に設定した状態。水平方向に指が開いているのがわかる。

次の画像はコントローラのピッチを「-10°」に設定した状態。水平方向に指が揃えられているのがわかる。

次の画像はコントローラのヘディングを「30°」に設定した状態。5本の指が一斉に握る方向に曲がっているのがわかる。

次の画像はコントローラのヘディングを「30°」、ピッチを「-10°」に設定した状態。5本の指が揃えられた状態で握る方向に曲がっているのがわかる。これでコンストレインのテストは終了。

次に、コントローラのヘディングを「80°」、ピッチを「-10°」に設定し、ジャンケンのグーの状態にした上で、コンストレインで拘束されていない青いボーンを選択し、ヘディングを「-80°」にすることで人差し指と親指を伸ばしている。コンストレインで拘束されている赤いボーンは下を向いているけど、強制的に前を向かせているのがわかる。

GENOMA2での親子関係の設定が正しくできていれば、SceneEditorにおけるボーンの階層構造は次の画像のような形になっている。GENOMAを使わない場合は、このようなツリーになるように親子関係を設定する。親子関係を変更することでオブジェクトの形状が崩れてしまう場合はコンストレイン用のボーンのボーン・ウェイトを削除するか、「中心点回転記録」を有効にすると改善することがある。

途中経過

レイアウトでの操作を簡単にするためとは言え、リグを結構本気でやろうとすると非常に手間がかかることがよくわかった。CGアニメーションの制作会社にはリグを専門に担当する技術者がいるというのも納得できる。

ただ、手間はかかるものの、このようなリギング作業を済ませておくと、コントローラ・オブジェクトをひとつ回転させるだけで手の握り具合を簡単に制御できるようになり、指の制御を億劫に感じなくなる。一度この感覚を覚えてしまうと、指を1本ずつ操作するのが非常に面倒に思えてくる。

LightWaveの欠点ともされるボーンとモデルの変更がレイアウトに即座に同期しないという特徴も、考えようによってはボーンやNullオブジェクトの設定をまったく変更しないでモデルのレイヤーだけ入れ換えることで別の人物モデルにリグをすべて移行できるということでもあるため、大変な思いをするのは一度だけでいいという長所にもなる。

指の関節の長さを見直してみたけど、苦労した割にはあまり変わっていない気もする。たぶん、太さや曲がり始める箇所のウェイトの見直しも同時に必要なのだろう。

参考記事

キャラクターリグ(9) – 指の開閉リグ –（メモ帳）

資料探してて初めて知った指の関節間の長さの割合 pic.twitter.com/dZtOaAvdAv

— さなきち＠低浮上 (@cco11223) 2016年3月11日

LightWaveで二次元キャラ系人物モデリング奮闘記 ―GENOMA2編―

最終更新：2016/09/06

本記事はボーン、下半身IK、上半身IKの設定が済んでいることを前提としたものです。設定の詳細は各記事をご覧ください。

ボーンやIKの設定を済ませてしまってから、よくよく測ってみたら腕が短かった、胴体のバランスが悪かった、脚が長かったといった事態は常に起こりうる。全体のバランスを調整すると関節の位置も変動するので当然ながらボーンの位置や長さが変わる。

LightWaveの場合、モデラーとレイアウトが独立しているため、モデラーでスケルゴンを編集するだけではレイアウトには反映されないばかりか、スケルゴン変換やSkelegon Readerを使ってオブジェクトに組み込まれたスケルゴンからボーンを生成するとIKなどの設定はすべて消えてしまい、最初からやり直すことになる。できればそういった二度手間は避けたい。

そこで、LightWave 2015から実装されたGENOMA2を利用して極力レイアウトでのリグの組み直しの手間を減らす方法を考えた。

GENOMA「2」と言うからにはGENOMA「1」に相当するものがあったわけなんだけど、GENOMA2は厳密にはGENOMA1の単なるバージョンアップ版ではない。LightWave 11.5で実装されたGENOMAはプリセットとしてコンポーネント化されたリグパーツを組み合わせることで本来は熟練が必要な高度なリグを簡単な手順で導入できるようにしたもの。それに対し、GENOMA2はそういったリグパーツを根本から開発するためのプラットフォームという位置づけになっている。

最初からリグにGENOMAを使うことを前提としてモデリングしていた場合はいいけれど、既に従来のスケルゴンでリグを組んでしまったモデルには即座に応用できないという問題があった。GENOMAのプリセットには適当なスケルゴン名が付けられているため、それらに名前をつけ、ボーン・ウェイトを割り当てるところから始めなければならず、大幅に戻り作業が発生してしまう。何より、せっかく組んだリグを破棄しなければならないというのは精神的につらい。

GENOMA2を利用すれば、従来のスケルゴンを活かしつつボーン・ウェイトの再設定も発生させることなくリグを新しいものに入れ換えることができる。本来はこういった目的で使うものではないけど、リグを更新するための手段と割り切って使うことにする。

GENOMA2セットアップ

最初はモデラーで操作する。まず、モデルに組み込んであるスケルゴンを抽出し、別のレイヤーに移す。モデルにはスケルゴンを残さない。ポリゴン状態ウィンドウ（Wキー）を利用すると簡単に取り出すことができる。

スケルゴンだけ取り出した状態が次の画像。これをGENOMA2用のスケルゴン（以下、GENOMAスケルゴン）に変換する。変換後は全部を元に戻すのは困難なので、どこか別のレイヤーにバックアップをとっておくといいだろう。

すべてのスケルゴンを選択し、「セットアップ」メニューグループにある「GENOMA編集」サブグループの「セット」のドロップダウンメニューから「デフォルトタグ」を選択する。

しばらく待ち時間があり、計算が終わると次の画像のような、いつものスケルゴンより太めのスケルゴンが生成される。

従来はレイアウトで実施していたボーンに対する設定をここで行う。対象のスケルゴンを選択し、「プロパティ」を選択すると設定ウィンドウが表示される。一部の設定を除き、一度にひとつのスケルゴンしか設定できない。レイアウトで行える設定はすべて実施できると考えていい。

各所のボーンに上半身IKや下半身IKで行った設定とまったく同じ設定を施す。ここだけはどうしても二度手間が発生してしまうけど、これが最後と思えば少しはやる気にもなるだろう。

「アイテム」タブではアイテム種別（Item Type）の他、ボーンの色や見え方を設定できる。「モデラー形状を無処理（Leave Modeler Shape Intact）」という設定は標準タイプのくさび形のボーンではなく、特殊な形状のボーンとして表示させたい場合に使用する。

「ギズモチャンネル有効（Active Gizmo Channels）」はレイアウトでアイテムを選択した時に当たり前のように出る移動を示す矢印、回転を示す円といった3軸のGUIコントローラを表示し有効にするかどうかの設定。ゴールオブジェクトをはじめとするコントローラ系のオブジェクトには設定しておかないと直接数値を入力することでしか制御できなくなる。逆に言えば、従来のNullオブジェクトを使ったリグで邪魔だったギズモを表示されないように制限することができるということ。

GENOMA026 — 位置用ギズモチャンネルの例。特定の軸だけ表示することもできる。

表示にあるとおり、Nullオブジェクトもモデラーで作ってしまえるんだけど、レイアウトでのNullオブジェクトが1点だけの方向のない座標なのに対し、2点を指定するスケルゴンとして作成する必要があり、三次元的なベクトルができる。詳しく調べていないのでなんとも言えないけど、レイアウトに移した時にXYZの3軸が入れ替わってしまうローカルな座標系になってしまい、プラス方向が上なのか下なのかわからなくなってしまってコントローラやゴールオブジェクトとして役に立たないという事態が起きた。

次の画像の「形状」タブではレイアウトでのボーンの表示のされ方を設定する。通常のボーンの場合は変更する必要はない。レイアウトで見やすいようにラベルをつけたり、特別な色を着けたりすることもできるけど、リグに熟達してから使うようにしても遅くない。

なお、上の「アイテム」タブで「モデラー形状を無処理」を選択した場合か、Nullオブジェクトを選択した場合に限り「アイテム形状」で指定した形で表示される。ボーンの場合はレイアウトでのみ形状が変わるというちょっとクセのある仕様。

次の画像の「ボーン」タブでは、レイアウトでのボーンの「アイテムプロパティ」とほぼ同じ設定ができる。うっかりすると忘れてしまいそうになるウェイト関連の設定をあらかじめしておけるのは助かる。

次の画像の「IK」タブではレイアウトの「モーションオプション」の「IKとモディファイヤ」タブに相当する設定ができる。ゴールオブジェクトも設定できるんだけど、上でも書いたとおりNullオブジェクトの座標系がいまひとつわかりにくく、レイアウトとは感覚が異なるので、慣れないうちはここで設定してしまわないほうがいい。存在しないゴールオブジェクトを指定するとリグ作成の際にエラーになるので、「NONE」のままにしておく。

次の3つの画像の「位置」、「回転」、「スケール」タブではレイアウトの「モーションオプション」の「制御と制限」タブに相当する設定ができる。

次の画像の「回転」タブは重要。IKに関係するボーンの場合は必要に応じてピッチ制御とヘディング制御に「インバースキネマティクス」を忘れずに設定しておく。

シンプルな人物モデルの場合は次の画像の「スケール」タブで設定することはほとんどないだろう。

次の画像の「エクスプレッション」タブでは特殊な制御を数式として登録したい場合に使用する。構文が決まっていて、ほぼプログラムと言ってもいいレベルなので、よほど難しいリグを組む場合でない限り使うことはないだろうけど、参考までに。

次の画像の「スクリプト」タブではGENOMAを利用してリグを編成する際に実行させたいスクリプトを指定できる。これも高度なので利用する機会は少ないと思うけど、GENOMAが実行されている間だけ存在していて、編成が完了したら当該スケルゴンを自己消滅させてレイアウトには表示されないようにするスクリプトなんかを置いておくことができる。

GENOMAスケルゴンの設定が済んだら、それをコピーしてモデルのあるレイヤーにペーストして組み込む。その後、オブジェクトを保存（Sキー）し、レイアウトに移る。

GENOMAリグの作成

「アイテム」タブの「置き換え」を利用して既存のモデルをGENOMAスケルゴンを組み込んだモデルと入れ換える。既存のボーンを綺麗に削除しておかないとGENOMAでリグを編成する際にエラーの元になる。SceneEditorを開き、Rootボーンの配下に子オブジェクトがないか確認する。

Rootボーンの配下にオブジェクトがある場合はモーションオプションでモデルの直下に移動させる。上の画像の場合はスカートのオブジェクトがそれにあたる。スカートは物理演算で自然な形になるように設定してあるため、人物モデル本体とは独立している。

Rootボーンの配下にボーン以外のアイテムがないことが確認できたら、Rootボーンを選択して「選択アイテム消去（-キー）」を実行する。

次の画像のように確認ダイアログが表示されるので、「はい」を選択する。

子階層のアイテムをどうするか更に尋ねられるので、同様に「はい」を選択し、Rootボーン以下のすべてのボーンを削除する。

準備が整ったら、シーンを別名で保存しておく。GENOMAを一度走らせてしまうと不可逆的な変更が加えられてしまい、最悪手がつけられなくなる事態になることもあるため。

ボーンを作成したいオブジェクトを選択し、「リグ作成」をクリックする。ボーンがそれほど多くなくても結構計算に時間がかかる。次の画像のように「GENOMAリグが正常に作成されました」と表示されればひとまず問題なく処理が終了したことになる。

GENOMAでリグの編成中にエラーが出ると、GENOMAは途中で処理を終了してしまう。次の画像は、存在していないオブジェクトを指定したために出たエラー。仮にシーン内に同名のオブジェクトがあったとしてもGENOMAはそれを識別してくれない。あくまでもGENOMAスケルゴンとして組んだものしか処理の対象にならないという点に注意しなければならない。ゴールオブジェクトをGENOMAスケルゴンにあえて組み込まなかったのはシーンに既に存在するNullオブジェクトを利用したかったから。

GENOMAの処理が途中で終わってしまうと、ボーンの階層化まで処理が進まずにモデルの配下に同一階層のボーンが並んでしまうこともある。他にもありとあらゆる物が中途半端な状態になるため、手のつけようがなくなる。モデラーに戻ってエラーの原因になった設定を見直す。

無事にGENOMAリグの作成が済むと、次の画像のようにスケルゴンの階層どおりの整然とした親子関係が築かれる。MASTERオブジェクトというNullオブジェクトが原点位置に必ずできてしまうので、それに相当するオブジェクトが既にあって必要なければ削除しても構わない。

元のリグに戻すため、モデルをTOP_Nullオブジェクトの配下に配置し直す。

同様にリグの復元のため、RootボーンをWaist_Nullオブジェクトに追従するように設定する。詳しくは下半身IKの記事を参照のこと。

次の画像はRootボーンにフォロワーモディファイヤを追加した状態。

最後に、IKで使用する各ボーンにゴールオブジェクトを指定して完了。IKで屈伸する関節などその他の設定はモデラーで済んでしまっているので、そんなに大した作業ではないはず。

GENOMAリグの更新

モデラーでリグの設定のほとんどを済ましてしまえるのだから、動的にリグを更新できるようになった、と言いたいところなんだけど、実はそれほど簡単でもない。

モデラーでスケルゴンを編集してリグを変更したら、レイアウトにある、その名もズバリの「リグ更新」で変更箇所を反映させられるんだろうかと思うのが人情なんだけど、リグ更新ツールを使うとリグとはまったく関係なくても「オブジェクト」と名のつく物はすべて消去されて最初から構築し直されてしまう（ライトやカメラは残る）。つまり、当該ツールはモデルに組み込んだリグを何もないシーンでテストする時にしか使えないということ。リファレンス・マニュアルにもそのように書いてあり、LightWaveの仕様なのでこればかりはどうしようもない。

そうかと言って、既に組んでしまったシーンに存在するモデルのリグこそ更新したいと思うのは自然な欲求。そういう場合は、リグ更新ツールを使うのではなく、モデルを新しいものに入れ換え、再度「リグ作成」を実施する。その際に、ボーンはもちろんのこと、MASTERオブジェクトも削除しておかなければならないし、GENOMAを使用すると自動的に追加される次のような名前のオブジェクトも削除しておく必要がある。実態は把握していないけど、おそらくコントローラやエクスプレッションに関する設定が入っているか、他のソフトウェアとの互換を図るためにあるものだと思う。

Anima_Data_Counter_FK@0
Anima_Data_Counter_SaIControl@0
Animation_Data_Counter

GENOMAが自動的に作成したものをすべて削除してしまえば、再度リグ作成を実行できる。頻繁にリグを見直す可能性がある場合は、素直に新規シーンで個別にテストしたほうが無難。

途中経過

この画像だけではわかりにくいと思うけど、腕を少し長くした。本文ではまったく触れなかったけど、GENOMAプリセットに用意されている人物用のリグは構造があまりにも複雑でちょっと使う気にならなかった。本気でアニメーション完全対応のリグを組むとこうなるよ、という教材としては参考になりそうなんだけど。

LightWaveで二次元キャラ系人物モデリング奮闘記 ―まつ毛編―

最終更新：2016/09/06

今回はまつ毛のモデリング。まつ毛の話は最初のほうの顔のモデリングで少ししたけど、最終的にモデリングで作るのか、テクスチャで描くのかを決めずに仮設のまま放置していた。大幅に順序が前後するけど、瞳をすり鉢状にしてディテールを改善したことだし、まつ毛もモデリングで作ることに決め、ここで詰めていくことにする。

ボーン・ウェイトの記事でも少し触れたけど、ここでウェイト・マップを応用したサーフェースのパラメータ調整にも挑戦してみる。

頭の連続したポリゴンだけを取り出すと、現状は次の画像のようになっている。ちなみに、頬の紫色と首の赤色のスケッチ色は「法線の折り目」検出を使わずに顎のラインの境界線をunReal Xtreme2に確実に認識させるためのもの。

まつ毛のモデリング

まずは仮設のまつ毛の黒いポリゴンをすべて削除し、次の画像のようにまつ毛の裏打ちとして残しておいた眼窩の周囲のポリゴンを選択する。細かい部分なのでサブパッチは一時解除しておいたほうが作業しやすい。対称モード（Shift+Y）にしておくと左目のモデリングと同時に右目のモデリングも同時に進む。後頭部がガタガタなのはこの際気にしないで欲しい。

例によって拡張プラス（Eキー）でポリゴンを追加し、次の画像のように必要な分だけ前に押し出す。具体的には16mmだったけど、顔のスケールが1m以上あるのでほんの1～2%程度の範囲。

まつ毛用のサーフェースは既に作成済みなので、どこからどこまでがまつ毛なのかわかりやすいように仮設のまつ毛に使っていた色を着けておく。

まつ毛を伸ばしたい側面のポリゴンを選択し、拡張プラスと移動ツールで拡張する。この時点でまつ毛の先端は顔から離れることになる。

拡張したポリゴンの上下、前後のポイントを次の画像のように中央の1点に集約させる。スナップドラッグツール（Shift+G）を使ってもいいし、目標のポイントを中心にして拡大縮小ツール（Shift+H）を使って0%まで縮小してもいいし、ポイント情報で座標を直接入力してもいい。ポイントを結合してしまうとまつ毛の先が尖らなくなってしまうので、例によってポイントは結合しない。

ポイントを結合しないと気持ち悪いということであれば、サブパッチの場合はサブパッチ・ウェイト、キャトマルの場合はエッジ・ウェイトを使って尖らせる。ポイントを結合した場合は線ポリゴンが一定数できるので、忘れずに削除しておく。なお、ポイント結合時に限り対称モードを解除しておかないと左右のまつ毛がつながってしまうのでその点だけ注意。髪の毛と異なり、まつ毛の場合は尖らせたい箇所が数えられるほどしかないので、ウェイトを使うのも手ではある。

まつ毛の目尻側の下端が眼窩の外側のポリゴンのエッジにも接続していると目を綺麗に囲んでくれないことが判明したので、ポイントの結合を解除（Ctrl+U）し、眼窩の内側に接続し直した。その際、まつ毛の裏側にあたる顔側のポリゴンがひとつ不足するため、ポリゴン作成（Pキー）で三角形のポリゴンを追加した。

対称モードを適切に使用してモデリングしていれば、左目のまつ毛が完成する頃には右目のまつ毛も概ねできあがっているはず。まつ毛の眼窩の内側への接続し直しとポリゴンの追加だけは左右を個別にやらないといけないので若干効率が悪いけど、テクスチャを使わないことに決めたのだから、そのくらいの手間は惜しんではいけないのかもしれない。

ウェイト・マップを応用した色調調整

これで終わってしまうとただの作業記録になってしまうので（ブログだから別にそれでもいいのかもしれないけど）、ちょっと新しいことをする。

まつ毛の目頭側の下端がくっきりしすぎているので、少しぼかしたい。モデリングで短くすることも考えたんだけど、パッチ単位でしか短くできないので、大幅に短くなってしまう。そこで、ボーン・ウェイトとは無関係のウェイト・マップを活用する。

新規ウェイト（Weight Map）で「Cilia_Weight」という名称のウェイト・マップを追加する。

目頭側のポイントに外側から順に「100%」、「50%」のウェイト値を設定する。

モデラーのプレビューではウェイト・マップの効果を確認できないので、レイアウトでサーフェースの詳細を設定する。色のテクスチャ設定でグラディエント・マップを選択し、次の画像のように50%のキーから100%に向かって肌色になるようにグラデーションを設定する。

かなり微妙ではあるけど、目頭側の色調が若干ぼやけた。もう少し研究が必要そうだけど、やろうとしたことはわかるのではないかと思う。

途中経過

遠景にするとウェイト・マップによる色調調整はほとんどわからなくなってしまうけど、まつ毛が増量されて目力が更に増し、顔の情報量が増えてきた。そうすると、今度は首から下の情報量の少なさが気になってくる。

LightWaveで二次元キャラ系人物モデリング奮闘記 ―瞳編―

最終更新：2016/09/06

ここでちょっと脱線。これまで瞳にはUVを使わずに平面状にテクスチャ・マップを貼り付けていた。二次元キャラクター風の3DCGモデルを作りたい場合、目は平面か若干凹ませるくらいで造るというのは前の記事でも書いたけど、それを更に進め、瞳をすり鉢状に造型してハイライトと陰影をコントロールすると同時に視線の方向をわかりやすくする。

この手法は本来、設置されている環境の光源によって見え方に影響を受けるフィギュアの造型に関するものなんだけど、3DCGにも応用できるのではないかと思い、以前から試してみたいと思っていた。

概念図

基本的な考え方を簡単な図に示す。次の画像のような平面状の目の場合、斜めから見ても光の加減に関係なく単純に斜めに見えるだけなので、ハイライトや陰影といった視覚情報をテクスチャにあらかじめ描き込んでおく必要がある。また、視線がどこを向いているのかわかりにくい傾向がある。

一方、次の画像のようなすり鉢状の目の場合、斜めから見ると光の加減でハイライトや陰影が生じるため単色のサーフェースでも情報量が多くなる。また、瞳の中心が左右どちらかに圧縮して見えるので視線がどちらへ向いているのか想像しやすい。

なお、念のため前置きしておくけど、本記事は平面状の目に対してテクスチャ・マップを貼る手法を否定するものではない。あくまでも個人的好奇心と実験的要素が大きい。

平面状の目のテクスチャ・マップ

現状、目のモデルは次の画像のようになっている。

斜めにすると次の画像のように見える。これでも問題ないと言えば問題ないんだけど、どの方向から見ても陰影に変化がなく、立体的にも変わり映えがしない。

テクスチャ画像には次の画像を使用しており、元はInkscapeでベクター画像として作成したものをPNG画像としてエクスポートしたもの。目に落ちている影も一応描き込んであるものの、目の形状の都合でほとんど見えていない。

テクスチャ画像は円形だけど、目のサイズに合うようにX軸方向とY軸方向のスケールを調整して貼り付けている。

すり鉢状の目のモデリング

ボックスをメタフォームで細分化して球状に形成していってもいいんだけど、すり鉢状にしていくことを考えるとボールから作ったほうが良さそうだったので、ボールから作る。「サイド」は顔側の形状に合わせて8面にした。「分割数」は少し多めに12とした。多すぎる場合はバンドグル（Band Glue）で整理すればいい。

目は概ねZ軸方向を向いているので、ボールの中心軸をZ軸方向に向ける。

サブパッチを適用し、前に出っ張っているほうをZ軸に反転（Flip It）させて、瞳の前縁くらいまで移動させる。ポリゴンが裏返ってしまうので、法線を反転（Fキー）させる。黒く見える線は背景レイヤー。テクスチャ・マップで作った平面状の目の大体の位置と大きさを把握するためのもの。

瞳の内側にあたるエッジやポイントをループ選択（Select Loop）などで円環状に選択し前後に移動させ、拡大縮小（Size）ツール（Shift+H）で凸部分の大きさを調整しながら起伏を増やして造型していく。瞳の中心を一番暗くしたい場合は光が差し込まないように更にもう一段深くする。すり鉢の角度をあまり深くしすぎて瞳の中心が見えなくなってしまっては本末転倒なので、最大でも45°が限度といったところだろう。

サブパッチがかかっていると鋭角のエッジは想像よりも鈍りやすく段差の高さを調整しづらいので、折り返し箇所が苦しくなってきたら拡張プラス（Eキー）で平面の段を追加する。円形だからバンドグルによるポリゴンの再統合も容易なので、とりあえず一段分割してみてから考えてもいいと思う。

瞳の造型が大体できたら、眼窩の形に合うように白目の部分を形成する。平面状の目を先に作っていたので、それを構成するポイントを利用し、スナップドラッグ（Snap）ツール（Shift+G）で合わせた。スナップドラッグはポイントの結合はしないので、単純に既存のポイントに位置合わせをしたい時に便利。

最初からすり鉢状の目を作る場合は、ポリゴン数が単純に多いので瞳の位置や向き、白目の面積の調整に苦労するかもしれない。瞳に平面状テクスチャを使っていればレイアウトでも位置や大きさの微調整はできるけど、モデリングで瞳を作った場合はレイアウトでの調整は困難になる。

また、中心軸がZ軸方向に完全に平行なすり鉢状では横から見た時に瞳がまったく見えなかったり、不自然に出っ張っているように見えることもあるので、移動ツールで瞳の左右外縁を後ろに押して歪ませたり、瞳の正面方向を維持しつつ横からも見えるように斜体（Shear）ツール（[キー）で加工する必要がある。ニュートラルな視線を正面に向けたい場合でも、やや寄り目くらいに調整しておかないとレイアウトに持って行った時に左右の視線がヒラメのように外向きに開いて見える。

何の目安もなく感覚でモデリングするのは結構難しいので、参照用に眼窩の形や向きがわかるような適当なポリゴンを作っておいてそれを背景レイヤーに敷いてモデリングすると少し楽になる。

瞳の幅をストレッチ（Scale）ツール（Hキー）で80%くらいまで縮小し、ハイライトにあたるボックスを追加する。

ハイライトのボックスを選択し、細分化（Subdivide）ツール（Shift+D）の「メタフォーム」で分割する。1回で十分だと思うけど、もっと球状に近くしたい場合は更に分割する。

完成したすり鉢状の目が次の画像。右目は鏡面X（Mirror X）で作るけど、一般的に二次元キャラクターのハイライトは左右対称にならないので、複製後に位置を調整する。鏡面（Mirror）ツール（Shift+V）で右の瞳の正中線に位置するポイントの座標を参照して複製するとX軸方向は比較的簡単に合わせられる。

顔に移す前に頭のボーン・ウェイトを設定する。次の画像のようにビューをウェイトシェイドに変更する。

「マップ」メニューグループのMAP値指定（Set VMAP）で両目全体に100%のウェイト値を設定する。

目を頭のボーンとは独立して制御したい場合は必ずしも頭のボーン・ウェイトでなくてもいいけど、まずはモデリングの出来映えを確認しなければならないのでひとまず頭と一緒に動くものとして扱う。

コピー&ペーストで顔のあるレイヤーに複製する。モデラーでは問題なさそうではあったけどレンダリングしたら想像のとおりにはいかなかったことも考え、目は別のレイヤーに残しておく。

サーフェースの設定

目には外側から順に次のサーフェースを設定している。すべてunReal Xtreme2のEdgeTracerシェーダでグループID「4」を設定し、前髪を貫通するように設定してある。

Eye_Ball – 白目
Eye_Outline – 白目と瞳の境界部分
Eye_Pupil – 瞳の外側のすり鉢部分
Eye_Iris – 瞳の外側と中心の境界部分
Eye_Pupil_Center – 瞳の中心のすり鉢部分
Eye_Highlight – 瞳の右上にある固定ハイライト

サーフェースの設定は好みの部分も大いにあるのであくまでも参考程度に。次の画像は白目とハイライトの部分のサーフェース設定。白目とハイライトには髪の毛などの影を落としたくないので、自己発光度（Luminosity）を「100%」、拡散レベル（Diffuse）を「0%」にしている。

次の画像は瞳の外側の輪のサーフェース設定。光源に対してハイライトを生じさせたいので反射光（Specular）を「100%」にして光沢（Glossiness）を「40%」にしている。

次の画像は瞳の中心部分のサーフェース設定。光源に対してハイライトを生じるとかえって違和感があるのでサーフェース色は同じではあるものの反射光（Specular）を「0%」にしている。

引き続きノンリアリスティック・レンダリングにunReal Xtreme2を利用しているけど、目の中のサーフェースにはCelPainterシェーダを使っていない。正確には、使ってみる前にそこそこ良好なレンダリング出力を得られてしまったので細かいパラメータ調整まで試していない。なお、自己発光度を設定しているサーフェースにCelPainterシェーダを併用すると極端に暗く出力されることがある。

ToonTracerピクセルフィルターでサーフェース境界にエッジを引かせている。瞳のサーフェースの周囲にまったくエッジが引かれていないと瞳だけ浮いて見えてしまう上、瞳が小さく見えてしまうためだ。

また、モデリング手法の都合上、鋭角のエッジができやすいので、瞳の中に途切れ途切れの同心円状のラインが生じるのを防ぐ目的で境界検出に「法線の折り目」検出を使っていない。

レンダリング比較

上の設定でレンダリング出力したものが次の画像。顔が大きくなるようにカメラのズームファクターを変更したので相対的にエッジ・ラインが細くなっているように見えるけど、瞳の中だけに限って見れば余分なエッジは出力されていないし、レイトレースによるハイライトも生じていて瞳の中央にも奥行きが出ている。

細かいことを言えば、球状の固定ハイライトが瞳のすり鉢に接触している部分でやや不自然な歪みを生じているので、ハイライトは瞳から少し浮かせるくらいがちょうどいいのかもしれない。フィギュアで宙に浮いているハイライトというのはありえないけど、3DCGの場合は3Dプリンターでの出力を考慮しない限り許される。

次の画像は比較用に平面状の目にテクスチャを貼ったものをレンダリングしたもの。3DCGの場合は平面状の目でもサーフェースを自己発光させることで光源の影響を受けにくくすることはできるからフィギュアのような問題は起こりにくいし、テクスチャの描き方次第なのではないかと言われてしまうとそれまでなんだけど、瞳の印象は変えられたので当初の目的は達していると思う。

遠景にするとやや見え方が異なる。テクスチャを貼った平面状の目を長いこと見ていて見慣れすぎているのですり鉢状の目の陰影が新鮮に見えるだけかもしれない。もちろん、平面状の目にテクスチャを貼っている例は枚挙に暇がないほどで、十分実用に堪えるものなので、もはや好みの問題と言えるかもしれない。

途中経過

どっちでも大差ないと言われてしまえばそのとおりだけど、瞳のすり鉢状モデリングの効果を確認できただけでも満足。

参考記事

この凹で造る目の表現技法にはハイライトの位置をコントロールするという意味合いもあります。 pic.twitter.com/n9QOEQMeml

— 榎木ともひで (@eyewater_e) 2016年5月24日

2024年12月
日	月	火	水	木	金	土
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

JettoBevelの概要

ベベル（標準機能）

マルチシフト（標準機能）

JettoBevelの特徴

JettoBevelを使った角の丸め

JettoBevelによる穴の刳り貫き

作例

関連記事

参考記事

電源仕様

当初の予定構成

構成変更

パーツ選定

CPU

マザーボード

CPUクーラー

メモリ

PCケース

最終構成

性能

関連記事

モデラー

スケルゴンの構成

バンクハンドルの設定

ウェイト・マップの作成

スケルゴン回転でチェック

レイアウト

完成

参考記事

瞳の後退モーフによるカメラ目線

エクスプレッションによる視線コントロール

関連記事

目を閉じるモーフの作成

口を閉じるモーフの作成

表情集

関連記事

基礎を作る

アポロニウスの円

縦横の模様を合わせる

曲線折りの模擬

ウェストの絞り込み

基本版完成

途中経過

関連記事

参考記事

ボーンの二重化

右手への複製

コンストレインの設定

中指

薬指

小指

人差し指

親指

リグのテスト

途中経過

関連記事

参考記事

GENOMA2セットアップ

GENOMAリグの作成

GENOMAリグの更新

途中経過

関連記事

まつ毛のモデリング

ウェイト・マップを応用した色調調整

途中経過

関連記事

概念図

平面状の目のテクスチャ・マップ

すり鉢状の目のモデリング

サーフェースの設定

レンダリング比較

途中経過

関連記事

参考記事