タグ: LightWave

旧メインPCのリフレッシュ後の性能

最終更新：2020/08/01

リフレッシュしたPCの性能を計測した。性能に関する記述がふたつの記事に分かれてしまったので、ひとつの記事にまとめなおした。

LightWave 2015

例によって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クーラーを風魔弐あたりに換装しようと心に誓った。

3DMark

もはや説明の必要もない3DMarkによるベンチマークのスコア。5954というネットに出回っている6000強というスコアより若干低い結果が出たけど、おそらく画面の解像度が1920×1200だったからか、ELSA製品は速度重視のオーバークロックではないからだと思われる。

PCでゲームはしないので、ベンチの結果は本当に参考程度。3DMarkは色々なベンチを計測できるけど、GeForce GTX 1660 Tiそのものが最新製品というわけでもないのであれこれとベンチを試して他製品と比較したりはしない。

仮想暗号通貨マイニング

3DCGをふんだんに使ったゲームを快適に遊べるかという尺度ではなく、ひたすら単調な計算を繰り返す単純な演算能力（いわゆるGPGPUの能力）を測るのであれば、仮想暗号通貨のマイニングをさせてみると3DMarkとは違った意味でシビアな結果を得られる。ここではイーサリウムで例示している。

MSI Afterburnerを使ってVRAMのメモリ・クロックを+750MHz（DDRなのでクロックの立ち上がりと立ち下がりの両方でデータを転送できるため、データレートは+1.5GHz）ほどオーバークロックし、13GHzにしたうえで消費電力を70％まで絞り、84W（定格120W）くらいでおおよそ28.5MH/sという速度を得られる。

これは1秒間にどのくらいのデータの塊を処理してハッシュ値を算出できるかの効率を示し、ハッシュレートと呼ばれる。「MH」は「メガハッシュ」と読み、暗号化や復号化の計算量のこと。データの塊の具体的な容量はアルゴリズムによって異なるため暗号通貨が異なると同じGPUでもハッシュレートの値は異なるし、同じ通貨でも演算の難易度は変動する。

Quadro P2000はオーバークロックできないので、75Wで15MH/sくらい。それと比較すれば、そこそこ速く、ワット・パフォーマンスも良い。

GeForce GTX1080が同様の設定をして126W（定格180W）くらいで36MH/sほどなので、GPUの数をいとわないマイニング・リグを組むならGTX 1660 Tiのほうがワット・パフォーマンスは良く、効率的に採掘できる。

ただし、日本国内では電気料金が安くなく、ワット・パフォーマンスの良いGPUを選んだとしても2020年現在ではマイニングをすればするほど赤字になるので、ベンチマーク程度に試すくらいにしたほうがいいと思う。

金銭が絡むと厄介事も多く、「あなたも簡単にマイニングできますよ」という甘い言葉で誘惑しておき、実際には演算能力の大半を盗み出し、自分は電気料金や器材に投資することなく仮想通貨だけを詐取するトロイの木馬が組み込まれたマイニング・ソフトウェアをインストールさせる悪質なユーザーもいるので注意が必要だ。

通貨というそれ自体に価値のあるものではなく、自分にも回り回って利益があるものとしては、治療法の確立していない病原体（ウィルス、細菌等）の遺伝子情報から薬剤の効果を分散コンピューティングでシミュレーションして新薬を開発することを目指したプロジェクトのほうが長い目で見ると有益だろう。

関連記事

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の効果は出ていると言える。

関連記事

参考記事

DAIVのCPUクーラーを忍者五に換装

最終更新：2019/10/05



2019年1月頃に買ったマウスのDAIV-DQZ530S1P-EX9にはIntel Core i9-9900Kが搭載されている。出荷時に搭載されていたCPUクーラーではi9-9900Kを相手にするには冷却能力不足なのではないかと常々思っていたことと、CPUの負荷が上がると不定期にファンから轟音を出すため、ストレスが溜まっていた。元気な時はまだいいけれど、体調が良くない時や疲れている時は不意に大きくなる騒音が辛く感じる。そこで、CPUクーラーの換装を計画した。

免責事項

お決まり文句だけど、たかがCPUクーラーの換装といえど、BTOパソコンの改造行為にあたるため、換装後はメーカーの保証は受けられなくなる。換装時にミスがあってCPUやCPUソケット（マザーボード）を破損してしまったとしてもそれは自己責任となる。本記事を参考にしてCPUクーラーを換装を試みて失敗したとしても当ブログは一切責任を負えないので了承のうえ、活用いただきたい。

現用CPUクーラーの性能

今回換装する92mmサイドフロークーラー。4本のヒートパイプを備え、まったく冷えないわけではないけど最大3,800rpmで回るためかなりの轟音。

右の写真が今回換装する対象のCPUクーラー。どうやら、マウス・コンピューターのオリジナル設計のクーラーらしいけど、とにかく情報が少ない。少なくとも、第6世代Core iシリーズ・プロセッサの頃にはNEXTGEARやLITTLEGEARのようなマウスのBTOパソコンに採用されていたもので、設計そのものは新しくない。

本当に銅製かどうかはわからないけど銅色の4本ヒートパイプを備えたヒートシンクの前に7枚のファンブレードを備えた92mmファンがネジ留めされている。測ったみたところ、ファンの厚さは一応25mmあったけど、フレームがないせいか目測だともう少し小さく見える。

ヒートシンクはマザーボードに取り付ける時の作業性を良くするために後背部が絞り込まれているので、ヒートシンクの体積とフィンの表面積を小さくする要因になっているように見える。

いずれにせよ、92mmサイズのファンとそれと同程度の大きさのヒートシンクでi9-9900Kは荷が重すぎるだろうな、ということは容易に想像がつく。DAIVはプロフェッショナルのクリエイターの要求にも応えられるパソコンを売り文句のひとつにしているけど、CPUがハイエンドでもCPUクーラーがエントリーレベルのものではその性能をプロフェッショナルが満足するレベルで発揮できるとは思えない。

冷却性能（電力制限95W）

とりあえず、現用CPUクーラーの力量を整理しておく。現用品を取り外してしまってからではデータ採りも容易にできなくなるので、比較対象にする記録を残しておかないと後悔の元になる。

まずは、短期電力制限（Short Duration Power Limit）を200W、長期電力制限（Long Duration Power Limit）を95W、つまり定格運用の設定にしてLightWave 2015のレンダリングで負荷試験をしてみる。LightWaveの起動直後とシーン・ファイルのロード直後はCPUの負荷が安定しないので、しばらくアイドリングしてからグラフの1:00ちょうどのタイミングでレンダリング開始した。計測と記録はHWiNFO64で行った。室温は夏場だったので30℃前後でやや高め。

水色：CPUコアクロック 黄色：CPUパッケージ電力 赤色：CPUパッケージ温度

グラフを見ると、1:00の直後からCPUのコアクロックが4.7GHzのあたりで平坦化、ラジオシティの演算が終わったところで8コア16スレッドでのレンダリングが始まり、消費電力が急上昇する。電力が高い状態は長くは続かないので、すぐに95Wまで下がって安定する。95Wの電力制限がかかっている間はコアクロックは4.1～4.2GHzで推移する。

肝心のCPU温度は電力が上昇した時に95℃まで上がっているけど、その後は75℃前後で推移している。熱設計電力（TDP）である95Wに制限して定格運用する分には現用品のCPUクーラーでもとりあえず冷やせていることにはなる。ベースクロックは3.6GHzだから、これでもターボブーストはかかっていることにはなるけど、i9-9900Kを買ってこの結果で満足する人は少ないだろう。

冷却性能（電力制限200W）

次に、短期電力制限（Short Duration Power Limit）を200W、長期電力制限（Long Duration Power Limit）も200W、つまりオール・コアが定格最大の4.7GHzで張り付く設定にしてLightWave 2015のレンダリングで負荷試験をしてみる。他の条件は上の試験と同じ。

グラフを見ると、1:00の直後からCPUのコアクロックが4.7GHzのあたりで平坦化、8コア16スレッドでのレンダリングが始まった後、消費電力が150Wを超えた状態で推移する。電力が150Wを超えている間はコアクロックは4.7GHzで推移するけど、後半からサーマル・スロットリングがかかり始め、4.6GHzまで低下しているところが現れ始める。

CPU温度は右肩上がりに上昇し、ほぼ100℃に近い温度で推移している。定格最大ではあるものの、CPUのパワーを最大限引き出そうとすると現用のCPUクーラーではまったく冷やせていることにはなる。Tjmaxの100℃に近くなった時にCPUの破損を防ぐための安全機構が有効になっていなければCPU温度は際限なく上がっていってしまうことを表している。クーラーのファンが3,800rpmで回って一生懸命風を送ってはいるんだろうけど、ヒートシンクが受け止められる熱の容量が限界に達してしまっていて風を当てたくらいでは間に合っていないと予測される。安全機構が働いているから即座にCPUの破損につながるわけではないけど、こんな状態で常用していたらCPUの寿命は確実に短くなっていくだろう。

VRMを流れる電流はCPU電圧が1.3Vとして、155Wの時で119.2Aくらい。Z390-S01の8フェーズのVRMでこれを受け止めるわけだから、1フェーズあたり14.9Aくらい。MOSFETの損傷を心配するレベルではないけど、どうせOEMマザーボードなので壊れたところでそれほど惜しくはない。

CPUクーラーの取り外し

CPUクーラー本体の取り外し

何はともあれ、CPUクーラーの本体を取り外す。スプリング・スクリューにはなっていたけど、トップフローのCPUクーラーによくあるような取り付け方法で、4点留めになっている。グリスが固着しているようなこともなかったので簡単に取り外せた。

CPUクーラーを取り外した直後のCPU。ソケットのカバーでCPUのヒートスプレッダを押さえているのでクーラーを取り外したと同時にCPUも一緒に外れてしまうようなことはない。

CPUクーラーの受熱ベース側。銅色のヒートパイプと銀色の受熱ベースの間に溝があって、そこに集中してグリスが入り込んでいるのがわかる。


CPUグリスにはダイヤモンドグリスが使われているはずだけど、見た目ではわからない。ヒートスプレッダを若干はみ出しているものの、厚すぎずもなく、少なすぎもせず、お手本のような塗り方だった。さすがにBTOパソコンを長く作っているマウスだけあって、組み立て作業者の技能は高いようだ。CPUに残っているグリスに縦縞が入っているように見えるのは、CPUクーラーの受熱ベース側に凹凸があって、その溝の部分だけグリスが厚くなっているため。

まだ購入してから7ヶ月くらいしか経っていないので、まだグリスが乾燥するまでにはなっていなかった。実際のところ、グリスが乾燥すると冷却性能が極端に低下するというのは一種の民間信仰みたいなもので、CPU側のヒートスプレッダとクーラー側の受熱ベースプレートの目に見えないくらいの凹凸を埋め合わせられていれば十分なものらしい。もともとシリコンを基剤にした普通のグリスは金属に比べれば熱伝導率が極めて悪いもので、シリコンが乾いてしまったくらいならそれほど性能に影響が出るものではないそうだ。もちろん、オーバークロック用の特殊なグリスなら短期間での冷却性能の悪化というのは起こりえるのかもしれないけど。

CPUグリスの拭き取り

リムーバーをあらかじめ買っておいたので、ウェスに適量含ませてグリスを拭き取る。グリスを綺麗に拭き取り終わるとi9-9900Kのヒートスプレッダが見えてくる。そんなに頻繁にお目にかかれるものでもないし、すぐにまたグリスを塗って塞いでしまうので、記念撮影しておく。R0ステッピングはまだ出ていなかった頃のものなので、S-Specは当然「SRELS」（P0ステッピング）になっている。

ちなみに、リムーバーはできれば電子機器用のものがいいけど、無水エタノールでも代用できる。無水エタノールは一般の薬局でも売っているので入手しやすいのが特徴。ただ、茶色の薬瓶に入った500mlの大瓶しかなくて小瓶がなかったりするので、まともに買うと結構な出費になる。油性マジックで書いてしまったラクガキも消せるので清掃用品としても役に立つんだけどね。

バックプレートの取り外し

次に、CPUクーラーのバックプレートを取り外す。DAIVのケースは設計があまり新しくなく、CPUのバックプレートにあたる位置のメンテナンスホールのカットアウトの面積が小さい。バックプレートがほんのわずかだけどカットアウトの裏側に回り込んでしまっているので、マザーボードを一度取り外してからでないとCPUクーラーの換装はできない。

BTOパソコンはパーツの交換を前提としていないので、ケースの設計を改善する必要なんてないと考えているんだろうけど、とにかく作業性が悪い。マウスのBTOパソコンを二度と買いたくなくなるくらい中途半端な設計だと思った。

このバックプレートがまた取り外しにくくて、組み立て時の作業性を良くするために両面テープでマザーボードの裏に貼り付けられていた。トップフローのCPUクーラーなど軽量級のヒートシンクを使う製品の場合は作業性を良くするためにバックプレートを両面テープで仮止めしてからクーラー本体を取り付けるようになっているものも多い。ただ、自分で取り付けたものではないので両面テープの位置を把握していないため、とにかく力任せに引き剥がすしか方法がない。

忍者五への換装

現用のCPUクーラーの部品を全部取り外し終われば忍者五の取り付けにかかれる。まずはバックプレートを取り付けるわけだけど、できるだけ手間を減らしたかったので、マザーボードのネジを8本すべて外した上で基板を少し浮かせた状態で作業しようとした。

忍者五のバックプレートにはマウンティング・プレートを取り付けるためのネジと、そのネジをCPUソケットの規格に合わせた位置に固定し、バックプレートがマザーボードの裏面を傷つけないようにするためのゴム製のクリップがあらかじめ組み付けられている。ところが、このクリップがとても外れやすく、そのうちひとつが作業中に脱落してケース内で一時行方不明になった。ケースを立てたままでのCPUクーラー換装作業は難易度が高いと言われる理由をようやく理解した。脱落したクリップは5.25インチベイの中に落ちていたのをすぐに発見できたのでまだ良かったけど、紛失したり、簡単に拾えないところに落ちていたら面倒なことになっていた。

バックプレートの取り付けさえできてしまえば後は楽勝だろうと思ってマザーボードを再度ネジ留めしてしまったのが良くなかった。忍者五はとにかくヒートシンクが大きく、取り付けにひと苦労した。マウンティング・プレートのネジ穴がヒートシンクのフィンが邪魔でほとんど見えないので、ドライバーでスクリューを回した時の手の感触だけを頼りに手探り状態でヒートシンクを固定するのはなかなか難易度が高かった。少し締め過ぎた感もある。

マザーボードを裸の状態で組み立てられれば苦労はしないんだろうけど、今回はすでに組んであるBTOパソコンの換装なので、作業領域がとにかく狭かった。ScytheのCPUクーラーはヒートシンクにワイヤークリップでファンを取り付けるのが伝統だけど、ヒートシンクを先に取り付けてしまうと天板側のワイヤークリップの取り付け、取り外しが困難になる。ヒートシンクに先にファンを取り付けてからCPU上に設置することになるので、ファンを交換したくなったらヒートシンクごと取り外してからでないと作業できない。

忍者五のヒートシンクとケースのトップの間にはほとんど隙間がない。指を入れてもワイヤークリップには届かないし、細い工具を差し入れたとしてもワイヤークリップを引っかけるのに必要なテンションはかけられない。

そんなわけで、標準装備の800rpmのファンでの冷却性能もせっかくだから調べてみようと思ってたんだけど、ファンを交換するたびにヒートシンクを取り外さないといけないので面倒くさくなった。重量級のヒートシンクを何度もグリグリやっているうちにCPUソケットのピンを曲げてしまうのではないかと心配になったのもある。

サイズ 忍者五 SCNJ-5000 大型サイドフロー型 CPUクーラー 忍者シリーズ 5代目
サイズ 忍者五 SCNJ-5000 大型サイドフロー型 CPUクーラー
posted with amazlet at 19.09.07
参考価格: ¥ 6,980 (2019-09-07)
Scythe
Amazon.co.jpで詳細を見る

ファンの換装

NF-P12 redux – 1700 PWMのパッケージ。ケースファンにここまでしなくてもいいのでは、と思うくらい格好いいデザインの豪華な箱に入っている。

忍者五は標準構成では800rpmの低速回転のファンを2個使うようになっているんだけど、さすがにi9-9900Kを冷やすのに800rpmでは心もとなく感じた。忍者五のパッケージに書いてあった800rpmファンの仕様を参照すると43.03CFMなのでケースファンとしての風量はそこそこだけど、CPUクーラーの冷却ファンとして使うには物足りない。静音性を重視して800rpmにしたのだろうし、同回転数でPWMファンというのもScytheの製品の中でもレアなんだけど、素直に1200rpmのファンでも良かったような気もする。

そこで、吸気側のファンを自作PCユーザーに定評のあるオーストリアのNoctua製ファンに換装した。Noctuaのケースファンはおおまかに風量重視型と静圧重視型の2種類に分類できるんだけど、回転数の高いものを選べば風量はある程度稼げるので、静圧重視型にした。

Noctuaのケースファンというと、NF-A12x25が有名だけど、ケースファンとは思えないほどの価格なので、廉価版の「NF-P12 redux – 1700 PWM」を選んだ。四隅の防振ラバーパッドがついていなかったり、回転数を調整するLNA（Low-Noise Adapter）と呼ばれる変換ケーブルがついていなかったりしてコストダウンしてある。Amazonで買うと高いけど、PCパーツ・ショップから購入すれば1700円くらいで買える。日本国内の輸入販売はScytheが担当している。

Noctua NF-P12 redux-1700 PWM - high-performance quiet 120mm fan [NF-P12 redux-1700PWM]
Noctua NF-P12 redux-1700 PWM
posted with amazlet at 19.09.07
参考価格: ¥ 2,430 (2019-09-07)
Noctua
Amazon.co.jpで詳細を見る

排気側のファンはKazeFlex120 RGB PWM 1200rpmを使った。RGBである必要はまったくないんだけど、無限五 TUFで使わなかったファンがあったので、それを単に流用しただけ。写真に写っているファンの四隅が黄色なのはTUFゲーミングのブランドカラーであるため。どうせサイドパネルで塞いでしまうので、色はどうでもよかったのでそのままにしてしまったんだけど、忍者五に付属していたファンの防振ラバーパッドと交換しても良かったかな、と後になって思った。

KazeFlex120 RGB 1200rpm PWM
KazeFlex120 RGB 1200rpm PWM
posted with amazlet at 19.09.14
Scythe
Amazon.co.jpで詳細を見る

吸気側のファンと排気側のファンの回転数が異なるので、忍者五に付属していたY字分岐ケーブルは使用しなかった。個別に制御できたほうが何か問題があった時に対処しやすい。そもそも、マザーボードのファン・コネクタは余り気味なので、NF-P12 redux – 1700 PWMを「CPU_FAN1」に、KazeFlex120 RGB PWM 1200rpmを「PUMP_FAN1」に接続した。

二重反転ファン

NF-P12 redux – 1700 PWMが反時計回り、KazeFlex120 RGB PWMが時計回りに回転するので、二重反転ファンを構成できる。ファンから出る風は、回転するプロペラから出るものである以上、完全に直進するものではなく、多少は捻れている。風が捻れていると風速のベクトルのうち、ヒートシンクのフィンに垂直方向に当たる成分があることになるので、フィンの間で乱流が起こって渦を巻き、排気方向へのエアーの抜けが悪くなる。そこで、吸気側のファンで反対方向の捻りを加えてやることで風の直進性を良くする効果を狙う。また、同じ方向に回るファンを二重に設置すると共振して騒音が大きくなる傾向にあるので、騒音対策にもなる。

一般的な製品では反時計回りのファンがほとんどなんだけど、Scytheの製品は伝統的に時計回りだった。最近、スリムタイプの15mm厚のケースファンが発売されたんだけど、風魔弐で使った薄型プロペラの金型を転用しているようで、スリムタイプは反時計回りに変わっている。

品名 回転数 風量 静圧
吸気側 Noctua NF-P12 redux – 1700 PWM 1,700 rpm 70.74 CFM
（120.2 m3/h）		 2.83 mmH2O
排気側 Scythe KazeFlex120 RGB PWM 1,200 rpm 51.17 CFM
（86.9 m3/h）		 1.05 mmH2O

忍者五の性能

取り付けが終わったのでとりあえずサイドパネルを閉じる前に電源を入れてみた。NF-P12 redux – 1700 PWMには防振ラバーパッドがついていないのでどうなるか少し心配だったけど、防振しないといけないほどNoctuaの加工精度は悪くなかった。ベアリングも良い物を使っているようで、軸がぶれているような感じはまったく見受けられなかった。

冷却性能（電力制限95W）

まずは、短期電力制限（Short Duration Power Limit）を200W、長期電力制限（Long Duration Power Limit）を95W、つまり定格運用の設定にしてLightWave 2015のレンダリングで負荷試験をしてみる。室温は30℃前後でほぼ同じ。

忍者五に換装後のCPU温度は95Wの電力制限がかかっている間は63℃くらいで推移している。取り外したCPUクーラーに比べて12℃ほど下がった。

冷却性能（電力制限200W）

次に、本丸である定格最大の4.7GHzでの冷却性能を測る。短期電力制限（Short Duration Power Limit）を200W、長期電力制限（Long Duration Power Limit）も200Wの設定でLightWave 2015のレンダリングで負荷試験をしてみる。他の条件は同じ。

忍者五に換装後のCPU温度は8コア16スレッドでのレンダリングが始まったあたりから約80℃くらいに抑えられている。当然ながらサーマル・スロットリングも働かず、8コアすべてのコアクロックが4.7GHzに張り付き、ほぼ完全に平坦化している。室温が30℃くらいあったことを考えると、真冬はもう少し余裕が出るのではないかと期待してしまう。

少し意外だったのが、8コア16スレッドでのレンダリングが始まった後、消費電力が145W前後で推移していて150Wを超えなくなったこと。コアクロックは4.7GHzになっているので処理速度に差が生じるとは考えられないし、消費電力が高いほどCPUの能力が良くなるわけでもない。

試しに、ロード・ライン・キャリブレーション（Load Line Calibration、LLC）を「Auto」からもっともアグレッシブな設定で下がろうとする電圧をむしろ上げようとする「Mode 1」に変更したみたらレンダリング中に画面が真っ黒になってPCがダウンしてしまった。そこで、電圧が一定になるように維持する「Mode 4」では消費電力が170Wを超えるようにはなったものの、CPUの発熱が尋常ではなくなり、忍者五でもCPU温度が100℃近くになってしまった。LLCは「Auto」にしておくのが無難なようだ。

冷却性能まとめ

上記の結果からCPU温度の推移だけ抜き出したのが次のグラフ。2:00～3:00あたりがCPUにフルロードがかかっている部分。

何はともあれ、大型のヒートシンクと大口径のファンを使ったことで17℃もの改善がみられ、余裕をもって4.7GHz常用ができるようになった。発熱の問題が解消されたことで心配事がなくなり、スッキリした。4.7GHzで回せない鬱憤も晴らせたので精神衛生的にも好ましい効果と言え、結果的には換装してよかった。

定格最大4.7GHzのパフォーマンス

LightWave 2015でのレンダリング時間は約10秒ほど短縮できた。率にして9%くらいの改善。2分切りも期待したけど、あとわずがのところで1分台には届かなかった。ただし、これは一番結果が良かった時のスクリーンショット。原因は不明なものの、ある試験では条件によってはレンダリング時間があまり変わらないという結果もあった。メモリがDDR4-2666なのも影響しているかもしれないけど、忍者五はメモリとの干渉クリアランスが厳しく、背の高いヒートスプレッダを装備したオーバークロックメモリを搭載して試験するのは難しい。

LightWave 2015
CPU 総レンダリング時間 パフォーマンス 備考
Core i7-860 685.2秒（11分25秒） 1.00倍 DDR3-1333
Core i7-9700K 148.9秒（2分28秒） 4.60倍 DDR4-3600
Core i9-9900K（95W） 132.4秒（2分12秒） 5.17倍 DDR4-2666
Core i9-9900K（200W） 121.1秒（2分1秒） 5.66倍 DDR4-2666

換装後

忍者五に換装した後のDAIVケースの内部の全体写真。マザーボードがZ390-S01ならとりあえず取り付けることは可能なので、ヒートシンクの大きさが気になって躊躇している人には参考になるかもしれない。CPUソケットの位置があと1cm左だったらリア側のケースファンと干渉してしまうところだったので、ほっとしているところ。

CPUまわりの設計がほぼ同じのMSI「MPG Z390 GAMING PLUS」や「Z390-A PRO」でも問題なく設置できるだろう。

付属品の不備

忍者五に付属していたワイヤークリップ。上のものが本来使うべきワイヤークリップで、下のものが間違って入っていたと思われるワイヤークリップ。よく見ると、縦方向のワイヤーの長さが違う。

付属品を袋詰めした時のミスだと思うんだけど、ワイヤークリップが1本だけサイズの異なるものが入っていた。ファンを取り付ける時にかなりの強さで引っ張ってもクリップが一向にヒートシンクのフィンに引っかからないのでおかしいと思って確認したら、他のクリップと長さが異なっていた。

おそらく、風魔弐の15mm厚ファン用のワイヤークリップか、改良前の旧仕様のものだと思うんだけど、長さが少し違うだけで片方だけ見た時に判別が困難な上、型番を書くところもないただの針金なので、仕様が違うものが紛れ込んでいるのに気が付かずに袋に入れてしまったのだろう。機能上必要なくても判別のためにクリップの形をわざと変えるとか、もう少し工夫が必要ではないかと思った。

たまたま無限五をデュアルファンにするために予備でついていたワイヤークリップを持っていたのでなんとか事なきを得たけど、忍者五が初めて購入したScythe製のCPUクーラーだったらファンの取り付けができずに詰んでいたところだった。付属品はよく確認したほうがいいようだ。

Scytheに連絡すればワイヤークリップくらいなら郵送で交換してくれそうな気はするけど、余計な手間はできるだけ避けたいのはお互い様なので、風魔弐などの25mm厚のファンを使わないラインナップを増やした時やクリップの設計を変更した時にパーツの管理方法も併せて考えて欲しかったところだ。

関連記事


DAIV-DQZ530S1P-EX9の性能

最終更新：2019/10/15



DAIV-DQZ530S1P-EX9の性能について。

CPU

CPUをはじめとするコンピュータ・システムを構成するパーツの性能を計測するベンチマーク・ソフトウェアはたくさんあるけれど、ひとまず、Intelをはじめ、AMDを含むx86互換CPUの計測結果が豊富に掲載されているPassMark Softwareのスコアを参考にした。旧メインPCのi7-860に対して、i9-9900Kは4.04倍のスコアが出ている。

2019年6月9日現在のスコア。PassMark Software © 2008-2019

LightWave 2015のレンダリング時間

ベンチマークのスコアはあくまでも目安に過ぎないし、スコアを上げるためだけのPCを組んでいるわけではないので、PCとして実用した場合にどのくらいのパフォーマンスが出るのかが重要。普段使っている3DCGソフトウェアはLightWave 2015。750,530ポイント（頂点）、1,473,360ポリゴンの重めのシーンをレンダリングして比較してみた。LightWaveの標準レンダラーはGPUを一切使わず、CPUだけでレンダリングするため、CPUのパワーがレンダリング時間の長短に直結する。

まず、i7-860の結果。

i7-860でレンダリングした時の結果。685.2秒で約11分25秒。

次に、i9-9900Kの結果。

i9-9900Kでレンダリングした時の結果。132.4秒で約2分12秒。

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

ベンチマークのスコアを参考にすると、3倍以上で4倍に近い結果が出れば御の字と思ってたけど、なんと、旧マシンより5.17倍も早くレンダリングが終わった。これは純粋に嬉しい。ハイパースレッドのないi7-9700Kとi9-9900Kのどちらにすべきか最後まで悩んだけど、8コア16スレッドの威力は凄まじい。メモリが旧メインPCの倍の帯域でデータを伝送できることも影響しているだろうけど、さすがにメモリの影響までは自分の環境では要因を分離できない。

レンダリング中のコア・クロックは4.2GHzで推移していたので、全コアにターボ・ブーストがかけられる最大クロックは4.7GHzだから、オーバークロックをしてなくてもまだ余力があることになる。とは言うものの、長期間電力制限（Long Duration Power Limit = PL1）が定格の95Wの状態だとターボ・ブーストは3.6GHzから少し上がったくらいにしかならない。

データシートを見ると、短期間電力制限（Short Duration Power Limit = PL2）はPL1×1.25となっているから、そのくらいまでは耐えられると判断してPL1を95×1.25=118Wに設定して試してみた。その結果、最大クロックは4.5GHzまで上がったけどコアの温度があっけなく100℃を超えてしまい、一部の物理コアにサーマル・スロットリングがかかって全コアの協調が乱れたため、レンダリング時間はまったく短くならなかった。

最初からついてきた90mmサイドフロー空冷クーラーではまったく力不足なのは明白なんだけど、CPUだけを「空冷最強」と言われるnoctua NH-U12Aのような高級クーラーや水冷クーラーで冷やせば済む話とは思えなくて、VRMへの負荷を考えると高電力常用はCPUやマザーボードの寿命を縮めかねない。5.17倍でも満足すべき結果だ。

日本ではi7-9700Fがようやく発売されたところだけど、そのベンチマーク・スコアを見るとi7-860の3.36倍のパフォーマンスが出せるようだ。ということは、まだ日本で発売されていない、「K」も「F」もついていない無印のi7-9700も同じくらいのパフォーマンスを期待できる。旧メインPCをリフレッシュしてレンダリングの演算能力を出させるだけのためのマシンを組んでもコストに対して高いパフォーマンスのものを作れそうなので期待が膨らむ。

GPU

グラフィックス・カードはQuadro P2000。ミドルレンジのカードではあるけど、最新のTuringアーキテクチャではなく、ひとつ前のPascalアーキテクチャのGP106をベースにしているので、それほど大きな期待をしているわけではないけれど、OpenGLに最適化されているので、3DCGソフトウェアでテクスチャ・マッピングをリアルタイムで表示させたい時は役に立つ。旧メインPCはGeForce GTS 250だった。

同じくPassMark Softwareのスコアで比較してみると、Quadro P2000はGeForce GTS 250の8.31倍のパフォーマンスとなっている。第9世代Coreシリーズ・プロセッサに内蔵されているIntel UHD 630グラフィックスのほうがGTS 250よりスコアが上回っているのを見ると時代の流れを感じる。

2019年6月9日現在のスコア。PassMark Software © 2008-2019

GPUの力量を端的に測るいい方法が思いつかなかったので、とりあえずCrystalMark 2004R7でスコアを出してみた。

まず、GeForce GTS 250を搭載した旧メインPC。OpenGLスコアは22,278。6ピンの補助電源が必要で、消費電力が150Wもあることを考えると、かなりワット・パフォーマンスは悪い。Intel UHD 630に代理をさせれば電力消費はもっと改善することになる。

次に、Quadro P2000を搭載したDAIV-DQZ530S1P-EX9。OpenGLスコアは256,951。GeForce GTS 250の11.53倍のスコアが出ている。GTS 250でもLightWaveで使う分にはそれほど力不足と感じたことはないので、自分の使い方でQuadro P2000のパワーを最大限引き出すのは難しいかもしれないけど、GTS 250の消費電力の半分の75Wで10倍の余力があるのは悪くない。

ELSA NVIDIA Quadro P2000 グラフィックスボード VD6269 EQP2000-5GER
ELSA NVIDIA Quadro P2000 グラフィックスボード VD6269 EQP2000-5GER
posted with amazlet at 19.06.10
参考価格: ¥ 64,278 (2019-06-10)
エルザ (2017-03-27)
Amazon.co.jpで詳細を見る

M.2 SSD

M.2 SSDはADATAのASX8200NP-480GT-C。シーケンシャル・リードは約2,900MB/s（23Gbps）出ている。SATA SSDでも十分速いと思ってたけど、10秒くらいでWindowsが起動するのはさすがに驚異的。もっと高級なM.2 SSDなら3,400MB/sとか出るそうだけど、自分にはこれで十分だ。

ADATA Technology XPG SX8200 PCIe Gen3x4 M.2 2280 SSD 480GB ASX8200NP-480GT-C
ADATA Technology XPG SX8200 PCIe Gen3x4 M.2 2280 SSD 480GB ASX8200NP-480GT-C
posted with amazlet at 19.06.10
参考価格: ¥ 16,475 (2019-06-10)
ADATA Technology (2018-06-05)
Amazon.co.jpで詳細を見る

HDD

HDDはSeagateのST4000DM004（4TB SATA600 5,400rpm）だけど、同容量のWDのWD40EZRZ-RT2（4TB SATA600 5,400rpm）とRAID 1を組んでしまっているので、シーケンシャル・リードは165MB/sと平凡な結果。HDDに速度を求める時代ではないので、故障せずにデータの保管庫としての役割を果たしてくれればそれで十分。

Seagate BarraCuda 4TB【 2年保証 】正規代理店 3.5インチ HDD 内蔵 ハードディスク SATA 6Gb/s 64GB 5400rpm デスクトップPC向け
Seagate BarraCuda 4TB 3.5インチ HDD 内蔵 ハードディスク SATA 6Gb/s 64GB 5400rpm デスクトップPC向け
posted with amazlet at 19.06.10
参考価格: ¥ 6,999 (2019-06-10)
SEAGATE (2017-07-14)
Amazon.co.jpで詳細を見る
【国内代理店品】WD 内蔵HDD Blue 3.5
WD 内蔵HDD Blue 3.5″ 4TB SATA(6Gb/s) 64MB 5,400rpm WD40EZRZ-RT2
posted with amazlet at 19.06.10
参考価格: ¥ 8,750 (2019-06-10)
Western Digital (2018-01-01)
Amazon.co.jpで詳細を見る

関連記事


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で二次元キャラ系人物モデリング奮闘記 ―視線コントロール編―

最終更新：2017/01/13



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

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

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

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

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

morph031

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

morph032

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

morph033 morph034

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

morph035

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

morph041
俯瞰

morph042
仰視

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

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

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

morph030

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

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

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

morph040

この図から、目の正面方向と注視点に対する方向がなす角度\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}を移動させるとグラフの振幅が変動する。

morph036

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

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

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


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

関連記事



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

最終更新：2016/10/14



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

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

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

目を閉じるモーフの作成

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

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

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

morph000

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

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

morph001

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

morph002

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

morph003

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

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

morph004

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

morph005

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

morph006

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

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

morph006a

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

morph007

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

morph008

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

morph009

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

morph010

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

morph011

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

morph012

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

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

morph013

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

morph014

口を閉じるモーフの作成

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

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

morph015

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

morph016

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

morph017

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

morph018

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

morph019

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

morph020

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

morph021

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

morph022

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

morph023

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

morph024

表情集

morph026
視線右

morph027
視線左

 

morph028
怒りの表情

morph029
悲しみの表情（要見直し）

関連記事



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しか選択肢がない。

Skirt000

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

Skirt001

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

Skirt002

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

Skirt003

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

Skirt004

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

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

Skirt005

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

Skirt006

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

Skirt007

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

Skirt008

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

Skirt009

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

Skirt010

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

Skirt011

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

Skirt012

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

Skirt013

アポロニウスの円

ここからが本題。ひとつのひだを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°刻みにするため。

Skirt015

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

Skirt016

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

Skirt014

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

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

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

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

Skirt017

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

Skirt018

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

Skirt019

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

Skirt020

縦横の模様を合わせる

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

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

Skirt021

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

Skirt022

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

Skirt023

曲線折りの模擬

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

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

Skirt024

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

Skirt025

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

Skirt026

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

Skirt027

すべての段の折り目について、アポロニウスの円を作図するのがもっとも正確な方法なんだけど、(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%まで内側に向かって拡大する。

Skirt028

ウェストの絞り込み

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

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

Skirt029

Skirt029a

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

Skirt030

Skirt030a

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

Skirt031

Skirt031a

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

基本版完成

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

Skirt032

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

Skirt033

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

Skirt034

途中経過

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

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

skirt036

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

skirt037

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

skirt038

関連記事

参考記事


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

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

HandFK000

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

HandFK001

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

HandFK002

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

HandFK003

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

HandFK004

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

HandFK005

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

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

HandFK006

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

HandFK007

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

HandFK008

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

HandFK009

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

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

HandFK027

右手への複製

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

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

HandFK010

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

HandFK011

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

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

HandFK012

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

HandFK013

コンストレインの設定

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

中指

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

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

HandFK014

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

HandFK028

薬指

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

HandFK015

小指

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

HandFK016

人差し指

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

HandFK017

親指

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

HandFK018

リグのテスト

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

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

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

HandFK019

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

HandFK020

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

HandFK021

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

HandFK022

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

HandFK023

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

HandFK024

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

HandFK025

途中経過

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

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

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

HandFK026

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

関連記事

参考記事



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キー）を利用すると簡単に取り出すことができる。

GENOMA000

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

GENOMA001

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

GENOMA002

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

GENOMA003

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

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

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

GENOMA004

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

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

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

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

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

GENOMA005

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

GENOMA006

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

GENOMA007

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

GENOMA008

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

GENOMA009

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

GENOMA010

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

GENOMA011

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

GENOMA012

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

GENOMAリグの作成

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

GENOMA013

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

GENOMA014

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

GENOMA015

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

GENOMA016

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

GENOMA017

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

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

GENOMA018

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

GENOMA019

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

GENOMA020

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

GENOMA021

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

GENOMA022

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

GENOMA023

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

GENOMA024

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

GENOMAリグの更新

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

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

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

  • Anima_Data_Counter_FK@0
  • Anima_Data_Counter_SaIControl@0
  • Animation_Data_Counter

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

途中経過

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

GENOMA025

関連記事